PM2 vs cluster vs containers — como rodamos Node.js em 2026

PM2 era a resposta certa quando «Node.js em produção» significava um único VPS, uma chave SSH e um deploy com git pull. O módulo cluster funcionava bem antes disso para times que não queriam um process manager. Em 2026 a maioria dos serviços Node em produção roda como containers em Kubernetes ou em um PaaS de containers, e a proposta de valor do PM2 sumiu em grande parte — o orquestrador cuida de restart, autoscaling e deploys sem downtime.

Mas «em grande parte» não é «sempre». Ainda há cargas onde o PM2 é de fato a ferramenta certa. É assim que decidimos.

A decisão

# Deployment do Kubernetes — o padrão
replicas: 4                        # escala horizontal = trabalho do cluster
resources:
  requests: { cpu: 500m, memory: 512Mi }
  limits:   { cpu: 2000m, memory: 1Gi }
livenessProbe:
  httpGet: { path: /healthz, port: 3000 }
readinessProbe:
  httpGet: { path: /ready, port: 3000 }
# O container roda UM processo node. Sem cluster, sem PM2.

O erro que continuamos vendo: PM2 dentro de Docker dentro de Kubernetes. Três camadas de supervisão de processo brigando entre si. Um processo por container, ponto — deixe o Kubernetes fazer a orquestração.

O artigo completo cobre:

• Quando o módulo cluster ainda faz sentido (host único, CPU-bound, sem orquestrador)
• Quando o PM2 ainda faz sentido (deploys legados em VPS, host único com vários serviços não relacionados)
• O padrão Kubernetes: um processo por container, escala horizontal no nível do pod
• Shutdown gracioso — tratamento de SIGTERM, drenar requisições em voo, terminationGracePeriodSeconds
• Autoscaling consciente de memória com requests/limits corretamente ajustados
• Por que o «fork mode + reload» do PM2 é pior que um rolling deploy

Implantamos este padrão em cada stack Node.js gerenciada.