Partie 9 — Déployer Node / Next.js
⏱️ TL;DR — C’est la partie que tu attendais. Ton app Next.js tourne en local (
npm run dev), le VPS est provisionné, durci, joignable en HTTPS derrière Nginx. Il reste à y faire tourner ton app pour de vrai. On installe Node LTS, on récupère le code, on builde en prod (next build), on lance (next start) — puis on fait tourner tout ça comme un service qui redémarre au boot et après un crash (systemd, avec PM2 en alternative honnête). On met Nginx en façade devant Next, et on apprend à déployer une nouvelle version sans coupure et à lire les logs. À la fin,formacampus.frsert un front Next.js en production, en service, en HTTPS — sans Vercel, sans magie.
Le problème qu’on résout
En local, tu tapes npm run dev et tout marche : hot reload, port 3000, un terminal ouvert. La prod, c’est l’inverse de ça. Personne ne va laisser un npm run dev tourner dans un tmux oublié. Il faut :
- un Node installé proprement sur le serveur (pas ta version de dev) ;
- un build de production (
next build), optimisé, minifié, figé — pas le mode dev ; - un process qui survit : à ta déconnexion SSH, au reboot du VPS, à un crash de l’app ;
- une façade Nginx qui reçoit le trafic public en HTTPS et le relaie à Next sur son port privé ;
- une manière de livrer une nouvelle version sans afficher une page blanche à tes visiteurs.
Rien de sorcier, mais chaque maillon a ses pièges : la variable NEXT_PUBLIC_ qui fuite un secret, le npm install qui casse le build reproductible, l’oubli de enable qui fait qu’au reboot ton site ne remonte pas. Cette partie te donne les gestes sûrs, dans l’ordre.
Ce que tu sauras faire à la fin de cette partie
- Installer Node LTS sur un serveur (NodeSource ou nvm) et gérer
npm/pnpm/yarnvia corepack. - Récupérer ton code (
git clone, branche de prod), installer les deps avecnpm ci(et savoir pourquoiciet pasinstall). - Gérer les variables d’environnement en prod, et ne jamais exposer un secret via
NEXT_PUBLIC_. - Builder (
next build), démarrer (next start), et choisir entre SSR, export statique etoutput: 'standalone'. - Faire tourner Next comme un service systemd (
formacampus-web) qui redémarre au boot et après un crash. - Décider entre systemd et PM2 en connaissance de cause.
- Écrire le server block Nginx complet devant Next (headers,
X-Forwarded-Proto, cache du statique, uploads). - Déployer sans coupure, brancher un healthcheck, lire les logs applicatifs, et savoir quand un VPS bat Vercel (et l’inverse).
Les chapitres
| # | Chapitre | En un mot |
|---|---|---|
| 9.1 | Build de prod Next.js | Node LTS, git clone, npm ci, env, next build, standalone, SSG. |
| 9.2 | systemd pour Node | Le unit formacampus-web.service, enable --now, Restart=always. |
| 9.3 | PM2, l’alternative | ecosystem.config.js, pm2 startup, cluster — systemd vs PM2. |
| 9.4 | Nginx devant Next | proxy_pass, X-Forwarded-Proto, /_next/static, plusieurs apps. |
| 9.5 | Zéro-downtime & logs | reload vs restart, healthcheck, logs, checklist de déploiement. |
Cette partie te rend opérationnel sur le déploiement Node/Next manuel. La Partie 10 — Autres stacks (PHP, Symfony, WP…) fera le même travail pour l’API Symfony de FormaCampus et les stacks PHP, avant de brancher la base en Partie 11 et d’automatiser tout ça en Partie 13 — CI/CD.
On commence : Build de prod Next.js — de Node installé au premier next start qui répond.