Partie 10 — Autres stacks (PHP, Symfony, WordPress, statique, Python)
⏱️ TL;DR — Tu as appris à déployer Node/Next.js derrière Nginx en Partie 9. Bonne nouvelle : c’est le même schéma partout. Une app en prod, quelle que soit sa techno, se résume à un process qui écoute en local + Nginx en façade qui reçoit le trafic public et le relaie. Cette partie décline ce patron sur les stacks que tu croiseras : PHP-FPM (le moteur PHP moderne, en FastCGI derrière Nginx), Symfony en prod, WordPress sur VPS, les sites statiques et SPA (le cas le plus simple : Nginx tout seul), et Python (
gunicorn/uvicornderrière Nginx) — qui sert de prétexte pour formuler le pattern générique valable aussi pour Go, Ruby, Rust… À la fin, tu ne mémorises pas 15 recettes : tu comprends un modèle que tu adaptes à n’importe quoi.
Le problème qu’on résout
Le web n’est pas fait que de Next.js. Un jour tu reprends une API Symfony, le lendemain un WordPress client, la semaine d’après un back Django ou un site Astro statique. Faut-il tout réapprendre à chaque fois ? Non. Les débutants croient qu’« héberger du PHP », « héberger du Python » et « héberger du Node » sont trois savoir-faire séparés. C’est faux. Ce sont trois variantes d’une seule idée.
L’idée, tu la connais déjà depuis la Partie 7 : Nginx en façade, l’app en local. Ce qui change d’une stack à l’autre, c’est uniquement comment l’app locale tourne et comment Nginx lui parle : en HTTP proxifié (Node, Python), en FastCGI (PHP-FPM), ou pas du tout parce qu’il n’y a rien à faire tourner (statique). Cette partie te fait voir le motif commun sous les cas particuliers.
L’idée directrice : « app derrière Nginx », partout
Retiens ce schéma. On le remplira stack par stack.
Trois façons pour Nginx de traiter une requête, une seule façade :
- Proxy HTTP (
proxy_pass) → pour tout ce qui parle HTTP en local : Node, Next, gunicorn/uvicorn (Python), puma (Ruby), un binaire Go… - FastCGI (
fastcgi_pass) → pour PHP, via PHP-FPM. PHP ne « tourne » pas comme un serveur HTTP autonome : Nginx lui parle un protocole dédié, FastCGI. - Fichiers servis directement → pour le statique et les SPA : Nginx lit les fichiers sur le disque, aucune app ne tourne. Le plus simple et le plus robuste.
Ce que tu sauras faire à la fin de cette partie
- Faire tourner du PHP en prod avec PHP-FPM derrière Nginx (le socket, le server block FastCGI, les pools, OPcache).
- Déployer une application Symfony en mode
prodproprement (cache, permissions devar/, document root surpublic/, OPcache, migrations). - Mettre un WordPress en production sur une pile LEMP : base MySQL dédiée, permissions de fichiers saines, server block correct, durcissement.
- Servir un site 100 % statique ou une SPA avec Nginx seul, cache des assets et fallback de routing.
- Reconnaître le pattern générique (process local + reverse proxy) et l’appliquer à Python — et par extension à n’importe quelle stack.
Les chapitres
| # | Chapitre | En un mot |
|---|---|---|
| 10.1 | PHP-FPM | Comment PHP tourne vraiment en prod, en FastCGI derrière Nginx. |
| 10.2 | Symfony en prod | APP_ENV=prod, cache, permissions, public/, OPcache, migrations. |
| 10.3 | WordPress en prod | LEMP, base dédiée, permissions, server block, durcissement, WP-CLI. |
| 10.4 | Statique & SPA | Le cas le plus simple : Nginx seul, try_files, cache immutable. |
| 10.5 | Python & le pattern générique | gunicorn/uvicorn + proxy, et le modèle qui unifie tout. |
Cette partie généralise ce que tu sais déjà : le patron « app derrière Nginx » n’est pas propre à Node, il est universel. Une fois qu’on a fait tourner les apps (Node en Partie 9, les autres stacks ici), il reste à leur donner où stocker leurs données : c’est l’objet de la Partie 11 — Bases de données en prod.
On commence : PHP-FPM.