A tmux alternative for local dev stacks — panes without config.
tmux is a wonderful terminal multiplexer. lpm is a project manager for your local dev stacks that happens to give you the same pane-per-service layout for free. If you only use tmux to wire up your dev stack, this page is for you.
Where each tool earns its keep
tmux wins on persistence, ubiquity, and raw flexibility. lpm wins on first-class projects, zero-config start, and a desktop app. Here is the honest side-by-side.
| Capability | lpm | tmux |
|---|---|---|
| One-command project start | Yes | via tmuxinator |
| Zero config to run a detected stack | Yes | No |
| Auto-detect Rails, Next.js, Go, Django, Flask, Docker Compose | Yes | No |
| Pane-per-service live output | Yes | Yes |
| Native macOS desktop app with visual switcher | Yes | No |
| Multi-project management as a first-class concept | Yes | via tmuxinator |
| Start / stop / duplicate projects as first-class ops | Yes | manual |
| Built for running AI agents (Claude Code, Codex) in parallel | Yes | manual |
| Session detach / reattach across terminal restarts | Yes | Yes |
| Works over SSH on any Unix box | remote projects + port forwarding | Yes |
| Fully scriptable keybindings and layouts | No | via .tmux.conf |
| Tiny footprint, ubiquitous on Unix systems | No | Yes |
- One-command project startlpmYestmuxvia tmuxinator
- Zero config to run a detected stacklpmYestmuxNo
- Auto-detect Rails, Next.js, Go, Django, Flask, Docker ComposelpmYestmuxNo
- Pane-per-service live outputlpmYestmuxYes
- Native macOS desktop app with visual switcherlpmYestmuxNo
- Multi-project management as a first-class conceptlpmYestmuxvia tmuxinator
- Start / stop / duplicate projects as first-class opslpmYestmuxmanual
- Built for running AI agents (Claude Code, Codex) in parallellpmYestmuxmanual
- Session detach / reattach across terminal restartslpmYestmuxYes
- Works over SSH on any Unix boxlpmremote projects + port forwardingtmuxYes
- Fully scriptable keybindings and layoutslpmNotmuxvia .tmux.conf
- Tiny footprint, ubiquitous on Unix systemslpmNotmuxYes
Which one should you actually use?
tmux and lpm do different jobs that overlap only at 'run services in panes.' Pick based on what you really need, not on which tool is newer.
You use tmux mostly as a crude process manager for your dev stack.
- You open a project and immediately run rails s, npm dev, redis, and a worker in separate panes — every single time.
- You do not want to maintain a .tmux.conf or a tmuxinator YAML for every project.
- You juggle multiple local projects and want a visual switcher that remembers them.
- You want to run Claude Code, Codex, or other AI agents in parallel with every service's output visible at once.
- You like the idea of a native macOS desktop app with live per-service panes and a config you can read, edit, and commit.
You already love tmux and use it for much more than starting services.
- You have years of muscle memory and a .tmux.conf you actually enjoy.
- Your session lives on the remote box itself and you reach it from any machine — tmux runs there; lpm drives remote projects from a Mac app instead.
- You need sessions you can reattach from any SSH login, not from a desktop app.
- You use tmux for vim splits, logs, monitoring, ops work — not just dev servers.
- You already have a tmuxinator or zellij layout that fits your brain perfectly.
- You work on a platform other than macOS — lpm is macOS-only.
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 tmux, answered honestly
Can I still use tmux alongside lpm?
Absolutely. lpm manages your project's services — it has no opinion on your editor, shell, or terminal setup. Keep tmux for SSH, long-lived sessions, vim splits, and anything else you already use it for. Let lpm handle the boring part: starting the dev stack when you open a project.Does lpm use tmux under the hood?
What matters is the behavior: your services run in persistent sessions that survive app and terminal restarts, and each one gets its own scrollable pane in the desktop app. There's nothing for you to set up, configure, or attach to — no .tmux.conf to edit, no keybindings to memorize, no windows to attach to by name. You get the persistence and per-service visibility you'd normally build with tmux, without setting any of it up.What about my remote / SSH workflow?
lpm can attach remote dev boxes as SSH projects — run remote services in panes beside local ones and forward remote ports to localhost from the app. That said, if your entire session lives inside SSH on a remote box and you reach it from arbitrary machines, tmux on that box is still the right tool — lpm is not trying to replace it there.Is this basically tmuxinator with a GUI?
Overlapping goals, different shape. tmuxinator gives you named, YAML-defined tmux layouts per project. lpm gives you managed projects with live pane output, a visual switcher, and first-class start / stop / duplicate. If your tmuxinator file is mostlyrails s,npm dev,redis, andsidekiq, lpm will feel like a shortcut. If you lean on custom layouts, splits, and keybindings, tmuxinator will still suit you better.How do I move a tmuxinator project over to lpm?
Point lpm at the directory and let it generate the service config from your repo, or define the services yourself — each one is just a name and a command. Then start the project from the app. You can keep the tmuxinator file around as a fallback; lpm won't touch it. Source and examples are on GitHub.PM2 vs tmux — which one for local development?
Different jobs, so the comparison is a bit of a trap. PM2 is a restart-on-crash process daemon: it keeps processes alive in the background and restarts them when they die. tmux is persistent interactive sessions and panes: terminals you watch, scroll, and type into. Some people run both — tmux for the interactive session, PM2 for supervision. If what you actually want is the local-dev overlap of the two, that's the job lpm does: a live pane per service plus start/stop lifecycle, in one Mac app.
Keep tmux. Let lpm start the boring stuff.
lpm is free, open source, and runs as a native macOS app. Point it at a project, hit Start, and get your whole stack running with per-service output — no tmux config required.