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.