Colima: a Lima-backed container runtime for macOS without Docker Desktop
Container runtimes on macOS (and Linux) with minimal setup
At a glance
- What is it?
- Colima wraps Lima virtual machines into a single CLI that starts Docker, containerd, Incus or Kubernetes on macOS. It is a good fit if you want a disposable Linux VM per runtime and dislike a GUI-managed daemon; it is a poor fit if you need Kubernetes conformance testing or Windows containers.
- Who is it for?
- Adopt Colima if you want Docker or containerd on macOS with a command-line lifecycle, multiple named instances and no GUI daemon, and if you are comfortable editing a config file and rebuilding a VM when its parameters change. Do not adopt it if you need Windows containers, a vendor support contract, or GPU passthrough on Intel Macs, since the README ties GPU-accelerated AI workloads to Apple Silicon and macOS 13+ with the krunkit VM type.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The macOS gap Colima fills, and for whom
On macOS there is no native Linux kernel, so any Linux container needs a virtual machine underneath. Colima's answer is to own that VM for you. The README states the project goal plainly: to provide container runtimes on macOS with minimal setup. The name is a contraction of Containers on Lima, and Lima is the upstream project that manages the Linux virtual machine.
The audience is narrower than the slogan suggests. Colima is for developers who want a Docker or containerd endpoint on a Mac and are willing to manage it from a terminal. The README lists Homebrew, MacPorts, Nix and Mise as install paths, which tells you the expected user already has a package manager and a shell profile. If you want a tray icon, a settings panel and a support contract, this is not the tool. If you want a command you can put in a Makefile or a CI script for a Mac runner, it is.
The Linux support is real but secondary. The README describes the project as container runtimes on macOS and Linux, and the repository carries a linux-integration workflow alongside the macOS one. The problem being solved, though, is the Mac one: on Linux you already have a kernel, and Colima's value is mostly consistency of interface rather than capability.
Lima underneath, runtimes on top
Colima is a Go program that drives Lima. When you run colima start, it creates a Lima instance, boots a Linux guest, and then provisions the runtime you asked for inside that guest. The host-side clients (docker, nerdctl, kubectl, incus) talk to sockets that Colima forwards out of the VM. The README says port forwarding is automatic, and that after colima start the docker client works on macOS with no additional setup.
The runtime is chosen at first start and defaults to Docker. The alternatives are containerd, Incus and, orthogonally, Kubernetes. These are not interchangeable skins over one engine. Docker and containerd are container runtimes with different client tooling; the README points containerd users at colima nerdctl and recommends colima nerdctl install to place a nerdctl alias script on the PATH. Incus is a different category: the README describes it as containers and virtual machines, and notes that running VMs under Incus is only supported on m3 or newer Apple Silicon.
Kubernetes is a flag layered on top rather than a fourth runtime. colima start --kubernetes brings up a cluster, and the README explains the image-sharing rule: with the Docker runtime, images built or pulled with Docker are visible to Kubernetes, while with containerd only images in the k8s.io namespace are visible. That detail matters more than it looks. It determines whether a locally built image needs a registry round trip before a pod can pull it.
The VM itself is a Lima artifact with defaults of 2 CPUs, 2GiB memory and 100GiB storage. Customization happens either through flags on colima start or through a config file opened with colima start --edit. Multiple instances are a listed feature, so the unit of configuration is a named VM, not a global daemon.
Getting a runtime up from a clean shell
The README gives the install commands directly. On Homebrew it is brew install colima; MacPorts uses sudo port install colima; Nix uses nix-env -iA nixpkgs.colima; Mise uses mise use -g colima@latest. There is also a bleeding-edge path, brew install --HEAD colima, which the README restricts to Homebrew.
The shortest path to a working Docker endpoint is two commands: colima start, then docker run hello-world. The docker client is a separate install, brew install docker, and the README is explicit that it is required for the Docker runtime. That is a common first stumble: Colima provides the engine, not the CLI.
For containerd the sequence is colima start --runtime containerd, then nerdctl run hello-world. Kubernetes needs kubectl installed separately via brew install kubectl, then colima start --kubernetes followed by kubectl run caddy --image=caddy and kubectl get pods. Incus needs the incus client, brew install incus, then colima start --runtime incus and incus launch images:alpine/edge.
Sizing is done with colima start --cpu 1 --memory 2 --disk 10 for a small VM, or by stopping first and restarting with new values: colima stop, then colima start --cpu 4 --memory 8. The README notes that disk size can be increased after the VM is created, and says nothing about reducing it. Rosetta 2 emulation is available with colima start --vm-type=vz --vz-rosetta, which the README gates on v0.5.3 or later and macOS 13 Ventura or later on Apple Silicon.
The AI path is the newest surface. It requires v0.10.0, Apple Silicon and macOS 13 or later, and uses the krunkit VM type: colima start --runtime docker --vm-type krunkit, then colima model run gemma3. Two runner backends are documented, Docker Model Runner as the default and Ramalama as an alternative, selected with --runner ramalama. Model names can be bare (gemma3, llama3.2), HuggingFace-qualified (hf.co/microsoft/Phi-3-mini-4k-instruct-gguf) or Ollama-qualified (ollama://gemma3).
Where Colima stops being the right answer
The clearest boundary is the one the README draws itself: GPU-accelerated AI workloads need Apple Silicon, macOS 13 or later, and krunkit installed separately from the containers project. On an Intel Mac that whole feature set is unavailable, and the documentation does not offer a fallback. The same applies to Incus virtual machines, which the README limits to m3 or newer Apple Silicon. If your team is mixed hardware, you are supporting two capability tiers with one tool name.
The Kubernetes story is a development cluster, not a test cluster. The README shows kubectl run and kubectl get pods; it makes no claim about conformance, multi-node scheduling, or control-plane behaviour under load. The image visibility rule is the concrete symptom: with containerd, an image you just built is invisible to Kubernetes unless it landed in the k8s.io namespace. Anyone who expects kubectl to see whatever nerdctl just produced will spend time debugging a namespace boundary rather than a bug.
Resource changes are not fully online. The README's own example for moving an existing VM to 4 CPUs and 8GiB is stop then start, and disk growth is described as a post-creation operation with no stated shrink path. A VM whose disk you sized too large is a VM you rebuild. That is a real cost in a project whose selling point is minimal setup.
Finally, the runtime choice is sticky in a way that is easy to miss. Because the runtime is selected on initial startup, switching from Docker to containerd is not a flag on a running instance; it is a new instance or a rebuild. Teams that want to compare runtime behaviour on the same machine should plan for multiple instances from the start.
Colima against Docker Desktop, and against Lima alone
The obvious comparison is Docker Desktop. Both give you a docker CLI on macOS. Docker Desktop is a GUI application with a vendor behind it, a licence that restricts commercial use at larger organisations, and a settings panel. Colima is an MIT-licensed CLI that provisions a Lima VM and forwards the socket. The practical difference is where configuration lives. In Docker Desktop you click; in Colima you pass flags or edit the file opened by colima start --edit, and the README points at a config file as a first-class workflow rather than an escape hatch. If your team already automates Mac setup with a package manager and a dotfiles repo, Colima fits that shape. If your team needs a support phone number, it does not.
The second comparison is Lima itself, which Colima is built on. Lima gives you a Linux VM on macOS with its own configuration format. Colima adds the runtime provisioning layer on top: choosing Docker, containerd or Incus, wiring the host client to the guest socket, and adding the Kubernetes and model-runner flags. If you only need a Linux shell and no container runtime, Colima is a layer you do not need. If you want containers without writing Lima templates, that layer is the entire product.
A third comparison worth naming is a remote Linux host or a cloud dev VM. That approach removes the macOS VM boundary entirely and gives you a real Linux kernel with no Rosetta question. It costs you offline work and adds network latency to every file watch. Colima keeps everything local, which is why the automatic port forwarding and volume mounts in the feature list exist at all.
Upgrade and licence costs you actually pay
Colima is MIT licensed, which permits commercial use and modification. That is the whole of the licence story the README tells; it does not discuss trademarks, contributor agreements or any relicensing commitment. Nothing here is legal advice, and a project can change its licence in a later release, so if licence terms are a procurement question, read the LICENSE file in the tag you pin rather than the README summary.
The maintenance cost is not in the binary, it is in the VM. Colima depends on Lima, and on the guest runtime it provisions. A Lima upgrade or a runtime upgrade can change what is inside the VM, and the README's own answer to configuration drift is colima start --edit plus a stop and start cycle. Upgrades that touch the VM type or the runtime may mean recreating the instance, which means re-pulling images and re-creating volumes. The release cadence visible in the repository is uneven: v0.10.3 and v0.10.2 are dated one day apart in June 2026, while v0.10.1 is from February 2026. That pattern suggests patch releases cluster around a fix, not a steady drip, so pinning a version and reading the release notes before moving is the cheaper habit.
Feature gating is part of the cost too. The README tags Incus as requiring v0.7.0 and the AI model support as requiring v0.10.0, which means any documentation or internal runbook you write has a minimum version attached to it. If you standardise on an older Colima across a team, those sections simply do not apply, and there is no compatibility shim described.
What to check before you standardise on it
Verify the runtime you plan to use is reachable from the host client on your own machine before you write it into a setup script. The README's examples are one command each (docker run hello-world, nerdctl run hello-world, incus launch images:alpine/edge), and reproducing them is the cheapest possible smoke test. If your workflow builds images locally and runs them in Kubernetes, test the namespace rule first: build an image under the Docker runtime and confirm a pod can use it, then repeat under containerd, where the README says only k8s.io namespace images are visible.
Decide your VM sizing before the first start, not after. The README documents increasing disk but not shrinking it, and its own resize example is a stop and start. Getting --cpu, --memory and --disk right on the first colima start costs a minute; getting them wrong costs a rebuild.
Check your hardware tier against the feature list. GPU-accelerated models need Apple Silicon, macOS 13+ and krunkit installed separately. Incus VMs need m3 or newer Apple Silicon. Rosetta 2 needs v0.5.3, macOS 13+ and --vm-type=vz. If any of those conditions fail on a machine you support, that feature is off the table for that machine, and the README offers no alternative path.
Editorial conclusion
Adopt Colima if you want Docker or containerd on macOS with a command-line lifecycle, multiple named instances and no GUI daemon, and if you are comfortable editing a config file and rebuilding a VM when its parameters change. Do not adopt it if you need Windows containers, a vendor support contract, or GPU passthrough on Intel Macs, since the README ties GPU-accelerated AI workloads to Apple Silicon and macOS 13+ with the krunkit VM type. Before committing, verify three things on your own machine: that your chosen runtime is reachable from the host client after colima start, that your Kubernetes workload tolerates a single-node cluster, and that the disk size you set with --disk is the one you want, because the README says disk can be increased after creation but says nothing about shrinking it.
Community notes