A PM2 alternative built for the local development loop.
PM2 is a production-first process supervisor with local watch and development modes. lpm specializes in the interactive Mac workflow around your services: live panes, project switching, and isolated copies for parallel agents.
Facts checked July 26, 2026 against PM2 development docs and PM2 process-management docs.
PM2 and lpm, feature by feature
PM2 has mature process supervision, monitoring, and a local watch mode. lpm adds a project-aware Mac workspace with service panes and parallel-agent copies.
| Capability | lpm | PM2 |
|---|---|---|
| Starts multiple processes with one command | Yes | Yes |
| Primary focus | local dev workflow | production-first |
| Local file-watch restart mode | via service command | pm2-dev / --watch |
| Per-service live output pane | Yes | logs / attach |
| Native macOS desktop app | Yes | No |
| Visual multi-project switcher | Yes | No |
| Generates project config from your repo | Yes | No |
| Runs Node, Python, shell commands, and binaries | Yes | Yes |
| Duplicate a project for a second AI agent | Yes | No |
| Designed for Claude Code / Codex in parallel | Yes | No |
| Cluster mode across CPU cores | No | Yes |
| Auto-restart on crash with backoff | No | Yes |
| Runs at server boot (pm2 startup / save) | No | Yes |
| Zero-downtime reload on deploy | No | Yes |
| Log rotation and centralized log files | live dev panes | log files; rotation add-on |
| CPU / memory monitoring dashboard | no resource dashboard | pm2 monit + Plus |
| Config format | name + command per service | ecosystem.config.js |
| Open source, free | Yes | Yes |
- Starts multiple processes with one commandlpmYesPM2Yes
- Primary focuslpmlocal dev workflowPM2production-first
- Local file-watch restart modelpmvia service commandPM2pm2-dev / --watch
- Per-service live output panelpmYesPM2logs / attach
- Native macOS desktop applpmYesPM2No
- Visual multi-project switcherlpmYesPM2No
- Generates project config from your repolpmYesPM2No
- Runs Node, Python, shell commands, and binarieslpmYesPM2Yes
- Duplicate a project for a second AI agentlpmYesPM2No
- Designed for Claude Code / Codex in parallellpmYesPM2No
- Cluster mode across CPU coreslpmNoPM2Yes
- Auto-restart on crash with backofflpmNoPM2Yes
- Runs at server boot (pm2 startup / save)lpmNoPM2Yes
- Zero-downtime reload on deploylpmNoPM2Yes
- Log rotation and centralized log fileslpmlive dev panesPM2log files; rotation add-on
- CPU / memory monitoring dashboardlpmno resource dashboardPM2pm2 monit + Plus
- Config formatlpmname + command per servicePM2ecosystem.config.js
- Open source, freelpmYesPM2Yes
When each one is the right tool
Both run multiple processes. PM2 is strongest as a supervisor and also offers local watch mode; lpm specializes in an interactive multi-project Mac workspace.
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.
You need deployment supervision or already rely on PM2's local watch workflow.
- 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 want pm2-dev or --watch to restart a local application when its files change.
Projects, terminals, agents, a built-in browser — one click each
A recording of lpm booting a project and handing it to Claude Code — lpm is a macOS app, so the clickable demo runs on desktop.Click anything — it runs live in your browser.
lpm is a macOS app with a multi-pane terminal workspace. Open this page on your computer to try the interactive demo.
Get lpm for MacOr check your Macs from your iPhone
Done poking around? Get lpm for Mac and point it at your own projects.
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 local dev-workflow tool. PM2 is production-first, with cluster mode, crash recovery, boot persistence, and zero-downtime reloads; it also provides pm2-dev and watch mode for local development. If you are deploying an app to a server, use PM2. If you want a visual workspace around local services and agents, use lpm.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?
PM2 can start Python applications, shell commands, and binaries as well as Node apps. lpm's difference is the local workspace around those processes: repo detection, generated service config, one pane per service, project switching, and isolated copies for parallel agents. If you need a server supervisor, choose PM2; if you need that interactive Mac workflow, choose lpm.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 small per-project config file you can read, edit, and commit, where each service is just a name and a 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. Or let lpm read the repo and generate the config for you.Can I keep PM2 for production and use lpm locally?
Yes. Keep ecosystem.config.js and PM2 in your deployment workflow, then add an lpm config for the local commands you actively develop against. That avoids nesting two process supervisors while preserving PM2's production behavior and giving local development lpm's service panes, project switcher, and parallel-agent copies.PM2 vs tmux — which one for local development?
They do different jobs. PM2 is a restart-on-crash process daemon: it keeps processes alive in the background and brings them back when they die. tmux is persistent interactive sessions and panes: terminals you can watch, scroll, and type into. Neither covers the whole local-dev job alone, and some people run both — tmux for the interactive session, PM2 for supervision. lpm covers that overlap in one Mac app: a live pane per service you can read and interact with, plus start/stop lifecycle per project.
Keep PM2 for supervision. Add lpm for the workspace.
Use the tool that matches the job: PM2 for mature runtime supervision, lpm for per-service panes, multi-project switching, and parallel AI-agent workflows.