Introduction

Node.js has become the backbone of modern web applications, powering everything from APIs to real-time services. But running a Node.js application in production isnt as simple as typing node app.js. Without proper process management, your application can crash silently, consume excessive memory, or fail to restart after server reboots. This is where PM2 comes in.

PM2 is a production-grade process manager for Node.js applications that ensures uptime, performance, and scalability. Unlike basic terminal-based execution, PM2 provides advanced features like automatic restarts, load balancing, log management, and monitoringall critical for maintaining reliable services in production environments.

But not all guides to PM2 are created equal. Many tutorials skip over best practices, misconfigure clustering, or recommend outdated settings. In this comprehensive guide, youll learn the top 10 trusted, battle-tested ways to use PM2 for Node.js applicationsmethods proven by developers at Fortune 500 companies, startups scaling to millions of users, and DevOps teams managing thousands of instances.

By the end of this article, youll know exactly how to deploy, monitor, and maintain Node.js applications with PM2without guesswork, without risk, and without compromising stability.

Why Trust Matters

In software development, trust isnt a luxuryits a necessity. When youre managing production applications, a single misconfiguration can lead to downtime, data loss, or security vulnerabilities. PM2 is a powerful tool, but its power comes with complexity. Using it incorrectly can cause more harm than good.

Many online tutorials recommend running PM2 with root privileges, disabling logging, or using default memory limitspractices that are dangerous in production. Others suggest outdated PM2 versions or ignore key features like ecosystem files, restart policies, and process monitoring hooks.

Trusted methods are those validated through real-world usage: applications that have survived traffic spikes, server failures, and security audits. They follow industry standards, adhere to the principle of least privilege, and prioritize observability and resilience.

Trust also means understanding what PM2 does under the hood. Its not just a restart my app tool. PM2 is a full lifecycle manager: it monitors memory usage, handles graceful shutdowns, manages logs across multiple instances, and integrates with system services like systemd. When used correctly, it becomes the silent guardian of your applications availability.

This guide focuses exclusively on methods that have been tested, documented, and adopted by professional Node.js teams. We avoid hype, quick fixes, and theoretical suggestions. Every recommendation here has been deployed in live environments with measurable improvements in uptime, performance, and maintainability.

Top 10 How to Use PM2 for Nodejs

1. Install PM2 Globally with npm (Verified Version)

Before using PM2, ensure youre installing a stable, verified version. Avoid installing via package managers like apt or yum unless youre certain theyre maintained by trusted repositories. The safest and most reliable method is using npm.

Run the following command:

npm install -g pm2@latest

Always check the installed version after installation:

pm2 --version

As of 2024, PM2 v5.x is the stable release line. Avoid versions below v4, as they lack critical security patches and performance improvements. Use npm install -g pm2@5.3.1 (or the latest patch) to lock to a known-good version.

Never install PM2 as root. Use a dedicated non-root user with minimal privileges. If you must install globally as root, reconfigure PM2 to run processes under a restricted user using ecosystem files (covered in

3).

Why this matters: Installing the latest stable version ensures compatibility with modern Node.js runtimes and prevents known vulnerabilities in older PM2 releases. Trusted teams use version pinning to avoid unexpected breaking changes during deployments.

2. Use an Ecosystem Configuration File (ecosystem.config.js)

Never start your Node.js app with a raw command like pm2 start app.js in production. Instead, define your application configuration in an ecosystem file. This file is version-controlled, reusable, and supports environment-specific settings.

Create a file named ecosystem.config.js in your project root:

module.exports = {
apps: [{
name: 'my-node-app',
script: './dist/index.js',
instances: 'max',
exec_mode: 'cluster',
autorestart: true,
watch: false,
max_restarts: 10,
max_memory_restart: '1G',
env: {
NODE_ENV: 'development',
PORT: 3000
},
env_production: {
NODE_ENV: 'production',
PORT: 8080
},
log_date_format: 'YYYY-MM-DD HH:mm:ss',
error_file: './logs/err.log',
out_file: './logs/out.log',
pid_file: './pm2.pid',
min_uptime: '60s',
restart_delay: '3s'
}]
};

Deploy using:

pm2 start ecosystem.config.js --env production

Why this matters: Ecosystem files eliminate configuration drift. They allow you to define environment variables, log paths, restart policies, and instance counts in one place. Teams using ecosystem files reduce deployment errors by 70% compared to command-line-only deployments.

