Skip to content
All comparisons
lpm vs tmux

A tmux alternative for Mac dev stacks — panes without .tmux.conf.

tmux is a fine multiplexer and this page does not pretend otherwise. What it does not know is what a project is: which commands belong together, which order they start in, and which repo they came out of.

Most people asking for a tmux alternative want one of tmux's three jobs. lpm takes that one.

Download for macOSApple SiliconIntel Mac? Get the x86-64 build
Developer ID signed · Notarized by AppleSafety, checksums & removal
Coming from tmuxinator
View on GitHub

Facts checked against the tmux manual and the tmuxinator README. Where tmux is the better tool the comparison below says so, in three of its fifteen rows; every lpm cell was read off the app's own source.

The short answer

Is there a tmux alternative for running a local dev stack on a Mac?

Yes, if what you want from tmux is one pane per service. lpm is a macOS app that starts every service in a project at once, each in its own live pane, from a short service list instead of a .tmux.conf. It does not use tmux and does not need it installed — quit lpm and your dev servers keep running; reopen it and it finds them again.

Each pane keeps 10,000 lines of scrollback, and you restart one service with lpm service web restart instead of respawning a pane by hand. When the repo has a package.json dev script, a Procfile, a Rails Gemfile or a go.mod, lpm writes that list itself as you add the folder; anything it misses is a service name and a command, so translating a tmuxinator window list takes about a minute.

~/.lpm/projects/myapp.yml
name: myapp
root: ~/Projects/myapp

services:
  web: npm run dev
  api: go run ./cmd/server
  db: docker compose up postgres

Then press Start, or run lpm start myapp from any terminal while the app is open. tmux is still the better answer for a session that lives on a remote box, for vim splits, and for anything you have already bound to a key — this page is about the one job the two tools overlap on.

tmux

Keep tmux for

Remote sessions you reach from any machine, vim splits, ops work, and a .tmux.conf you actually enjoy.

lpm

Swap in lpm for

Starting and stopping a project's whole stack, switching between projects, and watching Claude Code or Codex work beside the services.

Both

Run both

lpm has no opinion on your shell or terminal, and it does not touch your .tmux.conf or your tmuxinator files. Nothing to uninstall.

Be specific about what you use it for

tmux does three jobs. lpm replaces one of them.

lpm takes this

Getting the dev stack up

Every morning: four panes, four commands, in the same order. In lpm that is a services map drafted from your repo when you add it, and a Start button, with dependsOn for the ones that must come up first and profiles for the days you only need the front end.

tmux keeps this

Sessions that outlive the terminal

If the session lives on a remote box you reach from a laptop, a phone and a machine at the office, tmux on that box is the right tool. lpm drives remote boxes as projects from a Mac; it does not replace a multiplexer you attach to over SSH.

tmux keeps this

Windows, splits and keys

Prefix keys, copy mode, custom layouts, vim splits. lpm has splits, three remappable app hotkeys and a shortcut you can bind to any action — not a scripting surface. If your .tmux.conf is a pleasure to use, keep it.

Most people asking for a tmux alternative want job one and have never wanted jobs two and three.

How it compares

Where each tool earns its keep

tmux wins on persistence, portability and raw scriptability; lpm wins on projects, a drafted config and a desktop app. Three rows below go to tmux outright — your own shells across a restart, keys and layouts in a config file, and where you install each tool — and one goes to neither.

  • One command brings the whole project up
    lpm
    Start button; lpm start myapp needs lpm running
    tmux
    via tmuxinator
  • Service list drafted from your repo, then yours to edit
    lpm
    package.json, Procfile, Gemfile, go.mod, compose and more, read as you add it
    tmux
    No
  • Redrafts the whole config with your own agent CLI
    lpm
    Claude Code, Codex, Gemini CLI or OpenCode
    tmux
    No
  • One live pane per service
    lpm
    Yes
    tmux
    Yes
  • Scrollback kept per service pane
    lpm
    10,000 lines, and no setting to change it
    tmux
    2,000 by default, raise it with history-limit
  • Restart one service without touching the others
    lpm
    lpm service web restart
    tmux
    respawn-pane by hand
  • Services keep running after you quit the app
    lpm
    Yes
    tmux
    Yes
  • Your own shells survive a restart too
    lpm
    tabs come back; Claude Code and Codex resume their conversation, shells start fresh
    tmux
    Yes
  • Restarts a crashed service automatically
    lpm
    No
    tmux
    No
  • Which agent needs you, shown on its own tab
    lpm
    working, needs you, done or error, from Claude Code and Codex
    tmux
    No
  • Runs with no tmux installed
    lpm
    Yes
    tmux
    No
  • Switch projects from a sidebar that remembers them
    lpm
    Yes
    tmux
    via tmuxinator
  • Attach a remote box and run its services in the same window
    lpm
    from the Mac app
    tmux
    on the box itself
  • Remap every key and script custom layouts in a config file
    lpm
    three remappable app hotkeys, plus a shortcut per action
    tmux
    via .tmux.conf
  • Where you install it
    lpm
    a Mac app; a Linux box joins as a remote host
    tmux
    on each Unix box you use it on

The sidebar remembers the projects you add, the folders you put them in and the order you leave them — there is more on the project sidebar.

Migration

Coming from tmuxinator

A tmuxinator project is a window list. An lpm project is a service map. The translation is mechanical, and adding the folder already does most of it.

