{"article":{"slug":"docker-has-always-used-microvms","title":"Docker has always used microVMs","subtitle":null,"summary":"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.","content_type":"essay","language":"en","canonical_url":"https://dave.recoil.org/docker-has-always-used-microvms/","author":{"name":"Dave Scott","url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"Dave Scott","url":null,"listing_slug":null,"listing":null},"topics":[{"name":"infrastructure","slug":"infrastructure","url":"https://listedarticles.com/topics/infrastructure"},{"name":"open-source","slug":"open-source","url":"https://listedarticles.com/topics/open-source"},{"name":"engineering","slug":"engineering","url":"https://listedarticles.com/topics/engineering"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":373,"reading_minutes":2,"published_at":"2026-10-03T12:00:00.000Z","added_at":"2026-10-03T17:11:13.976Z","updated_at":"2026-10-03T17:11:13.976Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/docker-has-always-used-microvms","markdown_url":"https://listedarticles.com/articles/docker-has-always-used-microvms.md","example":false,"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)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://dave.recoil.org/docker-has-always-used-microvms/"},"body_markdown":"# Docker has always used microVMs (well, since 2016)\n\nThere'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? \n\n# Back in 2015\n\nWhen 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. \n\n# A library VMM\n\nWe 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\n\nThe 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). \n\n# Docker for Mac in 2016\n\nFor Docker for Mac (later renamed Docker Desktop) this allowed: \n\n  * **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. \n  * **Minimal devices.** We could carefully limit the host / VM interface, making it easy to understand and audit. \n  * **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/). \n\n# And now\n\nThe 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. \n\n# Further reading\n\nTo 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). \n\n# Footnote\n\n1 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. ↩","body_html":"<h1 id=\"docker-has-always-used-microvms-well-since-2016\">Docker has always used microVMs (well, since 2016)</h1>\n<p>There&#39;s a lot of buzz about &quot;microVMs&quot;, where a workload runs with a stripped down Linux kernel, on a minimalist VMM such as <a href=\"https://github.com/firecracker-microvm/firecracker\" rel=\"nofollow ugc noopener\">firecracker</a> (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? </p>\n<h1 id=\"back-in-2015\">Back in 2015</h1>\n<p>When I joined Docker in 2015 the state of the art was <a href=\"https://github.com/docker-archive/toolbox\" rel=\"nofollow ugc noopener\">Docker Toolbox</a>. It used <a href=\"https://www.virtualbox.org\" rel=\"nofollow ugc noopener\">VirtualBox</a>, 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. </p>\n<h1 id=\"a-library-vmm\">A library VMM</h1>\n<p>We wanted Docker to feel like a native app on Mac and Windows, rather than a bundle of components. Using our <a href=\"https://mirage.io/\" rel=\"nofollow ugc noopener\">Mirage Unikernel libraries</a> we started building a &quot;library VMM&quot;: 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 <a href=\"https://github.com/moby/hyperkit\" rel=\"nofollow ugc noopener\">hyperkit</a> and the most recent one is <a href=\"https://www.docker.com/blog/docker-vmm-public-beta/\" rel=\"nofollow ugc noopener\">Docker VMM</a>.1</p>\n<p>The VM kernel and root filesystem were minimal too, based on the <a href=\"https://github.com/linuxkit/linuxkit\" rel=\"nofollow ugc noopener\">LinuxKit</a> project. The current version is an even more slimmed down variant but conceptually the same, similar to <a href=\"https://github.com/containerd/nerdbox\" rel=\"nofollow ugc noopener\">containerd/nerdbox</a>. </p>\n<h1 id=\"docker-for-mac-in-2016\">Docker for Mac in 2016</h1>\n<p>For Docker for Mac (later renamed Docker Desktop) this allowed: </p>\n<ul><li><strong>Running rootless on all platforms.</strong> Without requiring &quot;rootless inside Linux&quot;: the whole Linux kernel is untrusted, so even a <a href=\"https://lwn.net/Articles/1097401/\" rel=\"nofollow ugc noopener\">Linux CVE</a> doesn&#39;t matter. </li><li><strong>Minimal devices.</strong> We could carefully limit the host / VM interface, making it easy to understand and audit. </li><li><strong>VPNs and network policy.</strong> It was easy to interoperate with VPNs, and to impose networking policy such as <a href=\"https://www.docker.com/blog/introducing-registry-access-management-for-docker-business/\" rel=\"nofollow ugc noopener\">Registry Access Management</a>. </li></ul>\n<h1 id=\"and-now\">And now</h1>\n<p>The Docker microVM tech is the foundation of Docker Sandboxes today (<a href=\"https://www.docker.com/blog/why-microvms-the-architecture-behind-docker-sandboxes/\" rel=\"nofollow ugc noopener\">why microVMs</a>). It continues to get faster, lower overhead and more secure over time. </p>\n<h1 id=\"further-reading\">Further reading</h1>\n<p>To read more about the history of the tech, see <a href=\"https://cacm.acm.org/research/a-decade-of-docker-containers/\" rel=\"nofollow ugc noopener\">A Decade of Docker Containers</a> (Communications of the ACM). </p>\n<h1 id=\"footnote\">Footnote</h1>\n<p>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. ↩</p>","headings":[{"level":1,"text":"Docker has always used microVMs (well, since 2016)","id":"docker-has-always-used-microvms-well-since-2016"},{"level":1,"text":"Back in 2015","id":"back-in-2015"},{"level":1,"text":"A library VMM","id":"a-library-vmm"},{"level":1,"text":"Docker for Mac in 2016","id":"docker-for-mac-in-2016"},{"level":1,"text":"And now","id":"and-now"},{"level":1,"text":"Further reading","id":"further-reading"},{"level":1,"text":"Footnote","id":"footnote"}]}}