NGINX Unit als alternatief voor PHP-FPM? Architectuur, risico’s en toepassingen

Gearchiveerde status en een duidelijk kort oordeel

Per 30 september 2026 luidt het duidelijke oordeel: NGINX-unit kon PHP-toepassingen rechtstreeks uitvoeren en daarbij HTTP-verbindingen aannemen, TLS beëindigen, statische bestanden leveren en verzoeken doorsturen. Daarmee reikte de functionaliteit aanzienlijk verder dan die van PHP-FPM. Voor nieuwe productieve PHP-hostingplatforms is Unit echter geen algemene aanbeveling, omdat het officiële project sinds oktober 2025 is gearchiveerd en niet meer wordt onderhouden.

Dat betekent niet dat een bestaande Unit-installatie meteen onbruikbaar zou zijn. Deze kan nog steeds een toepassing ondersteunen, mits de afhankelijkheden, beveiligingsmaatregelen en een migratietraject zijn gedocumenteerd. Een nieuwe investering moet echter anders worden beoordeeld: zonder voortdurend projectonderhoud nemen de risico’s toe op het gebied van beveiligingslekken, beschikbaarheid van pakketten, nieuwe versies van besturingssystemen en toekomstige PHP-compatibiliteit.

Bij versie-aanduidingen is een duidelijke scheiding belangrijk. In de installatiedocumentatie, die nog steeds beschikbaar is, wordt vaak Unit 1.34.2 genoemd, terwijl de stabiele release 1.35.0 is uitgebracht. Deze release is onder andere compatibel met PHP 8.5; dit betekent echter niet dat het onderhoud wordt voortgezet. De ontwikkelingstak master is vanwege de gearchiveerde status geen relevante productversie voor operationele beslissingen.

Het verschil tussen NGINX, PHP-FPM en Unit

Om een weloverwogen beslissing te kunnen nemen, moeten de onderdelen afzonderlijk worden bekeken. NGINX is een webserver en reverse proxy: hij ontvangt HTTP-verzoeken, kan statische inhoud leveren en stuurt dynamische verzoeken door. PHP-FPM is daarentegen een FastCGI Process Manager. Het stelt PHP-workers ter beschikking, maar voert zelf niet de typische webservertaak van het ontvangen en doorsturen van HTTP-verzoeken uit.

In de klassieke opzet komt een verzoek eerst bij NGINX terecht. Als het om een statisch bestand gaat, kan NGINX dit direct leveren. Voor een PHP-script geeft NGINX de benodigde FastCGI-parameters door aan een PHP-FPM-pool; een beschikbare worker voert de code uit en stuurt het antwoord terug via NGINX. De poolgrootte en de procesmodus van PHP-FPM worden geregeld via configuratiebestanden in php.ini-formaat.

Unit was daarentegen een Applicatieserver met listeners, routes, statische levering en uitvoeringstijden per taal in één JSON-configuratiemodel. Een PHP-toepassing wordt daar als toepassingstype geïntegreerd; Unit kan zo het verzoektraject binnen hetzelfde platform in kaart brengen, vanaf de ontvangst tot aan de PHP-uitvoering. Dit vermindert niet automatisch het operationele risico, maar verandert wel de verantwoordelijkheidsgrenzen.

Unit is daarom geen „NGINX met ingebedde PHP-FPM“. Bij het bouwen van de PHP-module ontstaat een eigen SAPI-module die is gekoppeld aan de PHP-Embed-bibliotheek. Bij analyse en migratie moeten teams daarom niet alleen FastCGI-instellingen overzetten, maar ook routing, applicatiedefinities, modulekoppelingen en diagnosepaden opnieuw toewijzen. Fouten kunnen niet zonder meer worden toegeschreven aan een upstream-webserver of een afzonderlijke FPM-pool.

PHP-modules, versies en configuratielimieten

Voor PHP is bij een Unit-installatie naast de kern ook een bijbehorende taalmodule nodig. Deze module is gekoppeld aan de gebruikte PHP-versie en de Unit-installatie. Als er geen geschikte pakketten voor het besturingssysteem en de PHP-versie beschikbaar waren, werd in de documentatie beschreven hoe men zelf een installatie kon bouwen met een PHP-installatie die de Embed-SAPI ondersteunt. Dit vergroot de inspanning voor updates, reproduceerbare builds en foutanalyse aanzienlijk.