~/.config/tmuxinator/myapp.yml
name: myapp
root: ~/Projects/myapp

windows:
  - web: npm run dev
  - api: go run ./cmd/server
  - db: docker compose up postgres
~/.lpm/projects/myapp.yml
name: myapp
root: ~/Projects/myapp

services:
  web: npm run dev
  api:
    cmd: go run ./cmd/server
    cwd: ./backend
    dependsOn: [db]
  db: docker compose up postgres

Two things a window list cannot express: dependsOn, so db is up before api goes looking for it, and profiles, so profiles: { frontend: [web] } gives you a smaller stack on the days you do not need the rest. dependsOn sets the order, not readiness — lpm wait --port 5432 is the gate. Put the same services in a .lpm.yml at the repo root and your team gets them on clone, next to anything lpm picks up from the repo on their machine. The reference documents every field a project file takes.

Command map

What you type instead

The tmux and tmuxinator lines a dev stack actually uses, next to the lpm line that does the same job.

  • tmux / tmuxinator

    tmuxinator start myapp

    lpm

    lpm start myapp

    Or press Start on the project.

  • tmux / tmuxinator

    tmux ls

    lpm

    lpm list

    Running state and service counts, plus agents when lpm is up.

  • tmux / tmuxinator

    tmux attach -t myapp

    lpm

    click the project in the sidebar

  • tmux / tmuxinator

    tmux kill-session -t myapp

    lpm

    lpm stop myapp

  • tmux / tmuxinator

    tmux capture-pane -p -t myapp:web

    lpm

    lpm logs web -n 200

    Trailing lines of that service's pane.

  • tmux / tmuxinator

    respawn one pane

    lpm

    lpm service web restart

    The other services keep running.

  • tmux / tmuxinator

    set -g history-limit 2000

    lpm

    nothing to set; 10,000 lines per pane

  • tmux / tmuxinator

    —

    lpm

    lpm wait --port 3000

    Block a script until the stack is listening.

These fall into two groups. lpm start, lpm stop and lpm service … restart hand the work to the app, and lpm status asks it what your agents are doing — so those four want lpm open. lpm list, lpm logs and lpm wait --port read your running services themselves, from any shell, whether lpm is up or not.

See it

A project, defined once

Adding a project and shaping its service list in the built-in editor — the whole of what replaces your tmuxinator file.

Honest take

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.

Pick lpm

You mostly use tmux to get your dev stack running.

  • 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 Claude Code and Codex running beside the services, with working / needs-you / done / error on each tab.
  • You want a config you can read, edit, and commit as .lpm.yml so the next person gets the same stack.
Pick tmux

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 have a tmuxinator or zellij setup that fits your brain perfectly — lpm will not talk you out of it.
  • You work on a platform other than macOS — lpm is macOS-only.
See it in action

Start a project, then hand it to Claude Code or Codex — one click each

A one-minute tour: start a project and hand it to Claude Code.

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

lpm vs tmux, answered honestly

  • Do I need tmux installed to use lpm?
    No — tmux is not a dependency. lpm runs each service in a pane it owns, and it never installs tmux for you. If tmux is already on your machine, keep it: your .tmux.conf and your existing sessions are untouched.
  • Does lpm use tmux under the hood?
    No. Quit lpm and your dev servers keep running; reopen it and it finds them again. Each service keeps 10,000 lines of scrollback — tmux ships with 2,000 until you raise history-limit — and there is no .tmux.conf to maintain, no prefix key to learn, and no session name to attach to. lpm keeps a config too — the services map above, which it drafts from the repo when you add it — but it is names and commands, not keybindings.
  • Can I keep using 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.
  • 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 mostly rails s, npm dev, redis, and sidekiq, lpm will feel like a shortcut. If you lean on custom layouts, splits, and keybindings, tmuxinator will still suit you better.
  • What about my remote or SSH workflow?
    lpm can attach a remote dev box as an SSH project: its services run in panes beside your local ones, and each port a service declares is forwarded to localhost once it starts listening. The box needs SSH and bash — no tmux server to install there either. lpm does not detect an SSH project's services, so you list them yourself. If your whole session lives inside SSH and you reach it from arbitrary machines, tmux on that box is still the right tool.
  • What about zellij?
    Same answer as tmux: lpm does not use zellij either, and does not need it installed. If zellij is where you live, keep it — lpm's job is bringing a project's services up in its own panes, and it has no opinion on what you attach to for everything else.

Keep reading

lpm vs Overmind

For anyone whose service list already lives in a Procfile: lpm imports it once, when the folder is added.

lpm vs PM2 for local dev

lpm does not restart a service that dies. That trade-off, at length.

SSH projects on a Mac

Attach a dev box over SSH: its services get panes in the same window as the local ones.

A sidebar of projects

Every repo you work in, in folders, in the order you left them.

The config reference

What a project file takes: services, dependsOn, profiles, declared ports, actions.

Claude Code and Codex beside the stack

The agent tabs that sit next to the service panes, and the working or needs-you state each one shows.

Keep tmux. Let lpm bring the stack up.

lpm is free, MIT-licensed, and runs as a native macOS app. Add the folder, check the services it lists, press Start, and every service comes up in its own pane — with no tmux installed.

Download for macOSApple SiliconIntel Mac? Get the x86-64 build
Developer ID signed · Notarized by AppleSafety, checksums & removal
View on GitHub