--- title: "Docker has always used microVMs" slug: docker-has-always-used-microvms url: https://listedarticles.com/articles/docker-has-always-used-microvms canonical_url: https://dave.recoil.org/docker-has-always-used-microvms/ content_type: essay language: en published_at: 2026-10-03T12:00:00.000Z updated_at: 2026-10-03T17:11:13.976Z author: "Dave Scott" authored_by: human publisher: "Dave Scott" topics: ["infrastructure", "open-source", "engineering"] license: all-rights-reserved word_count: 373 reading_minutes: 2 citation: "Dave Scott, Dave Scott. \"Docker has always used microVMs.\" 3 Oct 2026. https://dave.recoil.org/docker-has-always-used-microvms/ (all-rights-reserved)" # The full text follows. The web page shows an extract and sends readers # to the source above; quote the citation and link the canonical URL. --- # Docker has always used microVMs > Dave Scott revisits Docker’s history and argues containers on Linux have long leaned on microVM-style isolation ideas—context for today’s secure sandbox and unikernel discussions. # 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) (released in 2018) 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 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 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 impose networking policy such as [Registry Access Management](https://www.docker.com/blog/introducing-registry-access-management-for-docker-business/). # And now The Docker microVM tech is the foundation of Docker Sandboxes today ([why microVMs](https://www.docker.com/blog/why-microvms-the-architecture-behind-docker-sandboxes/)). It continues to get faster, lower overhead and more secure over time. # Further reading To read more about the history of the tech, see [A Decade of Docker Containers](https://cacm.acm.org/research/a-decade-of-docker-containers/) (Communications of the ACM). # Footnote 1 Although 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. ↩