A Node.js process that crashes and doesn't restart is a production outage waiting for someone to notice it manually — PM2 exists specifically to make sure that never happens unattended.
PM2 is a process manager for Node.js applications that keeps them running, automatically restarts them on crash, provides zero-downtime reloads, and offers built-in load balancing across CPU cores via its cluster mode. For self-managed server deployments (as opposed to platforms that already handle process supervision), it's close to essential infrastructure.
Why PM2 Matters (and When to Skip It)
A raw node server.js process has no supervision — if it crashes, throws an unhandled exception, or the server reboots, nothing brings it back without manual intervention. PM2 wraps your application process with automatic restart on crash, log management, and monitoring, turning a fragile single process into something that behaves reliably in production.
Skip PM2 if you're deploying to a platform that already provides process supervision (most PaaS and container orchestration platforms handle restarts and scaling themselves) — running PM2 inside a container managed by Kubernetes, for example, is usually redundant with what the orchestrator already does.
Getting Started with PM2
npm install -g pm2
pm2 start server.js --name my-app
pm2 status
pm2 logs my-app
An ecosystem file for more detailed configuration:
// ecosystem.config.js
module.exports = {
apps: [{
name: "my-app",
script: "./server.js",
instances: "max",
exec_mode: "cluster",
env: {
NODE_ENV: "production",
PORT: 3000,
},
max_memory_restart: "500M",
}],
};
pm2 start ecosystem.config.js
pm2 save
pm2 startup # generates a command to restart PM2 on server reboot
Core PM2 Concepts Every Developer Should Know
Cluster mode load-balances across CPU cores automatically. Setting instances: "max" with exec_mode: "cluster" spawns one process per available CPU core, with PM2 distributing incoming connections across them — a significant throughput improvement for CPU-bound Node.js workloads with minimal configuration effort.
Zero-downtime reloads replace old processes with new code gradually, keeping the application available throughout a deploy:
pm2 reload my-app # graceful, one instance at a time
# vs
pm2 restart my-app # faster, but briefly drops all instances
max_memory_restart guards against memory leaks by automatically restarting a process if it exceeds a configured memory threshold — a practical safety net while the actual leak gets tracked down and fixed.
pm2 startup + pm2 save ensures your app survives a server reboot, generating and registering a system service that restarts PM2 (and everything it was managing) automatically on boot — an easy step to forget that turns a routine server restart into an unplanned outage.
Common PM2 Mistakes and How to Fix Them
Mistake 1: forgetting pm2 save and pm2 startup, so a server reboot doesn't bring the app back. This is a surprisingly common gap that only surfaces during an actual server restart, often at the worst time. Fix: run both commands as a standard part of initial server setup, not an afterthought.
Mistake 2: using pm2 restart for deploys instead of pm2 reload, causing unnecessary downtime. Fix: use reload for cluster-mode apps to get the zero-downtime rolling restart behavior.
Mistake 3: running PM2 inside a container also managed by an orchestrator like Kubernetes, duplicating restart/scaling logic the orchestrator already provides and potentially conflicting with it. Fix: let the orchestrator handle process supervision in containerized deployments; use PM2 specifically for traditional VM/bare-metal server deployments.
When Should You Use PM2 Instead of Systemd or a Container Orchestrator?
Use PM2 for self-managed VPS/bare-metal Node.js deployments where you want process supervision, cluster-mode load balancing, and zero-downtime reloads without the overhead of a full orchestration platform. Use systemd directly for simpler single-process supervision needs without PM2's Node-specific features, and use a container orchestrator (Kubernetes, ECS) when you're already running containerized infrastructure with its own process/scaling management.
PM2 in Production
Set up log rotation (pm2-logrotate module) to prevent log files from growing unbounded on the server disk over time. Also monitor PM2's own status output (pm2 monit) or integrate with a proper monitoring solution, since PM2 restarting a crashing process repeatedly is a symptom worth investigating, not just a problem automatically solved by the restart itself.
If you're running Node.js directly on a VPS without any process supervision currently, adding PM2 with cluster mode and startup persistence is a quick, high-value change before the next deploy.