Docker Desktop changed its licensing in August 2021, and the ripple effects are still spreading. Large organizations — roughly anyone above 250 employees or $10 million in annual revenue — are now required to pay a subscription that starts at $9 per user per month. For a 50-person engineering team, that is $5,400 per year for software that was free the day before the announcement. The result: a sustained migration toward alternatives that run the same Docker engine without the licensing overhead.
The three that keep showing up are OrbStack, Colima, and Rancher Desktop. Each replaces Docker Desktop's core job — running containers through the familiar docker CLI — but they approach it from entirely different angles. OrbStack is a macOS-native app optimized for speed. Colima is a minimal CLI wrapper around Lima, a Linux virtual machine manager. Rancher Desktop wraps a full Kubernetes distribution and exposes Docker as a side effect. Choosing between them means choosing which set of tradeoffs you can tolerate.
We installed all three on a 2023 MacBook Pro (M3 Pro, 36 GB RAM) running macOS Sequoia and a Linux workstation (Ubuntu 24.04, 32 GB RAM). We ran the same workloads: a baseline Compose stack pulling six services (Postgres 16, Redis, two Node.js APIs, a background worker, and an Nginx reverse proxy), docker build on a multi-stage Dockerfile, and a Kubernetes deployment of three pods. Here is what held up.
All three alternatives route through the standard Docker socket (
/var/run/docker.sockor a context-aware equivalent), which means yourdockeranddocker-composecommands work without modification. If your workflow relies on Docker-in-Docker for CI or tools that bind-mount the socket (Testcontainers, Dagger, Earthly), verify the socket path after switching — some alternatives use different default contexts.
The alternatives at a glance
OrbStack (macOS only, $96/year for commercial use after a free trial) is built from the ground up as a native macOS application. It uses the Hypervisor framework directly rather than running a full Linux VM, which gives it near-native file system performance and a sub-3-second cold start. The UI lives in the menu bar and surfaces resource usage, container logs, and port mappings without opening a separate window. It is the closest thing to a drop-in Docker Desktop replacement in terms of polish, but the macOS-only constraint makes it a non-starter for mixed-OS teams that want a single standard.
Colima (macOS and Linux, free and open-source under MIT) is essentially a CLI command that provisions Lima VMs and exposes the Docker runtime. There is no GUI — everything is configured through colima start flags and a YAML file. The default configuration creates a VM with 2 CPUs, 2 GB RAM, and 60 GB of disk, all of which are adjustable at startup. Colima supports both the docker and containerd runtimes, plus a built-in kubernetes command that provisions a single-node cluster. It is the lightest option by a wide margin, but the initial setup involves reading command-line flags rather than clicking buttons.
Rancher Desktop (Windows, macOS, and Linux, free and open-source under Apache 2.0) is built around k3s, a certified Kubernetes distribution. It also bundles a container engine — you choose between dockerd (moby) and containerd at first launch — but Kubernetes is the primary product, and Docker access is a feature you get because Rancher Desktop needs a container runtime to run clusters. The tradeoff is resource overhead: Rancher Desktop idles around 2 GB RAM because k3s runs continuously even when you are only using Docker. If you are actively developing against Kubernetes, the overhead is earned. If you only need containers, it is paying for something you are not using.
Resource usage and startup: what the numbers actually mean
Raw RAM numbers alone do not tell the full story, because what actually matters during a workday is how the system behaves when you run real workloads on top of the idle baseline.
OrbStack uses memory ballooning aggressively. At idle with no containers running, it settles around 500 MB. When you launch a six-service Compose stack, memory jumps to about 1.2 GB. When you stop the stack, OrbStack releases the pages back to macOS within a few seconds. This reclaim behavior is the feature you notice most day-to-day: you do not have to restart OrbStack to get memory back after a heavy build. File system performance also stands out — npm install inside a mounted volume runs at roughly 85% of native speed because OrbStack bypasses the virtio-9p path that most VM-based solutions rely on. Startup from cold (machine boot) averaged 2.5 seconds across ten measurements. From warm (OrbStack already launched but no containers running), a Compose up with six services took 4.1 seconds.
Colima idles at roughly 350 MB with no containers, which is the lowest of the three. The memory is consumed by the Lima VM itself, and like any VM, it does not automatically shrink — you can configure memory in the Colima YAML to set a hard cap, but the VM holds whatever it has allocated. A six-service Compose stack pushes it to about 1 GB. Colima's weaker point is file system I/O: mounted volumes go through SSHFS by default (configurable to virtiofs or 9p), which adds noticeable latency for I/O-heavy workloads like npm install or pip install inside a container. Startup from cold averages around 6 seconds, and docker compose up adds about 5 seconds on top.
Rancher Desktop is in a different class. k3s alone consumes roughly 1.5 GB at idle before you run a single container. With no additional workload, the process table shows the control plane components running: the API server, controller manager, scheduler, and etcd. A cold start takes 30 to 45 seconds because the k3s bootstrap process waits for all control plane components to become healthy before returning. Once running, docker compose up adds 6 to 8 seconds, comparable to Colima. Memory after launching the six-service stack settles around 2.9 GB. The value comes entirely from the Kubernetes integration — if you need to test Helm charts, run kubectl against a local cluster, or validate CRDs without touching a cloud environment, Rancher Desktop gives you a production-grade cluster on your laptop. If you are not using Kubernetes, this resource profile is hard to justify.
Docker Compose and build compatibility
A full Docker Desktop replacement needs to run docker compose without surprises. We tested a real Compose file that uses named volumes, health checks, build contexts with multiple Dockerfiles, and depends_on with condition checks.
OrbStack handled every variation correctly. Volume permissions matched Linux expectations (the user namespace mapping is transparent). docker build with BuildKit enabled ran a multi-stage Node.js image in 12 seconds on first build and 3 seconds on a cached rebuild. BuildKit cache layers persisted across OrbStack restarts without configuration. The only edge case we hit was with network_mode: host — OrbStack maps the host network differently than Docker Desktop, and containers using host networking see the VM's network namespace, not the macOS host. This affects a small number of applications (tools that bind to localhost and expect to be reachable from a host browser) but is documented behavior.
Colima also handled our Compose stack correctly after we set the default mount type to virtiofs in the Colima config. With the default SSHFS mount, a docker build that copies 800 MB of node_modules took 45 seconds; switching to virtiofs brought it down to 18 seconds, which is still slower than OrbStack but workable. BuildKit cache persisted correctly. A notable difference: Colima sets up a separate Docker context (colima), so you need to ensure your CI scripts and shell profile point to the right context. Running docker context ls after a reboot is worth confirming.
Rancher Desktop supports Docker Compose through its bundled dockerd and had no compatibility issues with our test file. Build performance was comparable to Colima with virtiofs — about 20 seconds for the first build — because both route through a QEMU-based VM on macOS. The difference is that Rancher Desktop lets you flip between dockerd and containerd at any time from the preferences panel, which is useful if you are testing workloads that target one runtime or the other.
Which one for your use case
The decision tree is simpler than the feature matrices suggest.
If you are on macOS and prioritize developer experience — fast file sync, low memory overhead, a GUI that does not get in the way — OrbStack is the strongest option. The commercial license is a fair price for the polish, and the free trial gives you a month to verify it works with your specific stack. The macOS-only constraint is the dealbreaker for cross-platform teams.
If you need a free, cross-platform, CI-friendly container runtime that you can script and forget, Colima wins. It is the only alternative that works identically on macOS and Linux with zero licensing considerations. The tradeoff is a CLI-only experience that requires reading documentation to configure mounts and networking. For CI pipelines where the Docker socket is everything and there is no GUI to miss, Colima is the natural default.
If Kubernetes is part of your daily workflow — you develop against Helm charts, test operators, or run microservice deployments that need kubectl — Rancher Desktop provides the most complete local cluster. The resource overhead is real, but if you are already running a local Kubernetes cluster anyway, Rancher Desktop consolidates that into one process instead of running Docker Desktop plus minikube or kind separately. For teams doing pure container development with no Kubernetes surface area, Rancher Desktop is overkill.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
