NGINX Unit als Alternative zu PHP-FPM? Architektur, Risiken und Einsatzfälle

Archivierter Status und klares Kurzurteil

Stand 30. September 2026 lautet das klare Urteil: NGINX Unit konnte PHP-Anwendungen direkt ausführen und dabei HTTP-Verbindungen annehmen, TLS terminieren, statische Dateien ausliefern sowie Anfragen routen. Damit ging der Funktionsumfang deutlich über PHP-FPM hinaus. Für neue produktive PHP-Hosting-Plattformen ist Unit dennoch keine allgemeine Empfehlung, weil das offizielle Projekt seit Oktober 2025 archiviert und nicht mehr gepflegt wird.

Das bedeutet nicht, dass eine vorhandene Unit-Installation sofort funktionsunfähig wäre. Sie kann weiterhin eine Anwendung bedienen, sofern ihre Abhängigkeiten, Sicherheitsvorkehrungen und ein Migrationsweg dokumentiert sind. Eine Neuinvestition muss aber anders bewertet werden: Ohne fortlaufende Projektpflege steigen Risiken bei Sicherheitslücken, Paketverfügbarkeit, neuen Betriebssystemversionen und künftigen PHP-Kompatibilitäten.

Bei Versionsangaben ist eine saubere Trennung wichtig. Die weiterhin verfügbare Installationsdokumentation nennt vielfach Unit 1.34.2, während der stabile Release-Tag 1.35.0 veröffentlicht wurde. Der Release belegt unter anderem PHP-8.5-Kompatibilität; daraus folgt jedoch keine fortgesetzte Wartung. Der Entwicklungszweig master ist wegen des archivierten Status keine maßgebliche Produktversion für Betriebsentscheidungen.

NGINX, PHP-FPM und Unit unterscheiden

Für eine belastbare Entscheidung müssen die Komponenten getrennt betrachtet werden. NGINX ist Webserver und Reverse Proxy: Er nimmt HTTP-Anfragen entgegen, kann statische Inhalte ausliefern und leitet dynamische Anfragen weiter. PHP-FPM ist dagegen ein FastCGI Process Manager. Er stellt PHP-Worker bereit, verarbeitet aber nicht selbst die typische Webserver-Aufgabe der HTTP-Annahme und des Routings.

Im klassischen Aufbau erreicht eine Anfrage zunächst NGINX. Handelt es sich um eine statische Datei, kann NGINX sie unmittelbar ausliefern. Für ein PHP-Skript übergibt NGINX die erforderlichen FastCGI-Parameter an einen PHP-FPM-Pool; ein freier Worker führt den Code aus und liefert die Antwort über NGINX zurück. Poolgröße und Prozessmodus werden bei PHP-FPM in Konfigurationsdateien im php.ini-Format gesteuert.

Unit war demgegenüber ein Application Server mit Listenern, Routen, statischer Auslieferung und Sprachlaufzeiten in einem JSON-Konfigurationsmodell. Eine PHP-Anwendung wird dort als Anwendungstyp eingebunden; Unit kann somit den Request-Weg innerhalb derselben Plattform von der Annahme bis zur PHP-Ausführung abbilden. Das reduziert nicht automatisch das Betriebsrisiko, verändert aber die Zuständigkeitsgrenzen.

Unit ist deshalb nicht „NGINX mit eingebettetem PHP-FPM“. Beim Bau des PHP-Moduls entsteht ein eigenes SAPI-Modul, das mit der PHP-Embed-Bibliothek verknüpft ist. Bei Analyse und Migration müssen Teams folglich nicht nur FastCGI-Einstellungen übertragen, sondern Routing, Anwendungsdefinitionen, Modulbindung und Diagnosewege neu zuordnen. Fehler lassen sich nicht pauschal einem vorgeschalteten Webserver oder einem getrennten FPM-Pool zuschreiben.

PHP-Module, Versionen und Konfigurationsgrenzen

Für PHP benötigt eine Unit-Installation neben dem Kern ein passendes Sprachmodul. Dieses Modul ist an die verwendete PHP-Version und die Unit-Installation gebunden. Waren keine geeigneten Pakete für Betriebssystem und PHP-Version verfügbar, beschrieb die Dokumentation den Eigenbau mit einer PHP-Installation, die die Embed-SAPI bereitstellt. Das erhöht den Aufwand für Updates, reproduzierbare Builds und die Fehleranalyse erheblich.

