Article title is a bit click-baity. The article is only talking about Docker Desktop on Mac or Windows. Docker Linux have not been using microVMs for a decade.
> Docker Linux have not been using microVMs for a decade.
You sure could. Kata containers have been around for a long time; I remember putting them into production back in 2017 or so (and dealing with filesystem forwarding issues).
https://lwn.net/Articles/755230/
I was just exploring the new docker sandbox and saw that they could retain all your data in/out of the sandbox for 30 days. I wash my hand of docker, use with care. Data is gold and lots of companies are now going to be giving their "free" products as a sort of trojan horse to steal your data.
I do think this was well ahead of its time. Under the hood, we designed a Linux distro called LinuxKit (https://github.com/linuxkit/linuxkit) which ran every process in its own mount namespace (including the init process), and had a deterministic build with hashes. As far as I can tell, it's still pretty hard to get this experience even with Nix in 2026.
The boot time was also quick enough to be entirely in parallel and so not be noticeable (the 'bounce time' of the application on Mac was one bounce!)
Dynamic memory hot-plugging is still not as efficient. So if you don't want strict isolation between containers or individual sandboxes around each one of them, avoid VMs to achieve the highest density per box.
Docker *Desktop*, not Docker Engine. Most uses of Docker, at least until Kubernetes shifted to containerd, were the latter. The reality is that most running production containers today share a kernel.
I wonder if this is due to Microsoft pushing forward with wslc in the past week or so.
I tried pure wslc for a project or two this past week. It got me 90% of the way but not all the way. Still pretty impressive, even if it is another example of extend and extinguish.
So what is currently the best way to run docker images in microvm these days? The article is pushing for docker sandboxes, but the "you need a docker login" makes is pretty much no-go for my use case.
> What if I told you that Docker Desktop has always used microVMs?
I'd say that I don't think it's that relevant? Hopefully everyone was aware that you required a VM to run Linux software on Windows and Mac, and then who would really care about what VM docker used to run development containers? The more expendable the better. Hopefully nobody is using a Windows PC with docker desktop in a production scenario - but given how utterly incompetent some people I met was, I'd not be too surprised from that
Yawn. IBM/AIX's WPARs & LPARs, Sun/Solaris' dynamic system domains & zones, BSD jails. How many times are we going to pat ourselves on the back for reinventing the wheel?
We know. But of course the hype of "microVMs" is just a rebranding of existing technologies with some modifications, macOS needed extra virtualization technologies just for containers for years:
Docker Desktop macOS (until 2025): QEMU + Virtualization.framework + Linux kernel (without extra drivers) = "microVM".
Now they use the native Apple virtualization libraries instead of QEMU for both containers and microVMs. [0] Linux never needed to use KVM for containers, but requires it for microVMs:
Linux: KVM + Linux kernel (without extra drivers) = Firecracker "microVM".
In reality, it is different depending on the OS that you are using.
You sure could. Kata containers have been around for a long time; I remember putting them into production back in 2017 or so (and dealing with filesystem forwarding issues). https://lwn.net/Articles/755230/
Neither XNU/Darwin nor Windows have had an oob option for running Linux images. WSL is rather new in comparison.
Then I would say your title is wildly misleading.
And the current Sandboxes dont offer the same security model - See Docker Sandboxes 0.42.0 security update: CVE-2026-77179 and CVE-2026-79994
https://docs.docker.com/security/security-announcements/
I do think this was well ahead of its time. Under the hood, we designed a Linux distro called LinuxKit (https://github.com/linuxkit/linuxkit) which ran every process in its own mount namespace (including the init process), and had a deterministic build with hashes. As far as I can tell, it's still pretty hard to get this experience even with Nix in 2026.
The boot time was also quick enough to be entirely in parallel and so not be noticeable (the 'bounce time' of the application on Mac was one bounce!)
Because the current needs are extremely lightweight and isolated environments i.e. vm per workload rather than shared.
And there's been a lot of wonderful innovations happen there
I tried pure wslc for a project or two this past week. It got me 90% of the way but not all the way. Still pretty impressive, even if it is another example of extend and extinguish.
Pretty strange article considering all the Docker shortcomings.
I'd say that I don't think it's that relevant? Hopefully everyone was aware that you required a VM to run Linux software on Windows and Mac, and then who would really care about what VM docker used to run development containers? The more expendable the better. Hopefully nobody is using a Windows PC with docker desktop in a production scenario - but given how utterly incompetent some people I met was, I'd not be too surprised from that
Do you remember VMS on DEC hardware? And again, which decade did that come out?
Yeah, this wheel is going to continue to be re-invented for as long as computers exist.
We know. But of course the hype of "microVMs" is just a rebranding of existing technologies with some modifications, macOS needed extra virtualization technologies just for containers for years:
Now they use the native Apple virtualization libraries instead of QEMU for both containers and microVMs. [0] Linux never needed to use KVM for containers, but requires it for microVMs: In reality, it is different depending on the OS that you are using.[0] https://www.docker.com/blog/docker-desktop-for-mac-qemu-virt...