What is the main takeaway from PM2 Production Deployment Guide: Process Management That Stays Up?
Define processes in an ecosystem file with clear app names, env vars, restart behavior, and log locations so behavior is reproducible.
Node.js guide
PM2 Production Deployment Guide: Process Management That Stays Up
PM2 keeps Node.js processes running, restarting them after crashes, starting them on boot, and reloading them without downtime. This guide covers configuring PM2 properly for production, not just running it locally.
11 min readUpdated 2026-08-20
Search focus
PM2 productionPM2 Node.jsPM2 cluster modePM2 process managerPM2 zero downtime
Published 2026-08-20Updated 2026-08-20CloudOpsync
What PM2 is and when to use it
PM2 is a process manager for Node.js applications that keeps a process alive, restarts it when it crashes or the host reboots, and manages multiple apps from one tool. It is the simplest reliable way to run a Node application on a single server, and it is especially well suited to small and medium deployments that do not yet justify container orchestration. PM2 runs beside your code, not instead of a good deployment, so it pairs naturally with a CI/CD pipeline that builds an artifact and hands it to PM2 to run. For teams comfortable with containers, a managed container service or an orchestrator can replace PM2, but for a straightforward Node service on a VM, PM2 offers process supervision, log capture, and boot resilience with a small operational surface.
Move from CLI flags to an ecosystem file
Running pm2 start app.js with many CLI flags is a recipe for drift, because the flags are not recorded anywhere and a reboot or a new engineer cannot reliably reproduce them. Instead, define apps in an ecosystem.config.js file that declares the name, script, interpreter, environment variables, instances, and restart options. The ecosystem file is also the human-readable contract for how the service runs, which makes it reviewable and version-controllable. It supports per-app log paths, an entry for args, and environment-specific overrides for development and production. Once the ecosystem file exists, pm2 start ecosystem.config.js runs the app the same way every time. Put the ecosystem file in the repository so the definition of the process travels with the code it runs.
Run in cluster mode for multiple cores
A Node.js process runs on a single core unless you scale it out. PM2's cluster mode, launched with --instance or via the ecosystem instances setting, starts multiple instances of your app that share the same port through a built-in load balancer, letting you use all of a machine's CPU cores. Running a number of instances equal to your CPU count is a common starting point on a multi-core server. Cluster mode works best for stateless services: if your app stores session data in memory, add a shared store such as Redis or an external service so all instances see the same state. If your workload is I/O-bound rather than CPU-bound, a single instance may be enough, so launch as many as the process pattern justifies and monitor the result.
Keep environment variables and secrets out of the repo
Secrets such as database passwords and API keys must not live in code or the ecosystem file. Use a .env file that PM2 loads, with the runtime reading the file that is not committed, or inject variables through the deployment environment and reference them with process.env. Keep the .env file out of version control and provision it on the server outside the repository, ensuring only the process user and deploy can read it. Restart the app when secrets rotate and verify the new values took effect by checking logs and connectivity. Treat a secret committed to the repository as compromised and rotate it. Centralizing secrets with a manager or the platform's parameter store is a good step once a handful of services share credentials.
Restart behavior and max restarts
PM2 restarts a crashed process automatically, but an app that crashes in a tight loop can spin forever. Configure restart limits with the max_restarts and min_uptime settings: max_restarts is the number of restarts allowed within a time window, and min_uptime sets how long the process must have stayed up before PM2 counts a failure. Use these together so a process that is up for a while is trusted, but one that dies a second after starting triggers a stop and an alert instead of an infinite loop. Choose the health check and the wait time so a genuine crash is caught without stopping a legitimate slow boot. The goal is that a crash is contained and visible to monitoring rather than silently retried by a process manager that will not give up.
Start PM2 on boot
Process managers are only useful across reboots if the manager itself starts with the system. PM2 provides a startup generator that configures an init system, such as systemd or the distribution equivalent, so PM2 and its process list restore on boot. Run pm2 save after setting up your apps to persist the current process list to the dump file that the startup script restores. On a rebooting host the process list comes back without manual intervention, which is the difference between hosting that survives maintenance and hosting that does not. Define the user that owns the PM2 instance so processes run without root, and verify the startup path works by rebooting a staging host and confirming the apps come back.
Manage logs deliberately
PM2 captures stdout and stderr to files by default, which is convenient, but logs need a retention plan or they will fill the disk. Set log paths in the ecosystem file and configure rotation so files do not grow without bound, either through PM2's log rotation module or by shipping logs to a central aggregator and keeping local files bounded. Rotate well before the disk fills, and check disk usage as part of monitoring, because a full disk can take a service down as surely as a crash. Structure log lines as JSON where possible so the aggregator can parse them, and include a request correlation ID so tracing across services starts at the log line. The goal is that every line reaches a place you can search when an incident starts, and no log file ever causes an outage.
Deploy with zero-downtime reloads
Updating a production Node app should not drop connections. In cluster mode, use pm2 reload with the ecosystem file, which performs a rolling restart, bringing new instances up and draining old ones so the port stays served throughout. This is the correct way to ship an update on a single server, versus pm2 restart, which briefly stops the app. Pair the reload with a health check so you confirm the new version responds before PM2 completes the cycle. Rolling reloads assume cluster mode, so run at least two instances when you rely on it. The zero-downtime path makes deployments a normal, boring event, and the rollback path is simply reloading the previous version from your artifact history.
Integrate PM2 with your pipeline
PM2 runs your app; a pipeline delivers it. Build the artifact in CI, version it, and hand it to the server, then run pm2 reload with the new artifact in a deployment step. Avoid pulling source and rebuilding on the server, because a rebuild on the host is not the artifact that CI validated and is harder to roll back. Keep the ecosystem file in the repository and promote the same configuration across environments so staging and production match. Record the deployed version so rollback is a clear action, and make the deployment step idempotent so the pipeline can be re-run safely. The cleanest loop is that the pipeline pushes the artifact and runs the reload, and PM2 keeps the process alive and observable between deploys.
Monitor health and performance
PM2 provides status, logs, and some runtime metrics, so read them, but do not rely on PM2 as your full observability story. Ship process health and application metrics to a real monitoring stack, watching uptime, restart counts, CPU and memory, request latency, and error rate, and alert on the symptoms users feel rather than on PM2 state alone. Have an external uptime probe on the service endpoint so a silent crash is a page, not a discovery, and keep a runbook for a crash loop or a hung process. Treat a process that restarts repeatedly as a signal to investigate rather than a normal state. The goal is that PM2 keeps the process alive while your monitoring and alerting tell an operator whether the service is actually healthy.
Implementation checklist
Turn the article into a safer production change.
- Step 1
Clarify the production goal behind pm2 production deployment guide: process management that stays up and the business risk it should reduce.
- Step 2
Review the current stack, deployment process, infrastructure ownership, monitoring, security, and support gaps.
- Step 3
Prioritize the smallest useful change that improves reliability, automation, visibility, or recovery.
- Step 4
Validate the change with logs, health checks, rollback notes, and a handover your team can keep using.
People also ask
When should a team apply this node.js guide guidance?
Set up startup on boot, manage logs, watch health and metrics, and integrate PM2 with your deployment pipeline for reliable operation.
Related services
Continue from guide to implementation.
Consultation
Turn the guide into a production-ready DevOps plan.
Share your stack, risk level, and delivery goal. You will get a practical scope conversation instead of a generic sales pitch.