NGINX Unit : une alternative à PHP-FPM ? Architecture, risques et cas d'utilisation

Statut « archivé » et bref verdict clair

Au 30 septembre 2026, le verdict est sans appel : Unité NGINX Il permettait d'exécuter directement des applications PHP tout en acceptant des connexions HTTP, en terminant les connexions TLS, en servant des fichiers statiques et en acheminant les requêtes. Ses fonctionnalités dépassaient ainsi largement celles de PHP-FPM. Unit n'est toutefois pas recommandé de manière générale pour les nouvelles plateformes d'hébergement PHP en production, car le projet officiel est archivé depuis octobre 2025 et n'est plus maintenu.

Cela ne signifie pas pour autant qu'une installation Unit existante deviendrait immédiatement inutilisable. Elle peut continuer à prendre en charge une application, à condition que ses dépendances, ses mesures de sécurité et une stratégie de migration soient documentées. Un nouvel investissement doit toutefois être évalué différemment : sans maintenance continue du projet, les risques augmentent en matière de failles de sécurité, de disponibilité des paquets, de nouvelles versions du système d'exploitation et de compatibilité future avec PHP.

Il est important de bien distinguer les différentes versions. La documentation d'installation, toujours disponible, mentionne souvent la version 1.34.2, alors que la version stable publiée porte le numéro 1.35.0. Cette version garantit notamment la compatibilité avec PHP 8.5 ; cela n'implique toutefois pas la poursuite de la maintenance. La branche de développement master En raison de son statut « archivé », cette version du produit ne constitue pas une référence pour les décisions opérationnelles.

Distinguer NGINX, PHP-FPM et Unit

Pour prendre une décision éclairée, il faut examiner chaque élément séparément. NGINX Il s'agit d'un serveur web et d'un proxy inverse : il reçoit les requêtes HTTP, peut servir du contenu statique et redirige les requêtes dynamiques. PHP-FPM, en revanche, est un gestionnaire de processus FastCGI. Il met à disposition des workers PHP, mais ne se charge pas lui-même des tâches typiques d'un serveur web, à savoir la réception et le routage des requêtes HTTP.

Dans une architecture classique, une requête parvient d’abord à NGINX. S’il s’agit d’un fichier statique, NGINX peut le servir immédiatement. Pour un script PHP, NGINX transmet les paramètres FastCGI nécessaires à un pool PHP-FPM ; un worker disponible exécute le code et renvoie la réponse via NGINX. La taille du pool et le mode de traitement sont contrôlés dans PHP-FPM via des fichiers de configuration au format php.ini.

Unit, en revanche, était un Serveur d'applications avec des écouteurs, des routes, une distribution statique et des durées d'exécution par langue dans un modèle de configuration JSON. Une application PHP y est intégrée en tant que type d'application ; Unit peut ainsi cartographier le parcours de la requête au sein de la même plateforme, depuis sa réception jusqu'à l'exécution du code PHP. Cela ne réduit pas automatiquement le risque opérationnel, mais modifie les limites des responsabilités.

Unit n'est donc pas „ NGINX avec PHP-FPM intégré “. Lors de la compilation du module PHP, un module SAPI distinct est créé, lié à la bibliothèque PHP-Embed. Lors de l’analyse et de la migration, les équipes doivent donc non seulement transférer les paramètres FastCGI, mais aussi remapper le routage, les définitions d’applications, les liaisons de modules et les chemins de diagnostic. Les erreurs ne peuvent pas être attribuées de manière générale à un serveur web en amont ou à un pool FPM distinct.

Modules PHP, versions et limites de configuration

Pour PHP, une installation d'Unit nécessite, outre le noyau, un module de langage adapté. Ce module est lié à la version de PHP utilisée et à l'installation d'Unit. Si aucun paquet adapté au système d’exploitation et à la version de PHP n’était disponible, la documentation décrivait une méthode de compilation manuelle à partir d’une installation PHP fournissant la SAPI Embed. Cela alourdit considérablement la charge de travail liée aux mises à jour, aux compilations reproductibles et à l’analyse des erreurs.

La configuration suit également des modèles différents. Unit regroupe les écouteurs, les routes et les applications sous forme de données JSON via son interface de configuration. PHP-FPM, en revanche, gère les pools dans des fichiers au format php.ini. Cette différence va au-delà de la simple syntaxe : dans une pile FPM, les règles du serveur web et les définitions des pools PHP sont séparées, tandis qu’Unit relie plus étroitement ces deux éléments au sein d’une même plateforme. Les stratégies de migration doivent tenir compte de cette structure.

