PM2 Ecosystem Config Generator

Generate a PM2 ecosystem.config.js without remembering the field names. Set the app name and script, choose fork or cluster mode and the number of instances, toggle file watching, set a max_memory_restart threshold and a cron_restart, and add environment variables — and get a ready-to-commit config file for pm2 start ecosystem.config.js. It builds live in your browser.

How to use the PM2 Ecosystem Config Generator

Set the app name (how the process shows up in pm2 list) and the script entry point. Choose exec_mode: fork runs a single process and works for any program, while cluster launches multiple Node.js workers behind PM2's built-in load balancer for zero-downtime reloads and multi-core use — set instances to a number or max to match CPU cores. Add a max_memory_restart threshold so a leaking process is recycled automatically, and a cron_restart if you want a scheduled restart.

Add environment variables one KEY=value per line; they're emitted as the env block. Set an interpreter only if you're running something other than Node directly (for example a Python script or Bun). Save the generated file as ecosystem.config.js in your project root and start it with pm2 start ecosystem.config.js; reload after changes with pm2 reload ecosystem.config.js. Note that cluster mode requires a Node.js script — for non-Node programs or anything started via an interpreter, use fork mode.

PM2, ecosystem files, and fork vs cluster

PM2 is a process manager for Node.js (and, in fork mode, any executable) that keeps applications alive, restarts them on crash or on a memory threshold, manages logs, and enables zero-downtime reloads. While you can start a process with flags on the command line, the recommended approach for anything beyond a one-off is an ecosystem file — a JavaScript (or JSON) config that declares one or more apps and all their options in version control, so the exact runtime configuration is reproducible and reviewable rather than living in someone's shell history.

The most consequential choice in the file is exec_mode. In fork mode PM2 simply spawns your script as a child process; this works for any program and any interpreter but gives you a single instance. In cluster mode PM2 uses Node's cluster module to fork several worker processes that share a listening socket, load-balancing connections across CPU cores and enabling pm2 reload to restart workers one at a time for zero downtime. Cluster mode only works with Node.js applications that listen on a socket; a CPU-bound script or a non-Node program must use fork mode. Setting instances to max (or 0) tells PM2 to launch one worker per core.

The other fields encode operational policy. autorestart brings a crashed process back; max_memory_restart recycles a process that grows past a memory limit, a pragmatic guard against slow leaks; watch restarts on file changes (useful in development, dangerous in production); and cron_restart schedules periodic restarts. Environment variables typically live in an env block, often with an env_production override applied via --env. Keeping all of this in an ecosystem file — rather than ad-hoc flags — is what makes a PM2 deployment repeatable, and this generator produces a clean, conventional file you can commit and adjust.

Common use cases

  • Node API servers. Run an Express/Fastify app in cluster mode across all cores with zero-downtime reloads.
  • Reproducible deploys. Commit an ecosystem file so the runtime config is in version control, not shell history.
  • Memory-leak safety net. Recycle a process automatically when it crosses a max_memory_restart threshold.
  • Scheduled restarts. Add a cron_restart to refresh a long-running worker nightly.

Frequently asked questions

When can I use cluster mode?

Cluster mode only works with Node.js applications that listen on a socket (HTTP servers, etc.), because it relies on Node's cluster module to share a port across workers. For CPU-bound scripts, non-Node programs, or anything launched through a custom interpreter, use fork mode — cluster mode would not balance load correctly.

What does instances: "max" mean?

In cluster mode, "max" (equivalent to 0) tells PM2 to start one worker per available CPU core. You can also give a specific number, or a negative number to leave that many cores free (for example -1 uses all cores but one). In fork mode instances is normally 1.

How do environment variables work across env blocks?

The env block sets the default environment. You can add env_production, env_staging and so on, then activate one with "pm2 start ecosystem.config.js --env production". Variables from the named block are merged over the base env. This generator emits the base env block; add override blocks as needed.

Should I enable watch in production?

No. watch restarts the app whenever files change, which is helpful in development but causes unexpected restarts in production (for example when logs or uploads are written into a watched path). Leave it off for production and rely on pm2 reload during deploys.

How do I start and reload the app?

Start with "pm2 start ecosystem.config.js". After editing the file or deploying new code, use "pm2 reload ecosystem.config.js" for zero-downtime reloads in cluster mode, or "pm2 restart" to hard-restart. Run "pm2 save" and "pm2 startup" to persist the process list across reboots.