Skip to content
All comparisons
lpm vs Docker Compose

A Docker Compose alternative for fast native development.

Docker Compose is excellent for prod parity and cross-team reproducibility. lpm is about the daily native dev loop on one machine — with per-service panes, a project switcher, and room for AI agents alongside your stack.

Download for macOS (Apple Silicon)Intel Mac? Get the x86-64 build
Developer ID signed · Notarized by AppleSafety, checksums & removal
View on GitHub
How it compares

Docker Compose and lpm, feature by feature

Different jobs. Rows where Compose clearly wins are called out honestly — nothing here is a dunk.

  • Starts a multi-service dev stack in one command
    lpm
    Yes
    Docker Compose
    Yes
  • Declares startup order between services
    lpm
    start order
    Docker Compose
    order + health gate
  • Runs services natively on the host
    lpm
    Yes
    Docker Compose
    No
  • Containerized service isolation
    lpm
    No
    Docker Compose
    Yes
  • Cold start after a code change
    lpm
    native speed
    Docker Compose
    container rebuild
  • macOS file I/O speed for mounted source
    lpm
    native FS
    Docker Compose
    volume sync overhead
  • Per-service live output pane in a native app
    lpm
    Yes
    Docker Compose
    docker compose logs
  • Visual project switcher across multiple repos
    lpm
    Yes
    Docker Compose
    No
  • Prod-parity service versions (Postgres 15.3, Redis 7.2, etc.)
    lpm
    use host versions
    Docker Compose
    Yes
  • Reproducible across team machines and OSes
    lpm
    Partial
    Docker Compose
    Yes
  • Auto-detects docker-compose.yml and can run it
    lpm
    Yes
    Docker Compose
    Yes
  • Designed for parallel AI coding agents on host
    lpm
    Yes
    Docker Compose
    No
  • Native macOS desktop app with shared config
    lpm
    Yes
    Docker Compose
    CLI only
  • Open source, free
    lpm
    Yes
    Docker Compose
    Yes
Honest take

When each one is the right tool

A friendly split. If your daily loop is native code running on your laptop, lpm leans in. If your daily loop depends on containerized infra matching prod, Compose still wins.

Pick lpm

You want fast native startup, per-service panes, and space for AI agents next to your stack.

  • You do most of your dev natively on macOS and Docker volume sync has been slowing you down.
  • You want your Rails server, Next.js frontend, worker, and a Redis process each in their own live pane.
  • You juggle multiple projects and want a visual switcher instead of remembering which compose file is running where.
  • You run Claude Code, Codex, or Cursor in parallel on the same or adjacent codebases and want their output visible alongside your services.
  • You already have a docker-compose.yml — lpm can drive it as one service while you move the rest native.
  • You want a native macOS desktop app to manage your services, not a terminal-only workflow.
Pick Docker Compose

You need prod parity, team reproducibility, or real container isolation for local dev.

  • Your production runs on containers and you want dev to match the exact Postgres, Redis, or Kafka versions.
  • Your team spans multiple operating systems and reproducible local infra matters more than startup speed.
  • You rely on complex service networking, named volumes, or health checks that Compose expresses cleanly.
  • You want strong isolation — each service in its own container, its own filesystem, its own network namespace.
  • Your CI, staging, and prod pipelines are container-based and your dev environment should stay in that ecosystem.
See it in action

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.

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 — or alongside — Docker Compose

  • Can I use lpm and Docker Compose together?
    Yes, and this is the common case. lpm can run compose up as one of your services alongside native processes. So you can keep Postgres and Redis in containers for prod parity while running your Rails or Next.js app natively, and watch every pane — container logs included — in the same desktop app. They are not mutually exclusive.
  • Does lpm replace Docker Compose?
    For some workflows, yes; for others, no. If you're a solo or small-team dev doing native work on macOS and Compose was mostly a way to launch a process tree, lpm covers that with per-service panes and multi-project switching. If you rely on Compose for prod-parity service versions, cross-OS team reproducibility, or container-first deploy pipelines, keep using Compose. lpm doesn't try to be a container runtime.
  • Why would I run things natively instead of in containers on macOS?
    Speed, mostly. Docker Desktop on macOS runs a virtualized environment and shares your source over a virtualized filesystem, which adds latency to file watching, bundle installs, test runs, and hot reloads. Native processes read your disk directly. Cold start is also instant — no image build, no container create, no volume mount. For the inner dev loop on one machine, native is usually faster; for prod parity and team reproducibility, containers are usually better.
  • Can I run Claude Code or Codex against services lpm started?
    Yes, and that's a big part of why lpm exists. Agents run natively on your host and talk to whichever services lpm brought up — native processes, compose-backed services, or a mix. Each project gets its own entry in the desktop app with live panes per service, so you can run one agent against one project and another agent against a duplicated project without them fighting over ports or tabs.
  • If I have a docker-compose.yml today, what does migrating look like?
    You don't have to fully migrate. Point lpm at the repo, it detects the compose file, and you can run the whole graph via docker compose up as one lpm service. From there you can incrementally move native-friendly processes — your Rails server, your Next.js dev server, a Go binary — out of the compose file and into lpm as native services, while leaving stateful infra like Postgres and Redis in Compose. Keep whatever split makes sense. The source is on GitHub if you want to see how the config reads.

Keep reading

Best terminal for Mac

A native Apple Silicon workspace for services, logs, and agents.

lpm vs PM2

Where the dev loop ends and production process management begins.

Keep compose where it earns it. Go native everywhere else.

Fast startup, per-service panes, multi-project switching, and AI agents on your host — with your docker-compose.yml still welcome. Free and open source.

Download for macOS (Apple Silicon)Intel Mac? Get the x86-64 build
Developer ID signed · Notarized by AppleSafety, checksums & removal
View on GitHub