Pour les directives PHP, Unit distingue les zones suivantes : admin et utilisateur. Les options « admin » correspondent à PHP_INI_SYSTEM et ne peuvent pas être modifiées par l'application lors de l'exécution ; les options « user » correspondent à PHP_INI_USER. Unit n'étend toutefois pas la plage autorisée d'une directive PHP. C’est toujours le mode de configuration PHP qui détermine si un paramètre peut être défini de cette manière ou modifié par le code de l’application.

Avertissement : la compatibilité avec PHP 8.5 indiquée dans Unit 1.35.0 atteste uniquement de la prise en charge de cette version dans la dernière version stable. Elle ne constitue en aucun cas une garantie quant aux futurs correctifs de sécurité ou aux adaptations du module PHP d'Unit. Pour l'exploitation en production, il convient donc de documenter de manière cohérente la date exacte de la version d'Unit, la version de PHP, la provenance du module et un chemin de migration testé en tant que dépendances interdépendantes.

Configurer le routage PHP et le contrôleur frontal

Une configuration d'unité relie un écouteur à des routes et à une application. Pour une démonstration locale, l'écouteur peut être configuré exclusivement sur 127.0.0.1:8080 écouter. Une route tente d'abord de trouver le fichier demandé sous /srv/example-app/public à servir de manière statique. Les fichiers PHP sont exclus de cette distribution grâce à l'exclusion par type MIME et sont transmis à l'application PHP ; il en va de même pour les fichiers inexistants. Ainsi, les fichiers publics et l'exécution de l'application restent traçables en tant qu'étapes distinctes.

Dans l'application, on définit root définit le répertoire des documents, tandis que type: php qui sélectionne le moteur d'exécution PHP. Avec script: index.php chaque requête transmise à l'application est redirigée vers ce script. Cela correspond à la Contrôleur avant de nombreux frameworks PHP : l'application analyse elle-même le chemin d'accès d'origine et détermine, par exemple, le contrôleur ou la page d'erreur à afficher.

Sans cette attitude script traite les chemins d'accès aux scripts basés sur l'URI. Cela peut convenir aux applications plus anciennes dont les fichiers PHP doivent être appelés directement, mais nécessite de limiter soigneusement les chemins d'accès autorisés. targets permettent en outre de définir des sous-domaines présentant un comportement différent en matière de « root », de « script » ou d’« index ». Elles ne remplacent donc pas le routage, mais constituent un moyen de définir de manière ciblée plusieurs règles d’application.

L'exemple suivant est un fichier de configuration JSON destiné à une démonstration locale, et non à un service public. Il ne contient ni nom de domaine, ni informations TLS, ni identifiants d'accès. Avant de l'utiliser, il convient de vérifier les droits d'accès au fichier, la prise en charge effective de PHP et la méthode prévue par Unit pour l'importation de la configuration.

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

L'ordre est déterminant : le livraison statique L'étape « share » est tentée avant le fallback, mais exclut expressément les fichiers PHP. Ces requêtes et les fichiers inexistants sont redirigés vers index.php; cela permet également aux URL « parlantes » de fonctionner, comme par exemple /artikel/beispiel sans fichier du même nom. La nécessité de règles supplémentaires pour les répertoires de téléchargement, les zones d'administration ou les fichiers PHP directement accessibles dépend de l'application concernée et ne doit pas être déduite de manière générale à partir de cette démo.

Comparer les modèles de processus et le budget RAM

PHP-FPM gère les workers par pool via les modes static, dynamic et ondemand. Avec Unit, en revanche, le nombre de processus est modélisé au sein même de l'application. Une configuration dynamique d'Unit limite avec processes.max le nombre total et suit le rythme 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 ainsi que 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.

A 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 Plafond 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.

Évaluer les modèles d'exploitation pour l'hébergement PHP

Le tableau classe les architectures, et non la vitesse ou la consommation de mémoire. Dans le cas de l'architecture NGINX-PHP-FPM, l'argument principal en faveur d'un nouvel hébergement PHP réside avant tout dans la séparation claire des tâches : le serveur web gère le protocole HTTP, la mise en proxy et les contenus statiques, tandis que PHP-FPM gère les workers PHP par pool. Cette répartition des responsabilités facilite l'évaluation séparée des configurations, des problèmes et des mises à jour.