Pro tip: Use pm2 save after starting your app to persist the process list across reboots. Combine this with pm2 startup to auto-start PM2 on system boot (see

6).

3. Run PM2 Under a Dedicated Non-Root User

Running Node.js applications as root is one of the most dangerous practices in production. If your app is compromised, an attacker gains full system access. Trusted teams always run PM2 under a dedicated, non-root user with minimal permissions.

Create a system user:

sudo adduser --system --no-create-home --group nodeapp

Change ownership of your application directory:

sudo chown -R nodeapp:nodeapp /opt/my-node-app

Switch to the user and start PM2:

sudo -u nodeapp pm2 start ecosystem.config.js --env production

Ensure PM2s startup script runs under this user:

sudo -u nodeapp pm2 startup systemd -u nodeapp --hp /home/nodeapp

Why this matters: The principle of least privilege is foundational to security. Even if your Node.js app is exploited via a vulnerability, the attacker cannot access system files, modify configurations, or install malware. This practice is mandatory for compliance with ISO 27001, SOC 2, and other enterprise security standards.

Never use sudo pm2 to start applications. Always bind PM2 to a restricted user from the start.

4. Enable Cluster Mode for Multi-Core Utilization

Node.js is single-threaded by default. One instance of your app can only use one CPU core. On modern servers with 4, 8, or 16 cores, this is a massive waste of resources.

PM2s cluster mode solves this by spawning multiple worker processeseach bound to a separate CPU core. This increases throughput without code changes.

In your ecosystem.config.js, set:

instances: 'max',  // Uses all available CPU cores
exec_mode: 'cluster'

Verify its working:

pm2 list

Youll see multiple instances running, each with a unique ID.

Why this matters: Cluster mode can increase application throughput by 300500% on multi-core systems. Its the single most effective performance optimization for most Node.js apps. Unlike manual child process management, PM2 handles process lifecycle, load balancing, and restarts automatically.

Important: Cluster mode requires your app to be stateless. Avoid storing session data in memory. Use Redis or another external store for shared state.

5. Configure Memory Limits and Auto-Restart Policies

Memory leaks are the silent killers of Node.js applications. Over time, poorly managed memory can cause apps to slow down, crash, or trigger OOM (Out of Memory) errors on the server.

Use PM2s built-in memory monitoring and auto-restart features:

max_memory_restart: '1G',
min_uptime: '60s',
restart_delay: '3s'

These settings mean: if a process exceeds 1GB of memory, PM2 will restart itbut only if its been running for at least 60 seconds (to avoid restarting during startup), and with a 3-second delay between restarts to prevent rapid cycling.

Combine this with monitoring:

pm2 monit

Watch memory usage in real time. If you see consistent growth, investigate memory leaks using Node.js built-in tools like --inspect and Chrome DevTools.

Why this matters: Auto-restart on memory exhaustion prevents server-wide crashes. Many production outages are caused by gradual memory leaks that go unnoticed until the server runs out of RAM. PM2s proactive restarts act as a safety net.

Set max_restarts to a reasonable limit (e.g., 10) to avoid infinite restart loops. If an app restarts more than 10 times in 5 minutes, PM2 will mark it as errored and stop tryinggiving you time to investigate.

6. Auto-Start PM2 on System Boot with Systemd

Server reboots happenduring updates, power outages, or hardware failures. If PM2 doesnt restart automatically, your app stays down until someone manually starts it.

Run the following command to generate a systemd service:

pm2 startup systemd -u nodeapp --hp /home/nodeapp

This outputs a command. Copy and paste it to install the systemd service. Example output:

sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u nodeapp --hp /home/nodeapp

Then save your current process list:

pm2 save

Reboot your server to test:

sudo reboot

After reboot, check:

pm2 list

Why this matters: Zero-downtime resilience starts with automatic recovery. Production systems must survive reboots without human intervention. This step is non-negotiable for any service with SLA requirements.

Always test this in a staging environment first. Ensure the user (e.g., nodeapp) has correct permissions to access all files and ports.

7. Centralize and Rotate Logs to Prevent Disk Exhaustion

By default, PM2 writes logs to ~/.pm2/logs/. Without rotation, these files can grow to gigabytes, filling your disk and crashing your server.

Configure log rotation in your ecosystem.config.js:

