Four processes, one repo, twenty times a day. Terminal tabs, a multiplexer, a Procfile runner, a container stack, a production supervisor — each solves part of it. Here is the whole field in one table, an honest verdict on each, and where lpm fits.
The short answer
It depends on how many processes there are and how often you restart them. One process: any terminal. Four processes you restart all day: you want one command that starts them all and one pane per process — that is what tmux, Foreman, Overmind, Docker Compose and PM2 each do differently. Several repos at once, or a coding agent working beside the services: you want the project itself to be the thing you start and stop.
The five families, one line each. Terminal emulators (iTerm2, cmux) give you panes and leave the wiring to you. Multiplexers (tmux) make those panes survive a disconnect. Procfile runners (Foreman, Overmind) start a fixed list of named processes with one command. Container stacks (Docker Compose) also build the environment those processes run in. Supervisors (PM2) keep processes alive and restart them when they die. lpm is a shape of its own: the project is the object — start it, stop it, duplicate it, and give Claude Code or Codex a tab of its own next to the services.
Foreman and Overmind run straight off a Procfile you already have, Docker Compose off a compose file, and all three read it again on every start. lpm uses either one once, when you add the folder — a service per Procfile line, or a single docker compose up for the compose file — and keeps a list of its own after that. Five of the seven also run somewhere other than a Mac; lpm does not, and the table below says so.
Procfile web: bin/rails server
css: bin/rails tailwindcss:watch
compose.yaml services:
web: { command: bin/rails server }
.lpm.yml services:
web: bin/rails server
css: bin/rails tailwindcss:watchThe shapes barely differ — a name and a command. What differs is what happens after they are running. For the lpm side of it, see the full field list.
Thirteen rows, each one a place where the eight columns genuinely differ. Two of them go against lpm.
| Capability | lpm | iTerm2 | tmux | cmux | Docker Compose | Foreman | Overmind | PM2 |
|---|---|---|---|---|---|---|---|---|
| Has a desktop app, not just a command line | Yes | Yes | No | Yes | Docker Desktop | No | No | No |
| One live pane per process, no scripting | Yes | you split them | you script it | you script it | interleaved | interleaved | one tmux window each | pm2 logs |
| Many repos as switchable projects | Yes | profiles | sessions | workspaces | No | No | No | No |
| Restart one process without the rest | Yes | No | respawn by hand | No | Yes | No | Yes | Yes |
| Brings a crashed process back on its own | No | No | No | No | with a restart policy | No | start -r | Yes |
| Works out the services from package.json, Gemfile or go.mod | built in, when you add the folder | No | No | No | No | No | No | No |
| Duplicates the project for a second agent | worktree or full copy, 1–50 | No | No | No | No | No | No | No |
| Says whether an agent is working, needs you or done | Claude Code, Codex | Claude Code, since 3.7 | No | when it needs you | No | No | No | No |
| Runs services natively, no containers | Yes | Yes | Yes | Yes | No | Yes | Yes | Yes |
| Services survive quitting the app | Yes | only via tmux | Yes | reopens panes | detached | No | Yes | Yes |
| Reads a Procfile or compose file you already have | once, when you add the folder | No | No | No | its compose file, every start | the Procfile, every start | the Procfile, every start | No |
| Available outside macOS | macOS only | No | Linux, *BSD | No | Linux, Windows | Linux | Linux, *BSD | Linux, Windows |
| Free and open source | MIT | GPLv2 | Yes | GPL-3.0-or-later | Apache-2.0 | Yes | MIT | Yes |
The lpm column covers the app and its lpm command together. Anything that changes what is running — starting, stopping, restarting — is the app's job, and the command hands it over, so keep lpm open for those; reading what is already running (lpm list, lpm logs) works either way.lpm's desktop app is macOS only. A Linux box can take the other end of it — the services and the agents run there, the Mac drives them — see the guide.Duplicating a project gives each agent its own checkout, so two of them never save over each other's work; the ports and the database underneath stay shared, and lpm checks the ports a project declares before it starts and names whatever process is holding one. A worktree copy brings across only the files git tracks — no .env, and Node packages only if you ask lpm to install them — here is what else it leaves behind.
Facts checked . Where we cannot name a workflow difference we do not invent one — two rows above go against lpm.
You run each process in its own terminal tab
You have a .tmux.conf or a tmuxinator file
rails s, npm dev and a worker.You have a Procfile
foreman export for launchd, systemd and five other init formats.foreman export, or the Procfile is a file you keep editing: lpm lifts its lines in once, as you add the folder, and later edits stay on Foreman's side.overmind connect attaches one process, overmind restart bounces one.-m web=2,worker=3 scaling, or a PORT handed to each process.You have a compose file
docker compose up as one of its services, beside any native ones it found.You use pm2 for local dev
pm2 startup, or zero-downtime reload. Different jobs — plenty of people run both.You are choosing a terminal for coding agents
Either way, read the agent-workflow guide →
The row every tool in the table implements differently: what starting the whole stack looks like when the project is the thing you start.
Procfile.dev — or Procfile when there is no .dev one — turns into one service per line under the same names and commands, minus the release line, and a compose file turns into a single docker compose up service beside the native ones. From then on the list belongs to lpm: a later edit to the Procfile is not picked up, whereas Foreman, Overmind and Compose go back to their file on every start.The agent half of this table: a tab per agent, its status, and the services still running underneath.
Where lpm's own terminal lands next to iTerm2, Terminal.app, Hyper and Warp.
Reach a machine over SSH and keep it in the sidebar beside your local projects.
Every key a service, profile or action accepts, and which file each one belongs in.
What a second checkout gives an agent, and what it quietly leaves behind.
Driving a headless Linux host from the Mac — the only Linux in the table lpm has a story for.
Free, open source, native macOS app. No lock-in — lpm starts and stops native processes the same way you would.