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 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? (since 2016)

Always has been meme: wait, Docker uses microVMs? Always has been (since 2016)

Unikernels are microVMs

Unikernels can be considered an early form of microVM. Rather than booting a full Linux kernel on a full VMM, a unikernel links an app with only the drivers, filesystems and subsystems it actually needs; other code is omitted. For example a MirageOS unikernel app would have no processes, probably no filesystem, only one vCPU. Certainly no ssh or shell (unless you really want those). The VMM that hosts the Mirage unikernel was also minimal (see Solo5 and mirage-solo5 ). No legacy required. We were so confident in the security of the system that we ran a bitcoin pinata offering 10BTC to any hacker able to claim it. The BTC went unclaimed.

Boot can be really fast too: the "Just-In-Time Summoning of Unikernels" project (paper, code) optimized x86 VM creation time down to about 20ms (120ms on an underpowered 2015 ARM dev board)

The main (obvious) downside of unikernels is having to link your app with a bunch of kernel code. A lot of people would like to run existing Linux programs!

While we were developing Unikernels, Docker was busy inventing the modern form of Linux containers and revolutionising how software is built, shared and run. Docker acquired Unikernel Systems in 2016 and we combined the best of Unikernels (microVMs) and Linux containers into Docker for Mac (later Docker Desktop).

A library VMM for Desktop applications

Our priority back then wasn't to add microVMs to Docker for their own sake. Instead our goal was to make Docker feel like a native app on Mac and Windows, rather than a bundle of components. Using our Mirage Unikernel libraries 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 (a fork of xhyve, itself derived from bhyve ). We linked the C code directly with the MirageOS block layer and used the Mirage userspace TCP/IP stack in a gvisor-like network stack vpnkit. The VMM code continues to evolve and is now called Docker VMM.1

The VM kernel and root filesystem were minimal too, based on the LinuxKit project. The current version is an even more slimmed down and efficient variant but conceptually the same, similar to containerd/nerdbox.

Docker for Mac in 2015-2016

Docker for Mac began in 2015 as Project Piñata, a skunkworks project to make Docker useful to more developers. In this 2018 tweet, Solomon Hykes recalls Docker's first use of unikernel technology and the collaboration between Paris, Cambridge and San Francisco:

For Docker for Mac (later renamed Docker Desktop) this allowed:

Here's the OG 2015 Docker for Mac beta installation experience:

And now in 2026

The Docker microVM tech is the foundation of both Docker Desktop and also Docker Sandboxes (why microVMs), where each sandbox runs in a separate microVM, completely isolated from each other and the host. Docker Sandboxes enables you to do things like run your favourite coding agent and harness securely, with strict isolation and governance.

CACM 2026 - A Decade of Docker Containers

To see what Docker microVM's can do, install Docker Sandboxes (sbx) 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 (Communications of the ACM).

Join the discussion on LinkedIn.

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. ↩

ChangeLog