lpm vs PM2

PM2 is for production. lpm is for the dev loop.

PM2 is a rock-solid daemon for keeping Node apps alive in prod — clustering, auto-restart, startup scripts. lpm is a workflow tool for starting, stopping, and switching between local projects while you code. Different jobs.

Download for macOS
Signed & notarized by Apple
View on GitHub
How it compares

PM2 and lpm, feature by feature

PM2 wins every production row. lpm wins the dev-loop rows. Written honestly so you can tell which column you actually need.

lpm

  • Starts multiple processes with one command
  • dev loopPrimary focus
  • Per-service live output pane
  • Native macOS desktop app
  • Visual multi-project switcher
  • Framework auto-detect (Rails, Next.js, Go, Django, Flask, Compose)
  • Duplicate a project for a second AI agent
  • Designed for Claude Code / Codex in parallel
  • Cluster mode across CPU cores
  • Auto-restart on crash with backoff
  • Runs at server boot (pm2 startup / save)
  • Zero-downtime reload on deploy
  • dev-onlyLog rotation and centralized log files
  • per-service panesCPU / memory monitoring dashboard
  • YAML name + commandConfig format
  • Open source, free

PM2

  • Starts multiple processes with one command
  • productionPrimary focus
  • Per-service live output pane
  • Native macOS desktop app
  • Visual multi-project switcher
  • Node-focusedFramework auto-detect (Rails, Next.js, Go, Django, Flask, Compose)
  • Duplicate a project for a second AI agent
  • Designed for Claude Code / Codex in parallel
  • Cluster mode across CPU cores
  • Auto-restart on crash with backoff
  • Runs at server boot (pm2 startup / save)
  • Zero-downtime reload on deploy
  • prod-gradeLog rotation and centralized log files
  • pm2 monit + PlusCPU / memory monitoring dashboard
  • ecosystem.config.jsConfig format
  • Open source, free
Honest take

When each one is the right tool

Both run multiple processes. The split is whether the processes are a product running for users or a stack you're actively editing.

Pick lpm

You're in the dev loop — multiple projects, mixed stacks, or AI agents running in parallel.

  • You switch between several local projects a day and want a visual switcher instead of terminal tabs.
  • Your stack is Rails, Next.js, Go, Django, Flask, or Docker Compose — not just Node — and you want first-class framework detection.
  • You want each service in its own live pane in a native macOS app, not one interleaved log stream.
  • You run Claude Code, Codex, Cursor, or aider in parallel and need each agent's output visible at once.
  • You want to duplicate a project so a second agent can work on its own copy of the stack without conflicts.
Pick PM2

You're shipping a Node app to a server and need it to stay alive under load.

  • You deploy Node to production or staging and need cluster mode across CPU cores with load balancing.
  • You need auto-restart on crash with exponential backoff, memory limits, and graceful reloads.
  • You need pm2 startup + pm2 save so the app comes back after a reboot.
  • You need log rotation, centralized log files, and integrations like PM2 Plus / Keymetrics for monitoring.
  • You need zero-downtime reloads on deploy without dropping in-flight requests.
FAQ

lpm vs PM2 — the honest FAQ

  • Can I use lpm in production instead of PM2?
    No, and that is not the pitch. lpm is a dev-workflow tool — it starts, stops, and switches between local projects while you are coding. PM2 is a daemon built to keep Node apps alive on a server: cluster mode, auto-restart on crash, pm2 startup for boot, zero-downtime reloads, log rotation. If you are deploying Node to prod or staging, use PM2. lpm and PM2 are complementary, not competitors.
  • Does lpm cluster Node processes across cores like PM2?
    No. Cluster mode is a production concern — PM2 forks your Node app across CPU cores and load-balances between workers so a single box serves more traffic. lpm doesn't do that. In dev you usually want one instance of each service so logs and debugger breakpoints map to a single process. If you need clustering, that is a signal you want PM2 in front of your app, not lpm.
  • I run non-Node projects — Rails, Django, Go. Does lpm help more than PM2 there?
    This is where the split is clearest. PM2 can run non-Node commands via its interpreter: "none" or bash escape hatch, but the ecosystem, docs, and defaults all assume Node. lpm auto-detects Rails, Next.js, Go, Django, Flask, and Docker Compose as first-class — you point it at the repo, it figures out the services, and each one gets its own live pane. If your stack is mixed or non-Node, lpm is built for that shape.
  • How do I migrate from ecosystem.config.js to lpm?
    You don't fully migrate — you'd keep ecosystem.config.js for production and add an lpm config for dev. lpm uses a lightweight YAML where each service is name + command, which maps cleanly to the apps array in ecosystem.config.js: take each entry's name and script/args, drop it into the lpm config, and you're running. Env vars, cwd, and ports are handled in the lpm config separately. For many Node projects the framework auto-detect means you don't even need a config.
  • Can I run PM2 under lpm during development?
    Yes, and that is a reasonable setup. If your dev environment mirrors prod and you want pm2 start ecosystem.config.js locally, make that a single service in your lpm config — one line, command pm2-runtime start ecosystem.config.js(the non-daemonized variant so lpm owns the lifecycle). You get lpm's per-project switcher and pane UI on the outside, PM2's cluster / restart semantics on the inside. Source is on GitHub if you want to try it.

Use PM2 in prod. Use lpm while you're coding.

A dev-loop layer on top of whatever runs your services — per-service panes, multi-project switching, and parallel AI-agent workflows. Free and open source.

Download for macOS
Signed & notarized by Apple
View on GitHub