log_date_format: 'YYYY-MM-DD HH:mm:ss',
error_file: './logs/app-err.log',
out_file: './logs/app-out.log',
merge_logs: true

Then enable PM2s built-in log rotation:

pm2 install pm2-logrotate

Configure it:

pm2 set pm2-logrotate:max_size 10M
pm2 set pm2-logrotate:retain 30
pm2 set pm2-logrotate:compress true
pm2 set pm2-logrotate:dateFormat YYYY-MM-DD_HH-mm-ss

These settings limit each log file to 10MB, keep 30 rotated files, compress old logs, and append timestamps.

Why this matters: Unmanaged logs are a leading cause of server crashes in production. A single misconfigured app can generate 50GB of logs in a week. Log rotation prevents this silently and automatically.

For advanced setups, pipe logs to external systems like Fluentd, Logstash, or Datadog using PM2s custom log output options.

8. Monitor Performance with PM2 Plus (Optional but Recommended)

While PM2s CLI tools (pm2 monit, pm2 logs) are powerful, they lack long-term metrics, alerts, and dashboards.

PM2 Plus (now called Keymetrics) is a commercial monitoring service that integrates seamlessly with PM2. It provides:

• Real-time CPU, memory, and request metrics
• Historical graphs and trend analysis
• Alerts for high memory, crashes, or latency spikes
• Remote access to logs and process controls

Install the agent:

npm install -g pm2

Connect your app:

pm2 link <your-api-key> <your-app-name>

Why this matters: Teams using PM2 Plus reduce mean time to detect (MTTD) and mean time to resolve (MTTR) by 6080%. You get visibility into performance bottlenecks before users complain. Even if you dont use the full service, the free tier offers valuable insights for small applications.

Important: PM2 Plus is optional. If you prefer open-source tools, use Prometheus + Grafana with the PM2 Prometheus exporter, but PM2 Plus requires zero configuration and works out of the box.

9. Use Environment-Specific Configurations

Applications behave differently in development, staging, and production. Hardcoding values like database URLs, API keys, or port numbers leads to misconfigurations and security risks.

Use PM2s environment profiles:

env: {
NODE_ENV: 'development',
DB_HOST: 'localhost',
PORT: 3000
},
env_production: {
NODE_ENV: 'production',
DB_HOST: 'prod-db.internal',
PORT: 8080,
LOG_LEVEL: 'info'
},
env_staging: {
NODE_ENV: 'staging',
DB_HOST: 'staging-db.internal',
PORT: 8080,
LOG_LEVEL: 'debug'
}

Start with:

pm2 start ecosystem.config.js --env staging

Why this matters: Environment separation prevents accidental use of production credentials in test environments. It also allows you to adjust logging levels, caching strategies, and feature flags without changing code.

Always keep your ecosystem.config.js in version controlbut exclude sensitive values. Use environment variables for secrets:

DB_PASSWORD: process.env.DB_PASSWORD

And pass them at runtime:

DB_PASSWORD=secret123 pm2 start ecosystem.config.js --env production

This keeps secrets out of your repository and allows secure injection via CI/CD pipelines.

10. Implement Graceful Shutdown and Health Checks

When you restart or deploy a new version of your app, PM2 must shut down processes gracefully to avoid dropping active requests.

Modify your Node.js app to listen for shutdown signals:

process.on('SIGINT', () => {
console.log('Received SIGINT. Shutting down gracefully...');
server.close(() => {
console.log('Server closed.');
process.exit(0);
});
});
process.on('SIGTERM', () => {
console.log('Received SIGTERM. Shutting down gracefully...');
server.close(() => {
console.log('Server closed.');
process.exit(0);
});
});

In your ecosystem.config.js, add:

kill_timeout: 5000

This gives your app 5 seconds to shut down before PM2 forcefully kills it.

For advanced setups, implement a health check endpoint:

app.get('/health', (req, res) => {
res.status(200).json({ status: 'OK', uptime: process.uptime() });
});

Use PM2s healthcheck feature (available in PM2 v5+):

healthcheck: {
endpoint: 'http://localhost:8080/health',
interval: 10,
timeout: 3
}

Why this matters: Graceful shutdowns prevent 502 errors during deployments. Health checks allow PM2 to detect when an app is unresponsive and restart it before users are affected. This is critical for APIs serving public traffic.

Combine this with load balancers (like Nginx) that remove unhealthy instances from rotation during restarts.

Comparison Table

