PM2 is an open-source process manager for Node.js applications that keeps programs running in the background, restarts them when they crash and starts them again after a server reboot. In the area of services & processes on servers, it acts as a process supervisor tailored to the needs of JavaScript runtimes, although it can also run Python scripts, shell scripts and other executables.
PM2 adds features that a plain node command lacks: cluster mode for using every CPU core, zero-downtime reloads, built-in log handling, memory-based restarts and a declarative configuration file. It is especially common on virtual private servers and single-host deployments where a full container orchestrator would be excessive.
How PM2 supervises processes
When the first PM2 command runs, it starts a background daemon that owns every managed application. The command-line tool only talks to this daemon, so closing the terminal or ending an SSH session does not stop the applications. The daemon watches each child process and restarts it according to its restart policy when it exits unexpectedly.
To survive a reboot, the daemon itself must be started by the operating system. The pm2 startup command generates an init script for systemd, launchd or another init system, and pm2 save stores the current process list so that it is restored automatically on boot.
The table lists the commands used most often in daily operations.
| Command | Effect | Typical moment |
|---|---|---|
pm2 start | Launches an app or an ecosystem file | First deployment |
pm2 reload | Restarts cluster workers one by one | Deploying new code without downtime |
pm2 restart | Stops and starts all instances at once | Configuration changes, fork mode apps |
pm2 list | Shows status, uptime, restarts, CPU and memory | Quick health check |
pm2 logs | Streams standard output and error logs | Debugging a failure |
pm2 save | Stores the current process list | After any change to running apps |
pm2 startup | Creates a boot script for the daemon | Initial server setup |
Fork mode and cluster mode
PM2 runs applications in one of two execution modes. In fork mode, each instance is a separate process, which works for any language. In cluster mode, PM2 uses the Node.js cluster module so that several worker processes share one listening port, spreading incoming connections across CPU cores.
| Aspect | Fork mode | Cluster mode |
|---|---|---|
| Supported programs | Any executable or interpreter | Node.js applications only |
| Port sharing | Each instance needs its own port | Workers share one port |
| Zero-downtime reload | Not available | Available through rolling reload |
| CPU usage | One core per instance | One worker per core, often max |
| Best suited for | Workers, scripts, non-Node services | HTTP servers and APIs |
Cluster mode requires the application to be stateless across workers. Sessions kept in memory, local caches and scheduled jobs run in every worker unless they are moved to a shared store such as a database or Redis, or limited to a single designated instance.
Configuration with an ecosystem file
Production setups describe applications in an ecosystem file, usually named ecosystem.config.js, instead of long command lines. The file is kept under version control, so every server starts the same apps with the same environment variables, instance counts and restart rules.
| Option | Purpose | Typical value |
|---|---|---|
instances | Number of processes to run | max, or a fixed number such as 4 |
exec_mode | Fork or cluster execution | cluster for web servers |
max_memory_restart | Restarts a process above a memory limit | For example 500M |
exp_backoff_restart_delay | Growing delay between crash restarts | About 100 milliseconds initially |
kill_timeout | Time allowed for graceful shutdown | A few seconds for busy servers |
wait_ready | Waits for an explicit ready signal | true for apps with slow startup |
Graceful shutdown deserves particular attention. On reload, PM2 sends a SIGINT signal and waits for the kill timeout before forcing termination. An application that closes its server, finishes active requests and releases database connections within that window delivers a genuinely seamless reload; one that ignores the signal loses in-flight requests.
PM2 compared with other process supervisors
PM2 overlaps with general-purpose supervisors such as systemd and Supervisord, and with container platforms. The difference lies mainly in scope: PM2 understands Node.js specifics, while the alternatives are language-neutral and often already present on the system.
| Tool | Scope | Strength | Limitation |
|---|---|---|---|
| PM2 | Application processes on one host | Node.js cluster mode and reloads | Adds its own daemon and tooling |
| systemd | All services on a Linux host | Native, dependency ordering, cgroups | No Node-aware clustering |
| Supervisord | Processes on one host | Simple, language-neutral | Fewer built-in features |
| Container orchestrator | Many hosts | Scheduling, scaling, self-healing | Much higher complexity |
Inside a container, running PM2 is often unnecessary, because the orchestrator already restarts failed containers. When it is used there, the pm2-runtime variant keeps the process in the foreground so the container lifecycle works correctly.
Common mistakes when running PM2
- Forgetting pm2 save after adding an app, so the server comes back after a reboot without it.
- Letting logs grow without limit; a log rotation module or system log rotation should cap file size.
- Masking memory leaks with max_memory_restart, which hides the root cause instead of fixing it.
- Running PM2 as root, which gives every managed application full control of the server.
- Ignoring high restart counts in pm2 list, which usually signal a crash loop.
In plain words
A web application is a program that must run all day and all night. If it crashes at three in the morning, someone has to start it again. PM2 is the caretaker that does this automatically.
It watches the program and restarts it after a crash. It brings the program back after the server reboots. It can also run several copies side by side so the work is shared across the machine’s processors. Think of a building manager who keeps every light on and replaces a bulb the moment it fails.
A real-world example
A startup runs its Node.js booking API on a single virtual server with eight CPU cores. At first the API ran in one process started from a terminal, and it stopped whenever the SSH session closed or an unhandled error occurred.
The team moved the API to PM2 with an ecosystem file: cluster mode with eight instances, a 700 MB memory restart limit, exponential backoff for crash restarts and a five-second kill timeout. The application was updated to close connections cleanly on SIGINT, and pm2 startup with pm2 save made the setup survive reboots.
Deployments now use pm2 reload, which replaces workers one at a time, so customers no longer see errors during releases. Throughput improved because all eight cores handle requests, and the restart counter in pm2 list helped the team spot and fix a recurring crash within a week.