Ook de configuratie volgt verschillende modellen. Unit bundelt listeners, routes en applicaties als JSON-gegevens via zijn configuratie-interface. PHP-FPM beheert pools daarentegen in bestanden in het php.ini-formaat. Dit verschil gaat verder dan alleen de syntaxis: in een FPM-stack staan webserverregels en PHP-pooldefinities los van elkaar, terwijl Unit beide nauwer met elkaar verbindt binnen één platform. Bij migratieplannen moet rekening worden gehouden met deze structuur.

Voor PHP-richtlijnen maakt Unit onderscheid tussen de volgende gebieden admin en gebruiker. Admin-opties komen overeen met PHP_INI_SYSTEM en kunnen tijdens de uitvoering niet door de toepassing worden gewijzigd; gebruikersopties komen overeen met PHP_INI_USER. Unit breidt daarmee echter het toegestane bereik van een PHP-richtlijn niet uit. Of een instelling op deze manier mag worden ingesteld of door applicatiecode mag worden gewijzigd, wordt nog steeds bepaald door de PHP-configuratiemodus.

Waarschuwing: De in Unit 1.35.0 vermelde compatibiliteit met PHP 8.5 geeft alleen aan dat deze versie wordt ondersteund in de laatste stabiele release. Dit is geen toezegging voor toekomstige beveiligingsupdates of aanpassingen aan de Unit-PHP-module. Voor bestaande systemen moeten daarom de exacte Unit-tag, de PHP-versie, de herkomst van de module en een getest migratietraject als onderling samenhangende afhankelijkheden worden gedocumenteerd.

PHP-routing en Front Controller configureren

Een unit-configuratie koppelt een listener aan routes en een applicatie. Voor een lokale demo kan de listener uitsluitend worden gekoppeld aan 127.0.0.1:8080 luisteren. Een route probeert eerst het opgevraagde bestand te vinden onder /srv/example-app/public statisch te leveren. PHP-bestanden worden via de MIME-type-uitsluiting van deze levering uitgesloten en doorgestuurd naar de PHP-toepassing; hetzelfde geldt voor niet-bestaande bestanden. Zo blijven openbare bestanden en de uitvoering van de toepassing als afzonderlijke stappen traceerbaar.

In de toepassing wordt root de documentmap vast, terwijl type: php de PHP-runtime selecteert. Met script: index.php wordt elk verzoek dat naar de applicatie wordt doorgestuurd, naar dit script geleid. Dit komt overeen met de Front-controller van veel PHP-frameworks: de applicatie analyseert zelf het oorspronkelijke pad en bepaalt bijvoorbeeld welke controller of foutpagina wordt weergegeven.

Zonder de instelling script verwerkt op URI gebaseerde scriptpaden. Dit kan geschikt zijn voor oudere toepassingen waarbij PHP-bestanden rechtstreeks moeten worden aangeroepen, maar vereist een zorgvuldige beperking van de bereikbare paden. targets maken bovendien deelgebieden mogelijk met afwijkend root-, script- of index-gedrag. Ze vormen daarom geen vervanging voor routing, maar een mogelijkheid om meerdere toepassingsregels gericht te definiëren.

Het volgende voorbeeld is een JSON-bestandsconfiguratie voor een lokale demo, niet voor een openbare dienst. Het bevat geen domeinnamen, TLS-gegevens of toegangsgegevens. Voordat je dit overneemt, moet je de bestandsrechten, de daadwerkelijk geïnstalleerde PHP-ondersteuning en de voor Unit bedoelde methode voor het importeren van de configuratie controleren.

{
  "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"
    }
  }
}

De volgorde is bepalend: de statische levering De share-stap wordt vóór de fallback uitgevoerd, maar sluit PHP-bestanden uitdrukkelijk uit. Deze verzoeken en niet-bestaande bestanden komen terecht bij index.php; daardoor werken ook sprekende URL’s zoals /artikel/beispiel zonder een bestand met dezelfde naam. Of er aanvullende regels nodig zijn voor uploadmappen, beheergebieden of direct toegankelijke PHP-bestanden, hangt af van de betreffende toepassing en mag niet algemeen worden afgeleid uit deze demo.

