PM2 vs cluster vs containers — cómo corremos Node.js en 2026

PM2 era la respuesta correcta cuando «Node.js en producción» significaba un solo VPS, una clave SSH y un despliegue con git pull. El módulo cluster funcionaba bien antes para equipos que no querían un process manager. En 2026 la mayoría de servicios Node en producción corren como containers en Kubernetes o en un PaaS de containers, y la propuesta de valor de PM2 ha desaparecido en gran medida — el orquestador se encarga de restart, autoscaling y despliegues sin downtime.

Pero «en gran medida» no es «siempre». Aún hay cargas donde PM2 es de verdad la herramienta correcta. Así es como decidimos.

La decisión

# Deployment de Kubernetes — el default
replicas: 4                        # escala horizontal = trabajo del clúster
resources:
  requests: { cpu: 500m, memory: 512Mi }
  limits:   { cpu: 2000m, memory: 1Gi }
livenessProbe:
  httpGet: { path: /healthz, port: 3000 }
readinessProbe:
  httpGet: { path: /ready, port: 3000 }
# El container corre UN proceso node. Sin cluster, sin PM2.

El error que seguimos viendo: PM2 dentro de Docker dentro de Kubernetes. Tres capas de supervisión de procesos peleándose entre sí. Un proceso por container, punto — deja a Kubernetes hacer la orquestación.

El artículo completo cubre:

• Cuándo el módulo cluster aún tiene sentido (un único host, CPU-bound, sin orquestador)
• Cuándo PM2 aún tiene sentido (despliegues VPS legacy, un único host con varios servicios no relacionados)
• El patrón Kubernetes: un proceso por container, escala horizontal a nivel pod
• Apagado gracioso — manejo de SIGTERM, drenar peticiones en vuelo, terminationGracePeriodSeconds
• Autoscaling consciente de memoria con requests/limits bien ajustados
• Por qué el «fork mode + reload» de PM2 es peor que un rolling deploy

Desplegamos este patrón en cada stack Node.js gestionada.