Docker Desktop vs Rig for local stacks

Docker Desktop shines when the app is defined as images and Compose files. Rig shines when the app is npm scripts, artisan sidecars, PHP built-in or Herd/Valet, a queue on the host, and a Vite process that refuses to stay on the port you remember.

Those are different shapes. Pretending one tool wins every local stack is how teams end up with a slow container for a three-line Node script — or a process board trying to be a container runtime.

Many studios use both: Docker for Postgres/Redis, Rig for the app processes. That is not a hedge. That is the intended split.

What Docker Desktop is for

Use Docker Desktop when:

• The service is defined as an image you want bit-for-bit parity with staging.
• Compose is the source of truth for networking between multiple containers.
• You need isolation that a host process cannot give you (weird system deps, conflicting native libraries).
• The team already thinks in containers and the pain of Docker is lower than the pain of “works on my machine” for that service.

Docker is excellent at shipping a database, a search container, or a full microservices mesh locally. It is heavier when all you needed was npm run dev and a queue worker.

What Rig is for

Use Rig when:

• The morning ritual is scripts and Procfiles on the Mac, not docker compose up for every line of application code.
• You need start order, merged logs, port reclaim, and an Attention board across host processes.
• AI editors should restart a crashed sidecar through scoped MCP tools — not by guessing pids in a shell.
• You share a five-minute client preview with Live Link without promoting a container stack to “staging.”

Rig can start a Compose script and work beside managed database containers. It does not replace the Docker engine. Docs say that in public: Rig is not a replacement for Docker Desktop when you need containers.

The honest middle: both

A common agency shape:

1. Docker Desktop runs Postgres and Redis (or MySQL for WordPress).
2. Herd or Valet serves PHP where that is the runtime.
3. Rig starts Vite, Horizon/queue, the Node API, and watches health and ports.
4. MCP reads the same board Cursor would otherwise invent.

Health-aware start order matters here: if Postgres is not ready, the API should wait. When a health check blocks the chain, check the Attention board and database containers first — before rewriting application code.

Comparisons that go wrong

“Just put everything in Compose.” Sometimes yes. Often you inherit a Laravel app that expects Herd, or a WordPress site that expects local PHP, or a Vite config that binds to the host. Containerizing the world for purity slows the morning without buying production parity you actually use.

“Rig replaces Docker.” No. If the unit of work is an image, stay in Docker. Rig will not pretend to be a container host.

“Docker replaces a process board.” docker compose logs -f is not the same as a named process table with reclaim, MCP, and Live Link. Different job.

See the public matrix: Rig vs Docker Desktop.

Workflows that map cleanly

Studio Mac, mixed stack. Docker for data stores; Rig for app processes; optional cloud for catalog across laptop and desk Mac. Source stays on disk.

Container-native service. Develop inside Compose; use Rig only if you also run host-side tools (docs site, proxy, agent hub) that are not in the Compose file.

WordPress one-click. Rig’s WordPress flow expects Docker for isolated MySQL in the documented path — that is coexistence, not competition.

AI-assisted debugging. Prefer MCP status/logs/restart on the Rig-managed processes. For container-only failures, use Docker’s tooling; do not ask an agent to docker kill through a vague shell if you can avoid it.

Edge cases

Port collisions between Compose and host Vite. Reclaim from the board; align Compose port mappings with the ports Rig expects. Two listeners on 5432 is not a framework bug.

Docker Desktop not started after reboot. Rig cannot invent the engine. Start Docker, then start the group. The morning-after-OS-update ritual applies.

Compose project vs Rig project. Keep naming clear so agents restart the right unit. A Procfile on the host and a Compose service with the same nickname will confuse humans first, models second.

Heavy images on a travel laptop. If battery and disk hate Desktop, keep only the databases in Docker and run app processes on the host via Rig — or use managed local services Rig provides where that fits your stack.

Decision rule

Ask one question: is the unit of work an image or a process?

• Image → Docker Desktop (and Compose) owns it.
• Process → Rig owns supervision, logs, ports, MCP.
• Both → split by unit, not by ideology.

If you only ever run one containerized service and never touch host scripts, you may not need Rig yet. If you only ever run npm run dev and a SQLite file, you may not need Docker yet. Both statements can be true for different projects on the same Mac — which is why the catalog exists.

Related

• Compare: Docker Desktop
• What Rig does not replace
• Procfile plus sidecars
• Herd is the runtime. Rig is the board.

Pick the tool that matches the shape of the stack. Mixing them on purpose beats forcing one religion onto every repo.

https://userig.app/blog/docker-desktop-vs-rig-local-stacks