Procesmodellen en RAM-budget vergelijken

PHP-FPM regelt het aantal workers per pool via de modi static, dynamic en ondemand. Bij Unit wordt het procesnummer daarentegen binnen de toepassing gemodelleerd. Een dynamische Unit-configuratie beperkt met processes.max het totale aantal en houdt gelijke tred met processes.spare Leegloopprocessen; idle_timeout ruimt overtollige, inactieve processen op.

De termen zijn daarom niet één-op-één uitwisselbaar. Met name een gedocumenteerde standaardinstelling is geen geschikte waarde voor een website. Zowel pm.max_children en ook processes.max beperken het aantal gelijktijdige PHP-processen en kunnen bij te lage waarden wachtrijen veroorzaken. Te hoge waarden leiden daarentegen tot concurrentie om het werkgeheugen met het besturingssysteem, de database, de cache en andere diensten.

A RAM-budget is in eerste instantie slechts een planningsmodel: van de totale opslagruimte worden reserves voor het besturingssysteem, de database, de cache en andere processen afgetrokken. De resterende waarde wordt gedeeld door een conservatief geschatte geheugenbehoefte per PHP-worker. Bij wijze van voorbeeld levert 1.200 MiB voor PHP, gedeeld door 120 MiB per worker, rekenkundig tien workers op; beide waarden zijn bewust gekozen plaatshouders, geen meting of configuratieaanbeveling.

Het resultaat is een Bovengrens en een uitgangspunt voor observatie, niet de juiste instelling. Doorslaggevend zijn de werkelijke piekwaarden, wachtrijen, antwoordfouten en het geheugengebruik bij zowel normale als hoge belasting. Voor de methodische afleiding en het bijstellen van pm.max_children het interne artikel helpt Het juiste aantal PHP-FPM-processen berekenen. Bij Unit geldt hetzelfde principe, ook al hebben de parameters andere namen.

Waarschuwing: het vaststellen van proceslimieten door simpelweg cijfers van anderen over te nemen, leidt er vaak alleen maar toe dat problemen worden uitgesteld. Pas een afgebakend geheugenbudget en voortdurende monitoring laten zien of een bovengrens voor het aantal workers past bij de toepassing, de uitbreidingen daarvan en de diensten die tegelijkertijd worden uitgevoerd.

Bedrijfsmodellen voor PHP-hosting beoordelen

De tabel geeft een overzicht van architecturen, niet van snelheid of geheugengebruik. Het belangrijkste argument voor nieuwe PHP-hosting met de NGINX-PHP-FPM-opzet is de duidelijke scheiding: de webserver verwerkt HTTP, proxying en statische inhoud, terwijl PHP-FPM de PHP-workers per pool beheert. Deze verantwoordelijkheden maken het gemakkelijker om configuraties, foutmeldingen en updates afzonderlijk te beoordelen.

Unit kon listeners, routing, statische bestanden en applicaties in één platform bundelen en naast PHP ook andere runtime-omgevingen ondersteunen. Deze meertalige aanpak kan verklaren waarom een bestaande omgeving voor Unit heeft gekozen. Voor uitsluitend op PHP gebaseerde oplossingen is dit echter geen automatisch voordeel: het vervangt noch de beoordeling van de benodigde functies, noch de toetsing of het team de andere configuratie- en bedrijfslogica op de lange termijn onder de knie kan krijgen.

Bij Unit 1.35.0 moet de technische functionaliteit van de Onderhoudsstatus moeten worden gescheiden. De releasedatum geeft de gepubliceerde versie en de bijbehorende wijzigingen aan; hieruit volgt dat het inmiddels gearchiveerde project niet verder wordt onderhouden. Bij een nieuwe beslissing weegt deze grens zwaarder dan een kleiner aantal zichtbare componenten. Voor een bestaande installatie is het daarentegen aanleiding om afhankelijkheden en een migratietraject te documenteren.