Auch die Konfiguration folgt unterschiedlichen Modellen. Unit bündelt Listener, Routen und Anwendungen als JSON-Daten über ihre Konfigurationsschnittstelle. PHP-FPM verwaltet Pools dagegen in Dateien im php.ini-Format. Diese Differenz ist mehr als Syntax: In einem FPM-Stack liegen Webserver-Regeln und PHP-Pooldefinitionen getrennt, während Unit beides enger in einer Plattform verbindet. Migrationskonzepte müssen diese Struktur berücksichtigen.

Für PHP-Direktiven unterscheidet Unit die Bereiche admin und user. Admin-Optionen entsprechen PHP_INI_SYSTEM und sind durch die Anwendung nicht zur Laufzeit veränderbar; User-Optionen entsprechen PHP_INI_USER. Unit erweitert damit aber nicht den zulässigen Bereich einer PHP-Direktive. Ob eine Einstellung auf diesem Weg gesetzt oder durch Anwendungscode geändert werden darf, bestimmt weiterhin ihr PHP-Konfigurationsmodus.

Warnung: Die in Unit 1.35.0 ausgewiesene PHP-8.5-Kompatibilität belegt nur die Unterstützung dieses Stands im letzten stabilen Release. Sie ist kein Versprechen für künftige Sicherheitskorrekturen oder Anpassungen des Unit-PHP-Moduls. Für Bestandsbetrieb sollten daher exakter Unit-Tag, PHP-Version, Modulherkunft und ein getesteter Ablösepfad als zusammenhängende Abhängigkeit dokumentiert werden.

PHP-Routing und Front Controller konfigurieren

Eine Unit-Konfiguration verbindet einen Listener mit Routen und einer Anwendung. Für eine lokale Demo kann der Listener ausschließlich auf 127.0.0.1:8080 lauschen. Eine Route versucht zunächst, die angeforderte Datei unter /srv/example-app/public statisch auszuliefern. PHP-Dateien werden über den MIME-Typ-Ausschluss von dieser Auslieferung ausgenommen und an die PHP-Anwendung weitergereicht; dasselbe gilt für nicht vorhandene Dateien. So bleiben öffentliche Dateien und die Anwendungsausführung als getrennte Schritte nachvollziehbar.

In der Anwendung legt root das Dokumentenverzeichnis fest, während type: php die PHP-Laufzeit auswählt. Mit script: index.php wird jede an die Anwendung weitergereichte Anfrage an dieses Skript geleitet. Das entspricht dem Front Controller vieler PHP-Frameworks: Die Anwendung wertet den ursprünglichen Pfad selbst aus und entscheidet etwa über Controller oder Fehlerseite.

Ohne die Einstellung script verarbeitet Unit URI-basierte Skriptpfade. Das kann für ältere Anwendungen passend sein, deren PHP-Dateien direkt aufgerufen werden sollen, verlangt aber eine sorgfältige Begrenzung der erreichbaren Pfade. targets erlauben zusätzlich Teilbereiche mit abweichendem root-, script- oder index-Verhalten. Sie sind daher kein Ersatz für Routing, sondern eine Möglichkeit, mehrere Anwendungsregeln gezielt zu definieren.

Das folgende Beispiel ist eine JSON-Dateikonfiguration für eine lokale Demo, nicht für einen öffentlichen Dienst. Sie enthält weder Domainnamen noch TLS- oder Zugangsdaten. Vor einer Übernahme müssen Dateirechte, der tatsächlich installierte PHP-Support und die für Unit vorgesehene Methode zum Einspielen der Konfiguration geprüft werden.

{
  "listeners": {
    "127.0.0.1:8080": {
      "pass": "routes/example"
    }
  },
  "routes": {
    "example": [
      {
        "action": {
          "share": "/srv/example-app/public$uri",
          "types": ["!application/x-httpd-php"],
          "fallback": {
            "pass": "applications/example-php"
          }
        }
      }
    ]
  },
  "applications": {
    "example-php": {
      "type": "php",
      "root": "/srv/example-app/public",
      "script": "index.php"
    }
  }
}

