PM2 vs cluster vs containers — comment nous faisons tourner Node.js en 2026

PM2 était la bonne réponse quand « Node.js en production » signifiait un seul VPS, une clé SSH et un déploiement git pull. Le module cluster marchait bien avant ça pour les équipes qui ne voulaient pas d'un process manager. En 2026, la plupart des services Node en prod tournent en containers dans Kubernetes ou sur un PaaS de containers, et la proposition de valeur de PM2 a largement disparu — l'orchestrateur gère restart, autoscaling et déploiements sans downtime.

Mais « largement » n'est pas « toujours ». Il y a encore des charges où PM2 est réellement le bon outil. Voici comment nous décidons.

La décision

# Kubernetes deployment — le défaut
replicas: 4                        # scale horizontal = boulot de votre cluster
resources:
  requests: { cpu: 500m, memory: 512Mi }
  limits:   { cpu: 2000m, memory: 1Gi }
livenessProbe:
  httpGet: { path: /healthz, port: 3000 }
readinessProbe:
  httpGet: { path: /ready, port: 3000 }
# Le container fait tourner UN seul processus node. Pas de cluster, pas de PM2.

L'erreur que nous voyons encore : PM2 dans Docker dans Kubernetes. Trois couches de supervision de processus qui se battent entre elles. Un processus par container, point — laissez Kubernetes faire l'orchestration.

L'article complet couvre :

• Quand le module cluster a encore du sens (mono-hôte, CPU-bound, pas d'orchestrateur)
• Quand PM2 a encore du sens (déploiements VPS legacy, mono-hôte avec plusieurs services non liés)
• Le pattern Kubernetes : un processus par container, scale horizontal au niveau pod
• Shutdown gracieux — gestion SIGTERM, drainage des requêtes en cours, terminationGracePeriodSeconds
• Autoscaling conscient de la mémoire avec requests/limits correctement réglés
• Pourquoi le « fork mode + reload » de PM2 est pire qu'un rolling deploy

Nous déployons ce pattern sur chaque stack Node.js managée.