For Windows and macOS users, Docker Desktop has been the main way to use Docker containers for many years. While it remains a viable and usable option for hobbyists and small development teams, recent pricing changes for larger user bases sent people looking for alternatives. I am not looking to replace Docker Desktop myself, but I was interested in trying the alternatives and seeing how they compared.
Video version of this post
You can find a video version of this post with more hands-on using each tool coverage on YouTube.
Terminology
Containers themselves are not a new concept in technology, but Docker back in the mid-2000s popularised the concept and marketed them the right way at the right time to bring the concept into the mainstream.
It’s worth separating Docker the company from Docker the project as it’s easy to confuse them and they are distinct entities. Due to this confusion, Docker the company renamed and open-sourced a lot of its container-related technologies, contributing to what is now known as the “Open Container Initiative”(OCI).
I am abstracting and summarising a lot here, but when the rest of this post refers to “OCI compliant” containers and terms like it, then think of it as analogous to what you might think of as a “Docker container”. All of these events and changes actually happened some time ago in technology time, but still, it’s a constant source of confusion. Tldr… All of the options featured in this post can run the same container definitions and this includes your pre-existing containers from Docker Desktop or created with a Dockerfile. Another note, often projects refer to containers running with Docker as “dockerd” and “Moby” interchangeably.
1. Podman
Probably the most popular alternative, Podman has many contributors from Red Hat and as it appears that Red Hat are planning commercial versions of Podman, it may be safe to say it’s a “Red Hat project”.
It’s available for Windows, macOS, and Linux and like many of the other tools featured here, follows similar syntax to Docker with two caveats:
- By default you use
podmaninstead of Docker, but you can create an alias and forget about that command change. - Docker Desktop by default assumes that you want to use container images from the Docker hub, whereas all other alternatives understandably don’t make that assumption. This means you need to specify the full path to many images you may use regularly, for example, “docker.io/library/busybox”.
One of the key differences between Podman and the other alternatives featured here, including Docker Desktop, is that it’s daemonless. This means that every running container runs as its own runtime process, not via one daemon. If the Docker daemon fails, all running containers fail, whereas with Podman, only the individual container fails. That said, i have personally never had the Docker daemon fail, but I am not running production workloads.
Like all other tools here, on first run, Podman needs to create a virtual machine on macOS and Windows to host the containers. Increasingly on macOS and Windows this isn’t always necessary, but for maximum cross-platform (and architecture) compatibility, it makes sense. Podman uses Fedora CoreOS (there’s that red Hat connection again) and QEMU to run the VM.
Podman desktop
The graphical companion to Podman is Podman Desktop, but in theory it should list images and containers created by other runtimes, inc. Like many of the other graphical tools, it also adds features for interacting with Kubernetes, but I will look at those in a future post. It offers may of the same features as Docker Desktop, including features I didn’t realise followed any standards, such as extensions, but is a little less polished and lacks some of the OS-specific features that Docker Desktop offers.
2. Colima
Only available for Linux and macOS, Colima uses Lima to enable Linux VMs on macOS. It supports Docker, Containerd, and Kubernetes runtimes, and in all cases you need to install that runtime alongside Colima. In the case of Docker on macOS, this is not completely the same as Docker Desktop.
As simple as Colima is to use, the fact you still need to install a runtime alongside it made me wonder “what is Colima?”, and to be honest, the minimal documentation doesn’t make it any clearer. The tagline is “Container runtimes on macOS (and Linux) with minimal setup”, but that still doesn’t clarify to me why I need it. As far as I can tell, the main reasons are for using containerd or as a Kubernetes backend (instead of Docker Dkestop, minikube etc.) and maybe the main reason for Docker support is backwards compatibility.
3. Rancher desktop
While it mostly bills itself as a Kubernetes management tool, Rancher Desktop also offers some container management features outside of Kubernetes. It supports containers running with containerd or Docker and offers most of the same features as the other graphical tools on this list. Again, QEMU provides the VM that everything runs on, with no option to change that. It’s a perfectly decent tool, and one of the more mature alternatives, but I tend find it needed to restart and reset the VM a lot when you made changes, which got a little tedious.
4. VMWare Fusion
If you already use VMWare Fusion for running Windows and Linux VMs, it also supports containers. However, the feature currently only works with Intel-based Macs, despite the installer still installing the CLI tool and giving you false hope.
5. Parallels
Again, if you already own and use Parallels Desktop for Linux and Windows VMs, then you can use it as a backend for minikube, which is mostly aimed at Kubernetes usage, but it’s container-adjacent, so I include it as kind of an option.
What I use
For now, as an individual contributor, I am happy with Docker Desktop, and I like the extra features it offers for more performant and seamless integration with the host operating system.
If something changed to disincentivise people like me too, then I would likely switch to Podman, perhaps with Podman Desktop, it will depend on the project’s state at that time.
What about you?
