PM2 vs Cluster vs Container — wie wir Node.js 2026 betreiben

PM2 war die richtige Antwort, als „Node.js in Produktion" einen einzelnen VPS, einen SSH-Key und ein git pull-Deployment bedeutete. Das Cluster-Modul funktionierte davor für Teams, die keinen Process Manager wollten. 2026 laufen die meisten produktiven Node-Services als Container in Kubernetes oder auf einem Container-PaaS, und die Wertversprechen von PM2 ist weitgehend verschwunden — der Orchestrator übernimmt Restart, Autoscaling und Zero-Downtime-Deployments.

Aber „weitgehend" ist nicht „immer". Es gibt noch Workloads, bei denen PM2 ehrlich das richtige Werkzeug ist. So entscheiden wir.

Die Entscheidung

# Kubernetes-Deployment — der Default
replicas: 4                        # horizontale Skalierung = Sache Ihres Clusters
resources:
  requests: { cpu: 500m, memory: 512Mi }
  limits:   { cpu: 2000m, memory: 1Gi }
livenessProbe:
  httpGet: { path: /healthz, port: 3000 }
readinessProbe:
  httpGet: { path: /ready, port: 3000 }
# Der Container fährt EINEN Node-Prozess. Kein Cluster, kein PM2.

Der Fehler, den wir immer noch sehen: PM2 in Docker in Kubernetes. Drei Schichten Prozess-Supervision, die sich gegenseitig in die Quere kommen. Ein Prozess pro Container, Punkt — lassen Sie Kubernetes die Orchestrierung machen.

Der vollständige Beitrag behandelt:

• Wann das Cluster-Modul noch Sinn macht (Single-Host, CPU-bound, kein Orchestrator)
• Wann PM2 noch Sinn macht (Legacy-VPS-Deployments, Single-Host mit mehreren unverbundenen Services)
• Das Kubernetes-Pattern: ein Prozess pro Container, horizontale Skalierung auf Pod-Ebene
• Graceful Shutdown — SIGTERM-Handling, In-Flight-Requests draining, terminationGracePeriodSeconds
• Speicherbewusstes Autoscaling mit korrekt gesetzten requests/limits
• Warum PM2s „Fork-Modus + Reload" schlechter ist als ein Rolling Deploy

Wir deployen dieses Pattern auf jedem gemanagten Node.js-Stack.