Rig vs Docker Desktop
Docker isolates runtimes in containers. Rig orchestrates processes already on your computer.
Who this is for
Teams choosing container-first vs native
The short answer
Use Docker when you need reproducible containers. Use Rig when the work is native macOS processes, Valet sites, and AI agents that must see live local services. Many people use both — Docker for DB images, Rig for the app processes.
Side by side
| Feature | Rig | Docker Desktop | Note |
|---|---|---|---|
| Primary job | Control plane for local projects | Container runtime + Compose GUI | |
| Native process discovery | Yes | No | |
| Compose / multi-container apps | Partial | Yes | Rig can run compose scripts; Docker owns the runtime |
| Unified logs for npm + artisan + workers | Yes | Partial | |
| MCP scoped to live tools | Yes | No | |
| Share running HTTP without rebuilding image | Yes | Partial | Docker port publish ≠ Live Link demos |
| Image build / registry workflow | No | Yes |
Choose Rig if
- Your stack is mostly native Mac + Valet / Homebrew
- You want editor agents on live logs without full container ops
Stay with Docker if
- Parity with Linux prod containers is non-negotiable
- Your whole stack is Compose and Docker is the source of truth
Running both
Docker keeps
- DB and service images
- Compose definitions
- Prod-like networks
Rig takes
- App processes on your computer
- Merged logs, ports and Attention
- MCP + opt-in share
Start containers how you already do — Rig is for the developer-facing processes around them.