Apache met PHP-FPM is niet per definitie een beter of slechter alternatief, maar een optie wanneer er specifieke Apache-vereisten zijn. De keuze moet worden gebaseerd op onderhoudbaarheid, beschikbare PHP-versies, patchprocessen, kennis binnen het team en het noodplan. Zonder vergelijkbare belastingprofielen en gedocumenteerde meetmethodiek kan uit dit architectuuroverzicht geen betrouwbare prestatierangorde worden afgeleid.

De unit veilig in gebruik houden

Een bestaande Unit-installatie moet in eerste instantie worden geregistreerd als een bestaand systeem, en niet als sjabloon voor een nieuw platform. De daadwerkelijk gebruikte versie, de gekoppelde applicaties en hun afhankelijkheden zijn hierbij doorslaggevend. Het feit dat Unit technisch nog steeds uitvoerbaar is, verandert niets aan het feit dat het project is gearchiveerd; de exploitatie en de vervanging moeten daarom gezamenlijk worden gepland.

Bij WordPress, Joomla of Drupal is de Front-controller Het belangrijkste punt: paden waarvoor geen bestand bestaat, moeten naar het centrale PHP-startbestand worden doorgestuurd, terwijl bestaande bestanden direct kunnen worden geleverd. De WordPress-handleiding voor Unit illustreert dit routeringsprincipe, inclusief de afhandeling van PHP-bestanden en /wp-admin/. Voor een bestaand CMS kan dit een logische configuratie zijn; voor een nieuwe installatie leidt dit echter niet tot een aanbeveling voor Unit.

Meerdere kleine applicaties met PHP, Python, Ruby of Node.js konden met Unit listeners, routes en runtime-omgevingen op één gemeenschappelijk platform worden gebundeld. Dat zou kunnen verklaren waarom destijds voor Unit is gekozen. Bij pure PHP-hosting is deze ondersteuning voor meerdere talen echter geen doel op zich: afzonderlijke, goed onderhouden componenten kunnen op de lange termijn beter te onderhouden zijn, ondanks de extra interfaces.

Een bevroren container-implementatie vereist een bijzonder nauwkeurige inventarisatie. Documenteer hiervoor de exacte unit-tag, de PHP-versie, de geïnstalleerde taalmodule, de basisimage en de volledige configuratie. Vermeld daarnaast de bronnen voor images en pakketten, het patchproces en een getest migratie- en uitwijkpad. PHP-compatibiliteit van een bepaalde unit-release is daarbij geen garantie dat de bijbehorende module in de toekomst beveiligingsupdates zal ontvangen.

NGINX kan vóór Unit staan, bijvoorbeeld wanneer een bestaande NGINX-laag behouden moet blijven of wanneer verzoeken doelgericht worden doorgeschakeld. De Unit-documentatie noemt deze integratie ook in verband met het beveiligen van de control socket. Het lost de 'gearchiveerde' status echter niet op en creëert een extra dienst met een eigen configuratie, logboekregistratie en verantwoordelijkheid voor updates. Het nut moet daarom concreet worden afgewogen tegen deze operationele kosten.

Time-outs, logbestanden en vastgelopen processen

Procesgrenzen zijn geen foutdiagnose. Met limits.requests Unit kan een applicatieproces vervangen nadat een bepaald aantal verzoeken is verwerkt. Dit kan het cumulatieve geheugengebruik in de tijd beperken, maar lost noch geheugenlekken, noch te grote gegevensstructuren, noch blokkerende externe aanroepen op. Een regelmatige herstart mag daarom niet worden beschouwd als bewijs van stabiele applicatiecode.

Met limits.timeout Unit beëindigt een verzoek na het verstrijken van de geconfigureerde tijd met een HTTP 503-statuscode. Dit is een zichtbare beveiligingsgrens voor individuele verzoeken, maar biedt geen volledige bescherming tegen vastgelopen workers: volgens de documentatie herkent Unit vastgelopen processen niet; deze kunnen in de procespool blijven zitten. Een langere time-out stelt dit probleem alleen maar uit, terwijl een kortere time-out normaal gesproken trage processen kan afbreken.