Die Reihenfolge ist entscheidend: Der statische Auslieferung dienende share-Schritt wird vor dem Fallback versucht, schließt aber PHP-Dateien ausdrücklich aus. Diese Anfragen und nicht vorhandene Dateien landen bei index.php; dadurch funktionieren auch sprechende URLs wie /artikel/beispiel ohne eine gleichnamige Datei. Ob zusätzliche Regeln für Upload-Verzeichnisse, Verwaltungsbereiche oder direkt erreichbare PHP-Dateien nötig sind, ergibt sich aus der jeweiligen Anwendung und sollte nicht pauschal aus dieser Demo abgeleitet werden.

Prozessmodelle und RAM-Budget vergleichen

PHP-FPM steuert Worker je Pool über die Modi static, dynamic und ondemand. Bei Unit wird die Prozesszahl dagegen innerhalb der Anwendung modelliert. Eine dynamische Unit-Konfiguration begrenzt mit processes.max die Gesamtzahl und hält mit processes.spare Leerlaufprozesse vor; idle_timeout räumt überzählige inaktive Prozesse ab.

Die Begriffe sind deshalb nicht eins zu eins austauschbar. Insbesondere ist eine dokumentierte Voreinstellung kein geeigneter Wert für eine Website. Sowohl pm.max_children als auch processes.max begrenzen parallele PHP-Arbeit und können bei zu niedrigen Werten Warteschlangen erzeugen. Zu hohe Werte konkurrieren dagegen mit Betriebssystem, Datenbank, Cache und weiteren Diensten um Arbeitsspeicher.

Ein RAM-Budget ist zunächst nur ein Planungsmodell: Vom Gesamtspeicher werden Reserven für Betriebssystem, Datenbank, Cache und weitere Prozesse abgezogen. Der verbleibende Wert wird durch einen konservativ angesetzten Speicherbedarf je PHP-Worker geteilt. Beispielhaft ergeben 1.200 MiB für PHP geteilt durch 120 MiB je Worker rechnerisch zehn Worker; beide Werte sind bewusst gewählte Platzhalter, keine Messung oder Konfigurationsempfehlung.

Das Ergebnis ist eine Obergrenze und ein Startpunkt für Beobachtung, nicht die richtige Einstellung. Entscheidend sind reale Spitzenwerte, Warteschlangen, Antwortfehler und der Speicherbedarf unter typischer sowie hoher Last. Für die methodische Herleitung und das Nachjustieren von pm.max_children hilft der interne Beitrag PHP-FPM-Children passend berechnen. Bei Unit gilt derselbe Grundsatz, auch wenn die Parameter anders heißen.

Warnung: Prozessgrenzen durch bloßes Übernehmen fremder Zahlen zu setzen, verschiebt Probleme häufig nur. Erst ein abgegrenztes Speicherbudget und wiederholtes Monitoring zeigen, ob eine Worker-Obergrenze zur Anwendung, ihren Erweiterungen und den gleichzeitig betriebenen Diensten passt.

Betriebsmodelle für PHP-Hosting bewerten

Die Tabelle ordnet Architekturen, nicht Geschwindigkeit oder Speicherverbrauch. Für neues PHP-Hosting spricht beim NGINX-PHP-FPM-Aufbau vor allem die klare Trennung: Der Webserver behandelt HTTP, Proxying und statische Inhalte, während PHP-FPM die PHP-Worker pro Pool verwaltet. Diese Zuständigkeiten erleichtern es, Konfigurationen, Fehlerbilder und Updates getrennt zu beurteilen.

Unit konnte Listener, Routing, statische Dateien und Anwendungen in einer Plattform bündeln und neben PHP weitere Laufzeiten unterstützen. Dieser Mehrsprachenansatz kann erklären, weshalb eine bestehende Umgebung Unit gewählt hat. Für ausschließlich PHP-basierte Angebote ist er jedoch kein automatischer Vorteil: Er ersetzt weder die Bewertung der benötigten Funktionen noch die Prüfung, ob das Team die andere Konfigurations- und Betriebslogik dauerhaft beherrschen kann.

Bei Unit 1.35.0 muss der technische Funktionsumfang vom Wartungsstatus getrennt werden. Der Release-Tag belegt die veröffentlichte Version und deren Änderungen; daraus folgt keine weitere Pflege des inzwischen archivierten Projekts. Für eine Neuentscheidung wiegt diese Grenze schwerer als eine geringere Zahl sichtbarer Komponenten. Für eine vorhandene Installation ist sie dagegen Anlass, Abhängigkeiten und einen Migrationsweg zu dokumentieren.

