PM2 vs cluster vs containers — how we run Node.js in 2026

PM2 was the right answer when "production Node.js" meant a single VPS, an SSH key, and a git pull deploy. The cluster module worked fine before that for teams who didn't want a process manager. In 2026 most production Node services run as containers in Kubernetes or on a container PaaS, and PM2's value proposition is largely gone — the orchestrator handles restart, autoscaling, and zero-downtime deploys.

But "largely" isn't "always." There are still workloads where PM2 is genuinely the right tool. This is how we decide.

The decision

# Kubernetes deployment — the default
replicas: 4                        # horizontal scale = your cluster's job
resources:
  requests: { cpu: 500m, memory: 512Mi }
  limits:   { cpu: 2000m, memory: 1Gi }
livenessProbe:
  httpGet: { path: /healthz, port: 3000 }
readinessProbe:
  httpGet: { path: /ready, port: 3000 }
# Container runs ONE node process. No cluster, no PM2.

The mistake we still see: PM2 inside Docker inside Kubernetes. Three layers of process supervision fighting each other. One process per container, full stop — let Kubernetes do the orchestration.

The full write-up covers:

• When the cluster module still makes sense (single-host, CPU-bound, no orchestrator)
• When PM2 still makes sense (legacy VPS deployments, single-host with multiple unrelated services)
• The Kubernetes pattern: one process per container, horizontal scaling at the pod level
• Graceful shutdown — SIGTERM handling, draining in-flight requests, terminationGracePeriodSeconds
• Memory-aware autoscaling with requests/limits set correctly
• Why PM2's "fork mode + reload" is worse than a rolling deploy

We deploy this pattern on every managed Node.js stack.