Unit a permis de regrouper les écouteurs, le routage, les fichiers statiques et les applications au sein d'une seule et même plateforme, tout en prenant en charge d'autres environnements d'exécution en plus de PHP. Cette approche multilingue peut expliquer pourquoi un environnement existant a choisi Unit. Pour les offres exclusivement basées sur PHP, cela ne constitue toutefois pas un avantage automatique : cela ne remplace ni l'évaluation des fonctionnalités requises, ni la vérification de la capacité de l'équipe à maîtriser durablement les autres logiques de configuration et d'exploitation.

Pour l'unité 1.35.0, l'étendue des fonctionnalités techniques doit être définie par le Wartungsstatus être séparés. La date de publication indique la version publiée et les modifications qu'elle comporte ; cela implique qu'aucune maintenance supplémentaire ne sera effectuée sur le projet, désormais archivé. Pour une nouvelle décision, cette limite pèse plus lourd qu'un nombre réduit de composants visibles. Pour une installation existante, en revanche, elle constitue une occasion de documenter les dépendances et la procédure de migration.

Apache avec PHP-FPM n'est pas une alternative systématiquement meilleure ou pire, mais une option à envisager lorsque des exigences liées à Apache sont déjà en place. Le choix doit s'appuyer sur la facilité de maintenance, les versions de PHP disponibles, les processus de correction, les compétences de l'équipe et le plan de secours. En l'absence de profils de charge comparables et d'une méthodologie de mesure documentée, il n'est pas possible d'établir un classement fiable des performances à partir de cette vue d'ensemble de l'architecture.

Assurer le bon fonctionnement de l'unité dans le parc

Une installation Unit existante doit d'abord être répertoriée comme système existant, et non comme modèle pour une nouvelle plateforme. Les éléments déterminants sont la version effectivement utilisée, les applications connectées et leurs dépendances. Le fait qu’Unit reste techniquement opérationnel ne change rien au fait que le projet a été archivé ; son exploitation et son remplacement doivent donc être planifiés conjointement.

Avec WordPress, Joomla ou Drupal, le Contrôleur avant Le point essentiel : les chemins d'accès qui ne correspondent pas à des fichiers existants doivent être redirigés vers le fichier d'entrée PHP central, tandis que les fichiers existants peuvent être servis directement. Le guide WordPress consacré à Unit illustre ce principe de routage, y compris la gestion des fichiers PHP et /wp-admin/. Pour un CMS existant, cette configuration peut se comprendre ; pour une nouvelle installation, cela ne constitue toutefois pas une recommandation pour Unit.

Plusieurs petites applications développées en PHP, Python, Ruby ou Node.js ont pu être regroupées au sein d'une plateforme commune grâce à Unit Listener, aux routes et aux environnements d'exécution. Cela peut expliquer pourquoi une architecture existante avait opté pour Unit à l'époque. Dans le cas d'un hébergement exclusivement PHP, cette polyvalence n'est toutefois pas une fin en soi : des composants distincts et bien entretenus peuvent, à long terme, être plus faciles à maintenir malgré des interfaces supplémentaires.

Le déploiement d'un conteneur figé nécessite un inventaire particulièrement précis. Pour cela, documentez l'identifiant exact de l'unité, la version de PHP, le module de langue installé, l'image de base et la configuration complète. Ajoutez également les sources des images et des paquets, le processus de correction, ainsi qu’un plan de migration et de repli testé. La compatibilité PHP d’une version spécifique d’Unit ne garantit pas que le module correspondant bénéficiera à l’avenir de correctifs de sécurité.

NGINX peut être placé en amont d'Unit, par exemple lorsqu'il s'agit de conserver une couche NGINX existante ou de rediriger de manière ciblée certains accès. La documentation d’Unit mentionne également cette intégration dans le cadre de la sécurisation du Control Socket. Elle ne résout toutefois pas le problème du statut « archivé » et crée un service supplémentaire avec sa propre configuration, sa propre journalisation et sa propre gestion des mises à jour. Il convient donc d’évaluer concrètement les avantages par rapport à cette charge opérationnelle.

Délais d'expiration, journaux et processus bloqués

Les limites de processus ne constituent pas un diagnostic d'erreur. Avec limits.requests Unit peut remplacer un processus d'application après un nombre défini de requêtes traitées. Cela permet de limiter dans le temps l'utilisation cumulée de la mémoire, mais ne résout ni les fuites de mémoire, ni les structures de données trop volumineuses, ni les appels externes bloquants. Un redémarrage régulier ne doit donc pas être considéré comme la preuve d’un code d’application stable.

