PM2 & Process Management
PM2 is a production process manager for Node.js that provides process lifecycle management, clustering, log management, and monitoring. It keeps Node.js applications alive after crashes and system restarts.
PM2 is a helicopter parent for your Node.js processes—restarts them when they crash, clones them across CPU cores (cluster mode), and does hot-swaps (zero-downtime reload). In Kubernetes, the helicopter parent is redundant because K8s is already the overprotective grandparent doing all of that.
PM2 key features: (1) Cluster mode (pm2 start app.js -i max) forks one process per CPU core using Node.js cluster module. (2) Zero-downtime reload (pm2 reload): sends SIGINT to old workers, starts new workers, waits for readiness, then kills old workers. (3) Ecosystem config file (ecosystem.config.js) for reproducible deployments. (4) pm2 logs with log rotation. (5) pm2 monit for real-time CPU/memory monitoring. (6) pm2 save + pm2 startup to persist processes across system restarts.
PM2's zero-downtime reload works by sending SIGINT (not SIGTERM) to the old worker, waiting for it to send a 'ready' message on process.send('ready') from the new worker, then killing the old one. The application must emit the ready signal after completing initialization (DB connections, cache warmup). In Kubernetes, PM2 is largely redundant since Kubernetes itself handles process supervision and rolling updates—use PM2 in non-orchestrated environments (VMs, bare metal) or as a development tool. In containers, it's better to run Node directly as PID 1 with proper signal handling or use a minimal init (tini) rather than PM2, which adds memory overhead and complexity.
PM2 manages Node.js process lifecycle with crash restarts, cluster mode for multi-core utilization, and zero-downtime reloads. It's most valuable in non-containerized environments. In Kubernetes, the orchestrator replaces PM2's supervision role; running Node as PID 1 with proper SIGTERM handling is preferred. PM2's cluster mode is a convenient wrapper over Node.js's native cluster module.
In Docker containers, PM2 runs as a child of the Node process manager—meaning the container's PID 1 is Node.js running PM2, not your application. Signals (SIGTERM from Docker stop) go to PID 1 (PM2), which may or may not propagate them correctly to your workers. PM2 does forward SIGTERM, but startup/shutdown race conditions in containers cause subtler issues. Test signal handling explicitly in containerized environments.