As shown, only the trusted setup described in this guide provides full production readiness. Basic PM2 usage is a step up from manual execution, but still lacks critical safeguards.

FAQs

Can I use PM2 with Docker?

Yes, but its often unnecessary. Docker containers are designed to run a single process. PM2s value lies in managing multiple Node.js processes on a single machine. If youre using Docker, let your container orchestration (like Kubernetes or Docker Compose) handle process management. Running PM2 inside Docker adds complexity without benefit unless youre managing multiple apps in one containerwhich is an anti-pattern.

Does PM2 work with Express, NestJS, and Next.js?

Yes. PM2 is framework-agnostic. It works with any Node.js application that exports a server or runs a JavaScript file. Whether youre using Express, NestJS, Fastify, or Next.js in server mode, PM2 can manage it. Just ensure your entry point (e.g., dist/main.js for NestJS or server/index.js for Next.js) is correctly referenced in your ecosystem.config.js.

How do I update PM2 without downtime?

Use PM2s reload feature:

pm2 reload ecosystem.config.js --env production

This restarts each worker one at a time, ensuring zero downtime. Never use pm2 restart for production appsit stops all instances simultaneously. Use reload for zero-downtime deployments.

Whats the difference between pm2 restart and pm2 reload?

pm2 restart stops all processes and starts them again simultaneously. This causes downtime. pm2 reload restarts workers one by one, maintaining availability. Always use reload in production. Use restart only for development or when changing core configuration.

How do I check why my app keeps crashing?

Run pm2 logs to view real-time output. Look for stack traces, unhandled exceptions, or connection timeouts. Use pm2 describe <app-name> to see restart count, memory usage, and uptime. If the app restarts more than 10 times in 5 minutes, PM2 marks it as erroredcheck pm2 show <app-name> for details.

Can I use PM2 with a reverse proxy like Nginx?

Absolutely. This is the standard production setup. Configure Nginx to proxy requests to your PM2-managed Node.js app(s). For cluster mode, point Nginx to the same port (e.g., 8080), and Nginx will load balance across all instances automatically. Use Nginx for SSL termination, static file serving, and rate limiting.

Is PM2 better than systemd alone for Node.js?

Systemd is excellent for managing single processes. But PM2 offers Node.js-specific features: cluster mode, memory-based restarts, log rotation, and built-in monitoring. For production Node.js apps, PM2 + systemd is the gold standard: systemd ensures PM2 starts on boot, and PM2 manages the Node.js application lifecycle.

What happens if PM2 crashes?

PM2 is designed to be resilient. If the PM2 daemon crashes, your applications continue runningtheyre managed by the underlying Node.js process tree. However, youll lose monitoring and management capabilities until you restart PM2. Thats why auto-start on boot (systemd) is critical. If PM2 dies, rebooting the server or manually restarting it with pm2 resurrect will restore control.

Should I use PM2 in development?

Yes, but with watch mode enabled:

pm2 start ecosystem.config.js --env development

Set watch: true in your ecosystem file to auto-restart on file changes. This gives you the benefits of PM2 (logs, process management) while enabling rapid iteration. Avoid cluster mode in developmentits unnecessary and can confuse debugging.

How do I remove an app from PM2?

Use:

pm2 delete <app-name-or-id>

To delete all apps:

pm2 delete all

Then remove the saved process list:

pm2 save

This ensures the app wont restart on reboot.

Conclusion

Using PM2 for Node.js applications isnt just about keeping your server runningits about building resilient, scalable, and secure systems that can withstand the demands of real-world usage. The top 10 methods outlined in this guide are not theoretical best practices. They are the same techniques used by engineering teams at companies that serve millions of users daily.

From running PM2 under a non-root user to enabling log rotation, clustering, and graceful shutdowns, each step adds a layer of reliability that raw node app.js simply cannot match. The comparison table makes it clear: only the trusted setup delivers full production readiness.

Dont treat PM2 as a simple start command. Treat it as your applications guardian. Configure it deliberately. Monitor it continuously. Secure it rigorously.

As Node.js continues to power the backbone of modern web infrastructure, the tools you choose to manage it become critical to your success. PM2, when used correctly, is one of the most powerful tools in your arsenal. Use it wisely, and your applications will not just runthey will thrive.

Start implementing these trusted methods today. Test them in staging. Deploy them with confidence. And never again be caught off guard by a silent crash or a full disk.