lpm vs Docker Compose

Native dev, without container overhead.

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
Signed & notarized by Apple
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.

lpm

  • Starts a multi-service dev stack in one command
  • Runs services natively on the host
  • Containerized service isolation
  • native speedCold start after a code change
  • native FSmacOS file I/O speed for mounted source
  • Per-service live output pane in a native app
  • Visual project switcher across multiple repos
  • use host versionsProd-parity service versions (Postgres 15.3, Redis 7.2, etc.)
  • Reproducible across team machines and OSes
  • Auto-detects docker-compose.yml and can run it
  • Designed for parallel AI coding agents on host
  • Native macOS desktop app + CLI with shared config
  • Open source, free

Docker Compose

  • Starts a multi-service dev stack in one command
  • Runs services natively on the host
  • Containerized service isolation
  • container rebuildCold start after a code change
  • volume sync overheadmacOS file I/O speed for mounted source
  • docker compose logsPer-service live output pane in a native app
  • Visual project switcher across multiple repos
  • Prod-parity service versions (Postgres 15.3, Redis 7.2, etc.)
  • Reproducible across team machines and OSes
  • Auto-detects docker-compose.yml and can run it
  • Designed for parallel AI coding agents on host
  • CLI onlyNative macOS desktop app + CLI with shared config
  • Open source, free
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 plus a CLI that share the same config.
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.
FAQ

Switching from — or alongside — Docker Compose

  • Can I use lpm and Docker Compose together?
    Yes, and this is the common case. lpm auto-detects docker-compose.yml in a project and 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 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
Signed & notarized by Apple
View on GitHub