Skip to content
lpm vs Overmind

An Overmind alternative for Mac — your Procfile as live panes, no tmux.

Overmind runs each Procfile line as a tmux window and asks you to install tmux first. lpm imports the same named commands and runs them as panes in a Mac app: click one to read its output, stop or restart one without the rest, start them in dependsOn order.

Five rows go to Overmind. If any of them is load-bearing for you, stay where you are.

See the Procfile conversion

Facts checked against Overmind's own README, its releases page, Foreman's man page and tmux's manual page. Overmind's flags and commands here all come from its README, the Foreman line from its man page, and the detach behaviour from tmux's. lpm's own rows were re-read in the app source the same day, after lpm began importing Procfiles.

The short answer

Is there an Overmind alternative for Mac that does not need tmux?

Yes. Overmind here means DarthSim/overmind, the Procfile runner linked above, which drives each of your services as a tmux window. Its README is explicit that tmux is a prerequisite you install first.

lpm does the same job from a native Mac app. Each process in your config lands in a pane of its own, holding its last 10,000 lines, and you can stop and start any one of them without touching the rest, or run lpm service web restart. One that crashes stays down, its output kept. Those panes are for reading rather than typing — dropping you at a prompt inside a running process is the one thing overmind connect does that lpm has no answer for. Nothing here runs on tmux, so there is no multiplexer to install first. Your Procfile stays where it is: lpm imports its lines once, when you add the folder, and the shape carries over unchanged.

What you give up: lpm reads the Procfile once rather than on every start, will not hand each process a PORT, will not run two copies of one process, and needs a Mac to drive it. Everything else on this page is what you get in exchange.

Procfile → ~/.lpm/projects/myapp.yml
web: bundle exec puma -C config/puma.rb      →  services:
worker: bundle exec sidekiq                       web:
css: bun run watch:css                              cmd: bundle exec puma -C config/puma.rb
                                                    port: 3000
                                                  worker:
                                                    cmd: bundle exec sidekiq
                                                    dependsOn: [web]
                                                  css: bun run watch:css

Overmind

Keep Overmind

-m web=2,worker=3 to scale a process, a PORT stepped per process with ‑p and ‑P, Linux and *BSD, and a Procfile it reads fresh on every start.

lpm

Switch to lpm

No tmux to install, a project switcher across repos, dependsOn for start order, and Claude Code or Codex in a tab beside the services.

Both

Run both

Nothing conflicts. lpm never touches your Procfile or your .overmind.env, so the Overmind workflow you already have keeps working.

The conversion

Your Procfile, line for line

lpm writes the three services on the right when you add the folder — same names, same commands. The port label, dependsOn and the profile are what you add after. Keep the Procfile in the repo if Heroku or Foreman still needs it.

Procfile
web: bundle exec puma -C config/puma.rb
worker: bundle exec sidekiq
css: bun run watch:css
~/.lpm/projects/myapp.yml
services:
  web:
    cmd: bundle exec puma -C config/puma.rb
    port: 3000
  worker:
    cmd: bundle exec sidekiq
    dependsOn: [web]
  css: bun run watch:css
profiles:
  api: [web, worker]
  • dependsOn orders the start: worker goes up after web, whatever order the lines sit in. It sequences the starts rather than waiting for readiness — that is what lpm wait is for.
  • profiles start a subset: lpm start --profile api, where Overmind takes overmind start -l web,worker or OVERMIND_PROCESSES.
  • port: is a label lpm checks for conflicts before starting, and it names the process holding one. It is not assigned to your process, so keep exporting PORT yourself. Commit the same services and profile as .lpm.yml in the repository to share them.

Every field a service takes — cmd, cwd, port, env, dependsOn — is in the config reference.

See it

Every process, its own live pane

What overmind start produces in tmux windows, produced instead as panes you click.

How it compares

Where the two tools differ

Fifteen rows. Five of them go to Overmind — the first four, plus typing at a running process — and those five are the honest reason to stay.

  • Picks up Procfile edits on the next start
    lpm
    no — imported once, when the project is added
    Overmind
    Yes
  • Automatic PORT allocation
    lpm
    port declared for conflict checks, not assigned
    Overmind
    PORT stepped per process (-p / -P)
  • Scales one process to several instances
    lpm
    one process per service
    Overmind
    -m web=2,worker=3
  • Which machines it runs on
    lpm
    Mac app; Linux and SSH boxes as hosts
    Overmind
    macOS, Linux, *BSD
  • Whether tmux has to be installed first
    lpm
    no — lpm does not use tmux
    Overmind
    yes — install tmux, then Overmind
  • Reads a config committed in the repo
    lpm
    .lpm.yml
    Overmind
    Procfile
  • Drafts the config for you
    lpm
    built in, from the Procfile and other manifests; Claude Code, Codex, Gemini CLI or OpenCode can redraft it
    Overmind
    No
  • Type at one running process
    lpm
    No
    Overmind
    overmind connect
  • Restart web without restarting worker
    lpm
    Yes
    Overmind
    Yes
  • Start order you declare, not line order
    lpm
    dependsOn
    Overmind
    No
  • Start a subset of processes
    lpm
    --profile
    Overmind
    -l / OVERMIND_PROCESSES
  • Port conflict caught at start, holder named
    lpm
    Yes
    Overmind
    No
  • What a session survives
    lpm
    quitting the app
    Overmind
    closing the terminal
  • Running it on a remote dev box
    lpm
    SSH projects, declared ports forwarded to localhost automatically
    Overmind
    run it on the box yourself
  • Run the project in several copies at once
    lpm
    1–50 worktrees or standalone copies
    Overmind
    No