• Registreer de HTTP-status, de betrokken paden, het tijdsbestek en de frequentie voordat de drempelwaarden worden gewijzigd.
• Voeg toegangs-, fout- en applicatielogboeken samen op basis van tijdstempels; bij PHP-FPM kan een slowlog aanvullende stack-informatie opleveren.
• Controleer de CPU, het werkgeheugen, de I/O, de netwerkverbindingen en de status en het aantal processen.
• Onderzoek vervolgens de code, databasequery's, toegang tot het bestandssysteem en externe diensten als mogelijke oorzaken.
• Pas wanneer de oorzaak en het belastingsprofiel bekend zijn, moeten time-outs, proceslimieten of herstartregels gericht worden aangepast.

Een HTTP 503-fout kan dus wijzen op een overschreden tijdslimiet, maar kan ook worden veroorzaakt door upstream-componenten of andere fouten. Terugkerende lange PHP-verzoeken moet je niet alleen aanpakken door het aantal workers aan te passen. De handleiding voor de PHP-FPM-slowlog en analyse van de oorzaken van trage verzoeken laat zien hoe stacktraces aan verzoekgegevens kunnen worden gekoppeld; dezelfde oorzaak-gevolg-logica is ook nuttig bij een analyse van de unit-voorraad.

Symptomen zonder duidelijke oorzaak zijn bijzonder kritiek: toenemende wachttijden, processen die voortdurend bezet zijn of het uitblijven van logboekvoortgang. In dat geval zijn de processtatus en afhankelijkheden belangrijker dan een algemene verlenging van de time-out. Controleer bijvoorbeeld of een PHP-worker wacht op database-, DNS-, bestandssysteem- of netwerk-I/O. Pas de concrete blokkade bepaalt of een code-fix, een aanpassing van de resources of een gecontroleerde herstart gepast is.

Keuze voor nieuwe en oude systemen

Voor nieuwe PHP-hostingomgevingen is een goed onderhouden webserver met PHP-FPM de meest logische standaardkeuze. PHP-FPM maakt deel uit van de standaard PHP-distributie en biedt gedocumenteerde opties voor pool- en procesbeheer. Bij Unit verschuift de vraag echter van pure functionaliteit naar onderhoudbaarheid: de installatie kan blijven draaien, maar de gearchiveerde projectstatus verhoogt het risico op een langdurige afhankelijkheid.

Voor bestaande unit-systemen begint een weloverwogen beslissing met een inventarisatie. Controleer de onderhoudsstatus en de patchbaarheid van het besturingssysteem, PHP en de basisimage, de compatibiliteit van de geïnstalleerde taalmodule, de aanwezige operationele kennis en de gekoppelde diensten. Even belangrijk zijn exporteerbare configuraties, een reproduceerbare rollback en een doelsysteem waarnaar routing, PHP-instellingen en implementaties stapsgewijs kunnen worden overgezet.

Voor een migratie is geen willekeurige, algemeen geldende termijn nodig, maar wel een volgorde op basis van prioriteit. Applicaties die in contact staan met het internet, images die niet kunnen worden bijgewerkt, modules waarvan de herkomst onduidelijk is en bedrijfskritische applicaties zonder noodplan verdienen als eerste aandacht. Daarna kunnen applicaties worden gegroepeerd op basis van complexiteit en afhankelijkheden. Parallel gebruik tijdens een gecontroleerde overgang kan risico’s verminderen, mits gegevensopslag, sessies en de terugkeerprocedure vooraf zijn gedefinieerd.

De Control API is een administratieve toegang en geen gewoon eindpunt van een website. Unit documenteert voor u een Unix-domain-socket en motiveert het gebruik ervan met veiligheidsaspecten. Stel restrictieve bestandsrechten en duidelijk afgebakende beheerdersrechten in; openbare toegankelijkheid zou aanvallers bij succesvolle toegang uitgebreide mogelijkheden bieden om de configuratie te wijzigen.

Het praktische migratietraject houdt niet op bij een nieuwe procesconfiguratie. Importeer per toepassing de PHP-versie, extensies, omgevingsvariabelen, bestandsrechten, routeringsregels en observeerbaarheid in het doelsysteem. Vergelijk daarbij de verwachte antwoorden en foutgevallen in plaats van algemene conclusies over de snelheid te trekken. Zo wordt van een onvoorziene erfenis uit het verleden een gedocumenteerde Vervangingsstrategie met begrijpelijke technische keuzes.