Apache mit PHP-FPM ist keine pauschal bessere oder schlechtere Alternative, sondern eine Option bei vorhandenen Apache-Anforderungen. Die Auswahl sollte sich an Wartbarkeit, verfügbaren PHP-Versionen, Patchprozessen, Teamwissen und dem Rückfallplan orientieren. Ohne vergleichbare Lastprofile und dokumentierte Messmethodik lässt sich aus dieser Architekturübersicht keine belastbare Leistungsrangfolge ableiten.

Unit im Bestand sicher betreiben

Eine vorhandene Unit-Installation sollte zunächst als Bestandssystem erfasst werden, nicht als Vorlage für eine neue Plattform. Entscheidend sind die tatsächlich eingesetzte Version, die angebundenen Anwendungen und ihre Abhängigkeiten. Dass Unit weiterhin technisch ausführbar ist, ändert nichts daran, dass das Projekt archiviert wurde; Betrieb und Ablösung müssen daher gemeinsam geplant werden.

Bei WordPress, Joomla oder Drupal ist der Front Controller der zentrale Punkt: Nicht als Datei vorhandene Pfade müssen an die zentrale PHP-Einstiegsdatei gehen, während vorhandene Dateien direkt ausgeliefert werden können. Die WordPress-Anleitung für Unit zeigt dieses Routing-Prinzip einschließlich der Behandlung von PHP-Dateien und /wp-admin/. Für ein bestehendes CMS kann das eine nachvollziehbare Konfiguration sein; für eine Neuinstallation folgt daraus keine Empfehlung für Unit.

Mehrere kleine Anwendungen mit PHP, Python, Ruby oder Node.js konnten unter Unit Listener, Routen und Laufzeiten in einer gemeinsamen Plattform bündeln. Das kann erklären, warum sich eine bestehende Architektur seinerzeit für Unit entschieden hat. Bei reinem PHP-Hosting ist diese Mehrsprachenfähigkeit jedoch kein Selbstzweck: Separate, gepflegte Komponenten können trotz zusätzlicher Schnittstellen langfristig besser wartbar sein.

Ein eingefrorenes Container-Deployment verlangt eine besonders genaue Inventarisierung. Dokumentiere dafür den exakten Unit-Tag, die PHP-Version, das installierte Sprachmodul, das Basisimage und die vollständige Konfiguration. Ergänze außerdem Quellen für Images und Pakete, den Patchprozess sowie einen getesteten Migrations- und Rückfallpfad. PHP-Kompatibilität eines bestimmten Unit-Releases ist dabei keine Zusage, dass das zugehörige Modul künftig Sicherheitskorrekturen erhält.

NGINX kann vor Unit stehen, etwa wenn eine bestehende NGINX-Schicht erhalten bleiben soll oder Zugriffe gezielt vorgelagert werden. Die Unit-Dokumentation nennt diese Integration auch im Zusammenhang mit der Absicherung des Control Socket. Sie behebt den archivierten Status aber nicht und schafft einen weiteren Dienst mit eigener Konfiguration, Protokollierung und Updateverantwortung. Der Nutzen muss deshalb konkret gegen diesen Betriebsaufwand abgewogen werden.

Timeouts, Logs und hängende Prozesse

Prozessgrenzen sind keine Fehlerdiagnose. Mit limits.requests kann Unit einen Anwendungsprozess nach einer festgelegten Zahl bearbeiteter Anfragen ersetzen. Das kann kumulierte Speicherbelegung zeitlich begrenzen, beseitigt aber weder Speicherlecks noch übergroße Datenstrukturen oder blockierende externe Aufrufe. Ein regelmäßiger Neustart darf daher nicht als Nachweis für einen stabilen Anwendungscode gelten.

Mit limits.timeout beendet Unit eine Anfrage nach Ablauf der konfigurierten Zeit mit HTTP 503. Das ist eine sichtbare Schutzgrenze für einzelne Requests, jedoch kein vollständiger Schutz gegen festgefahrene Worker: Laut Dokumentation erkennt Unit eingefrorene Prozesse nicht; sie können im Prozesspool verbleiben. Ein höherer Timeout verschiebt dieses Problem nur, ein niedrigerer kann regulär langsame Vorgänge abbrechen.

