Docker has always used microVMs (well since 2016)

# Docker has always used microVMs Source: [https://dave.recoil.org/docker-has-always-used-microvms/](https://dave.recoil.org/docker-has-always-used-microvms/) ## Docker has always used microVMs \(well, since 2016\) There's a lot of buzz about "microVMs", where a workload runs with a stripped down Linux kernel, on a minimalist VMM such as[firecracker](https://github.com/firecracker-microvm/firecracker)\(announced at[re:Invent 2018](https://brooker.co.za/blog/2025/09/18/firecracker.html)\) on top of a hypervisor like KVM or Xen\. MicroVMs are often contrasted to, and considered more secure than, traditional Linux Docker containers\. What if I told you that Docker Desktop has always used microVMs?  ## Back in 2015 When I joined Docker in 2015 the state of the art was[Docker Toolbox](https://github.com/docker-archive/toolbox)\. It used[VirtualBox](https://www.virtualbox.org/), which is a great product with lots of features\. VirtualBox has its own GUI and its own update process; way more than we needed for Docker\. ## A library VMM We wanted Docker to feel like a native app on Mac and Windows, rather than a bundle of components\. Using our[Mirage Unikernel libraries](https://mirage.io/)we started building a "library VMM": a VMM which could be embedded inside the Docker application, and which would be single purpose, minimal, secure and fast\. The first version was called[hyperkit](https://github.com/moby/hyperkit)and the most recent one is[Docker VMM](https://www.docker.com/blog/docker-vmm-public-beta/)\.[1](https://dave.recoil.org/docker-has-always-used-microvms/#fn1) The VM kernel and root filesystem were minimal too, based on the[LinuxKit](https://github.com/linuxkit/linuxkit)project\. The current version is an even more slimmed down and efficient variant but conceptually the same, similar to[containerd/nerdbox](https://github.com/containerd/nerdbox)\. ## Docker for Mac in 2016 For Docker for Mac \(later renamed Docker Desktop\) this allowed: - **Running rootless on all platforms\.**Without requiring "rootless inside Linux": the whole Linux kernel is untrusted, so even a[Linux CVE](https://lwn.net/Articles/1097401/)doesn't matter\. - **Minimal devices\.**We could carefully limit the host / VM interface, making it easy to understand and audit\. - **VPNs and network policy\.**It was easy to interoperate with VPNs, and to extend later to impose networking policy such as[Registry Access Management](https://www.docker.com/blog/introducing-registry-access-management-for-docker-business/)\. [](https://cacm.acm.org/research/a-decade-of-docker-containers/) ## And now in 2026 The Docker microVM tech is the foundation of both Docker Desktop and also*Docker Sandboxes*\([why microVMs](https://www.docker.com/blog/why-microvms-the-architecture-behind-docker-sandboxes/)\)\. Docker Sandboxes enables you to do things like[run your favourite coding agent and harness securely](https://www.docker.com/blog/docker-sandboxes-run-claude-code-and-other-coding-agents-unsupervised-but-safely/), with strict isolation and governance\. To see what Docker microVM's can do, install[Docker Sandboxes \(sbx\)](https://docs.docker.com/ai/sandboxes/install/)and try \`sbx run claude\`\. ## Further reading To read more about the history of the tech, check out the article[A Decade of Docker Containers](https://cacm.acm.org/research/a-decade-of-docker-containers/)\(Communications of the ACM\)\. ## Footnote 1Although we were aiming to make everything a library and link into a static unikernel\-like process, for technical reasons it makes sense to still have a single host process per VM\.[↩](https://dave.recoil.org/docker-has-always-used-microvms/#fnref1)