Avec limits.timeout Unit interrompt une requête avec un code HTTP 503 à l'expiration du délai configuré. Il s'agit d'une limite de protection visible pour les requêtes individuelles, mais pas d'une protection complète contre les workers bloqués : selon la documentation, Unit ne détecte pas les processus bloqués ; ceux-ci peuvent rester dans le pool de processus. Un délai d'expiration plus long ne fait que repousser ce problème, tandis qu'un délai plus court peut interrompre des opérations normalement lentes.

• Recenser les statuts HTTP, les chemins concernés, les plages horaires et la fréquence avant de modifier les seuils.
• Regroupez les journaux d'accès, d'erreurs et d'application en fonction des horodatages ; avec PHP-FPM, un « slowlog » peut fournir des informations supplémentaires sur la pile d'appel.
• Vérifier le processeur, la mémoire vive, les E/S, les connexions réseau ainsi que l'état et le nombre de processus.
• Examinez ensuite le code, les requêtes de base de données, les accès au système de fichiers et les services externes pour identifier les causes possibles.
• Ce n'est qu'une fois que la cause et le profil de charge sont connus qu'il convient d'ajuster de manière ciblée les délais d'expiration, les limites de processus ou les règles de redémarrage.

Un code HTTP 503 peut donc indiquer un dépassement du délai d'attente, mais il peut également être dû à des composants en amont ou à d'autres erreurs. Il ne faut pas traiter les requêtes PHP longues et récurrentes uniquement en jouant sur le nombre de workers. Le guide sur le Le Slowlog de PHP-FPM et l'analyse des causes des requêtes lentes montre comment associer les traces de pile aux données de requête ; cette même logique de cause à effet s'applique également à l'analyse de l'état des unités.

Les symptômes sans conclusion claire sont particulièrement critiques : allongement des temps d'attente, processus bloqués en permanence ou absence de progression dans les journaux. Dans ce cas, l'état du processus et ses dépendances sont plus importants qu'une augmentation forfaitaire du délai d'expiration. Vérifiez par exemple si un worker PHP attend une opération d’E/S au niveau de la base de données, du DNS, du système de fichiers ou du réseau. Seul le blocage concret permet de déterminer si une correction du code, un ajustement des ressources ou un redémarrage contrôlé est approprié.

Choix entre les nouveaux et les anciens systèmes

Pour les nouveaux environnements d'hébergement PHP, un serveur web bien entretenu avec PHP-FPM constitue le choix par défaut le plus logique. PHP-FPM fait partie de la distribution standard de PHP et offre des options documentées de gestion des pools et des processus. Avec Unit, en revanche, la question ne porte plus uniquement sur la fonctionnalité, mais aussi sur la maintenabilité : l'installation peut continuer à fonctionner, mais le statut « archivé » du projet augmente le risque d'une dépendance à long terme.

Pour les systèmes Unit existants, toute décision objective commence par un état des lieux. Vérifiez l'état de maintenance et la possibilité d'application de correctifs pour le système d'exploitation, PHP et l'image de base, la compatibilité du module linguistique installé, les connaissances opérationnelles disponibles ainsi que les services associés. Les configurations exportables, une restauration reproductible et un système cible vers lequel le routage, les paramètres PHP et les déploiements peuvent être transférés étape par étape revêtent une importance tout aussi grande.

Une migration ne nécessite pas de délai universel arbitraire, mais un ordre de priorité. Les applications exposées à Internet, les images non actualisables, les modules d’origine incertaine et les applications critiques pour l’activité sans plan de secours doivent être traités en priorité. Ensuite, les applications peuvent être regroupées en fonction de leur complexité et de leurs dépendances. Une exploitation en parallèle pendant une migration contrôlée peut réduire les risques, à condition que la gestion des données, les sessions et la procédure de repli aient été définies au préalable.

Le API de contrôle Il s'agit d'un accès administratif et non d'un point d'accès classique à un site web. Unit documente pour vous un socket de domaine Unix et justifie son utilisation par des considérations de sécurité. Définissez des droits d'accès restrictifs aux fichiers et des accès administratifs clairement délimités ; une accessibilité publique offrirait aux attaquants, en cas d'accès réussi, de vastes possibilités de modification de la configuration.

Le parcours de migration pratique ne s'arrête pas à une nouvelle configuration des processus. Transférez, application par application, la version PHP, les extensions, les variables d’environnement, les droits d’accès aux fichiers, les règles de routage et la capacité de surveillance vers le système cible. Comparez les réponses attendues et les cas d’erreur plutôt que de tirer des conclusions générales sur les performances. Ainsi, un héritage imprévu se transforme en un élément documenté stratégie de remplacement avec des choix techniques justifiés.