• HTTP-Status, betroffene Pfade, Zeitfenster und Häufigkeit erfassen, bevor Grenzwerte geändert werden.
• Zugriffs-, Fehler- und Anwendungslogs anhand von Zeitstempeln zusammenführen; bei PHP-FPM kann ein Slowlog zusätzliche Stack-Hinweise liefern.
• CPU, Arbeitsspeicher, I/O, Netzwerkverbindungen sowie Zustand und Anzahl der Prozesse prüfen.
• Danach Code, Datenbankabfragen, Dateisystemzugriffe und externe Dienste als mögliche Ursache untersuchen.
• Erst wenn Ursache und Lastprofil bekannt sind, Timeouts, Prozessgrenzen oder Neustartregeln gezielt anpassen.

Ein HTTP 503 kann somit auf ein abgelaufenes Zeitlimit hinweisen, aber auch durch vorgelagerte Komponenten oder andere Fehler entstehen. Wiederkehrende lange PHP-Anfragen solltest du nicht allein über Worker-Zahlen behandeln. Die Anleitung zum PHP-FPM-Slowlog und zur Ursachenanalyse langsamer Requests zeigt, wie Stack-Spuren mit Request-Daten verbunden werden können; die gleiche Ursache-Wirkung-Logik ist auch bei einer Unit-Bestandsanalyse sinnvoll.

Besonders kritisch sind Symptome ohne eindeutigen Abschluss: steigende Wartezeiten, dauerhaft belegte Prozesse oder ausbleibende Logfortschritte. Dann sind Prozesszustand und Abhängigkeiten wichtiger als eine pauschale Timeout-Erhöhung. Prüfe beispielsweise, ob ein PHP-Worker auf Datenbank-, DNS-, Dateisystem- oder Netzwerk-I/O wartet. Erst die konkrete Blockade entscheidet, ob ein Code-Fix, eine Ressourcenanpassung oder ein kontrollierter Neustart angemessen ist.

Entscheidung für neue und alte Systeme

Für neue PHP-Hosting-Umgebungen ist ein gepflegter Webserver mit PHP-FPM die nachvollziehbarere Standardentscheidung. PHP-FPM gehört zur regulären PHP-Distribution und stellt dokumentierte Pool- und Prozessmanager-Optionen bereit. Bei Unit verschiebt sich die Frage dagegen von der reinen Funktionsfähigkeit zur Wartbarkeit: Die Installation kann weiterlaufen, doch der archivierte Projektstatus erhöht das Risiko einer langfristigen Abhängigkeit.

Für vorhandene Unit-Systeme beginnt eine sachliche Entscheidung mit einer Inventarisierung. Prüfe Wartungsstatus und Patchfähigkeit von Betriebssystem, PHP und Basisimage, die Kompatibilität des installierten Sprachmoduls, vorhandenes Betriebswissen sowie gekoppelte Dienste. Ebenso wichtig sind exportierbare Konfigurationen, ein reproduzierbarer Rollback und ein Zielsystem, auf das sich Routing, PHP-Einstellungen und Deployments schrittweise übertragen lassen.

Eine Migration benötigt keine erfundene allgemeingültige Frist, aber eine priorisierte Reihenfolge. Internet-exponierte Anwendungen, nicht aktualisierbare Images, unklare Modulherkunft und geschäftskritische Anwendungen ohne Rückfallplan verdienen zuerst Aufmerksamkeit. Danach lassen sich Anwendungen nach Komplexität und Abhängigkeiten gruppieren. Ein Parallelbetrieb während einer kontrollierten Umstellung kann Risiken reduzieren, sofern Datenhaltung, Sessions und Rückweg vorher definiert sind.

Die Control API ist ein administrativer Zugriff und kein gewöhnlicher Endpunkt einer Website. Unit dokumentiert für sie einen Unix-Domain-Socket und begründet dessen Einsatz mit Sicherheitsaspekten. Lege restriktive Dateirechte und klar abgegrenzte administrative Zugriffe fest; eine öffentliche Erreichbarkeit würde Angreifern bei erfolgreichem Zugriff weitreichende Möglichkeiten zur Änderung der Konfiguration eröffnen.

Der praktische Migrationspfad endet nicht mit einer neuen Prozesskonfiguration. Übernimm Anwendung für Anwendung die PHP-Version, Erweiterungen, Umgebungswerte, Dateirechte, Routingregeln und Beobachtbarkeit in das Zielsystem. Vergleiche dabei erwartete Antworten und Fehlerfälle statt pauschale Geschwindigkeitsurteile abzuleiten. So wird aus einer ungeplanten Altlast eine dokumentierte Ablösestrategie mit nachvollziehbaren technischen Entscheidungen.