Read the five rows lpm loses twice. Overmind reads your Procfile afresh every time it starts where lpm imported it once, hands each process a PORT, runs several instances of one process, installs on Linux and *BSD where lpm needs a Mac to drive from, and drops you at a prompt inside a running process with overmind connect. If one of those five is load-bearing, stay where you are — nothing below outweighs a workflow that already works.

Muscle memory

Every overmind command, translated

The overmind verbs you type in a day, and what replaces each one. The last two rows have no overmind command to translate.

  • overmind

    overmind start

    lpm

    lpm start
  • overmind

    overmind start -l web,worker

    lpm

    lpm start --profile api
  • overmind

    overmind restart web

    lpm

    lpm service web restart
  • overmind

    overmind stop worker

    lpm

    lpm service worker stop
  • overmind

    overmind connect web

    lpm

    click the service's tab in the project, or lpm logs web -n 500
  • overmind

    overmind echo

    lpm

    open the project; each service's output is already in its pane
  • overmind

    overmind run yarn install

    lpm

    lpm run --command "yarn install"

    a one-off command in the project's folder

  • overmind

    overmind kill

    lpm

    lpm stop

    lpm reaps each service's process tree

  • overmind

    —

    lpm

    lpm wait --service web

    block a script until the service is up

  • overmind

    —

    lpm

    lpm duplicate -n 3 --run claude --prompt "…"

    three copies of the project, an agent running in each

Anything that changes what is running — lpm start, lpm stop, or a lpm service … restart — goes through the app, so keep lpm open: it owns the panes. lpm logs and lpm list only read, so they answer from a cold shell — lpm list is where you see how many services a project has up.

Honest take

Pick the tool that matches how you actually work

Pick lpm

You want a GUI, multiple projects open at once, and room for AI agents.

  • You switch between two or more local projects during the day and want a visual sidebar, not separate terminal windows.
  • You point Claude Code, Codex, Gemini CLI, or OpenCode at the same stack and want each agent's output in its own pane beside the services it is breaking.
  • You would rather not install tmux to run a Rails or Next.js stack.
  • Reading a service's last 10,000 lines and restarting just that one is enough — you do not need to type at the process itself.
  • You want the stack startable by someone who has never opened a multiplexer — the panes are already there when the project starts.
  • You want one prompt tried three ways: lpm copies the project up to 50 times and starts an agent in each — separate checkouts, so no two agents edit one file, but the same declared ports and the same database underneath, and a linked worktree starts with no .env, and with no node_modules unless you tick Install dependencies.
Pick Overmind

You live in tmux, stay on the CLI, and want native Procfile features.

  • You already have tmux muscle memory and prefer keyboard-driven window management.
  • You develop over SSH on a remote box, where a dropped connection leaves the tmux session running and overmind connect picks the process back up.
  • You use overmind start -m web=2,worker=3, or you rely on Overmind handing each process a PORT.
  • Your workflow is one project at a time and you're happy driving everything from the shell.
  • Your team develops on Linux or *BSD as well as macOS.
See it in action

Run only the services you need

A short video: a profile starts just the services it names.

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
FAQ

Switching from Overmind

  • Do I have to throw away my Procfile?
    No. lpm imports it when the project is added — one service per line, same names — and leaves the file as it was for Heroku or Foreman. From then on lpm starts from its own service list, so a Procfile change made later does not carry over by itself.
  • Does lpm need tmux?
    No. lpm does not use tmux and never asks you to install it. Your services keep running when you quit lpm and they are there when you reopen it — nothing to attach to.
  • How do I attach to one process the way overmind connect does?
    You do not, and this is the clearest thing Overmind does that lpm does not. Clicking a service brings up its pane with 10,000 lines of scrollback, but that pane is read-only: there is no prompt to type at, so a pry or byebug session inside a running process is an Overmind job. What lpm gives you instead is restarting that one process without touching the others, and reading its output back from the app or with lpm logs.
  • Does lpm assign each process a PORT like Overmind?
    No. In lpm port: is a label used to check for conflicts before a start and to name the process holding one; you still export PORT yourself. If automatic assignment is what keeps your Procfile portable, that is a real reason to stay on Overmind.
  • Overmind, Foreman or lpm — where does each fit?
    Foreman interleaves one log stream in a single terminal. Overmind gives each process a tmux window you can attach to. lpm gives each one a pane in a Mac app, plus a project switcher and a service list you can commit.
  • Can I use lpm on a remote dev box?
    Two ways: attach it as an SSH project, so its services get panes beside your local ones with ports forwarded to localhost, or pair a Linux machine as a headless host and drive it from the Mac app.

Your Procfile, as panes you can click.

lpm converts the lines as you add the folder. Each process opens as a pane you can click, stop or restart without the rest, and read 10,000 lines back — with no tmux installed anywhere. Free and open source on GitHub.