Thread

Docker has always used microVMs (well since 2016)

48 points · 39 comments · avsm

Loading the complete thread in the background. This saved snapshot is available now. Refresh

cr125rider · 1791068081 · focus · HN ↗
Is all of docker one “micro” VM though? Or does each container get a clean, fresh one?
1. firesteelrain · 1791068912 · focus · HN ↗
  It’s all one lightweight VM. Containers share the VM’s kernel.
  1. binsquare · 1791073902 · focus · HN ↗
    The shared kernel/lack of isolation between the cotnainer workloads is the model that this article isn't really touching but is really important.
    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
  2. jbverschoor · 1791089469 · focus · HN ↗
    So no micro VMs at all
2. sureglymop · 1791154081 · focus · HN ↗
  Look into the krun runtime (part of crun) if you'd like to do this.
sudb · 1791070735 · focus · HN ↗
One reason I think a distinction is made is that native Docker-in-Docker can be a real pain, but Docker in a Firecracker microVM "just works".
yjftsjthsd-h · 1791071137 · focus · HN ↗
> What if I told you that Docker Desktop has always used microVMs?
Then I would say your title is wildly misleading.
unsnap_biceps · 1791071291 · focus · HN ↗
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.
1. throwaway27448 · 1791076345 · focus · HN ↗
  [delayed]
  1. c0balt · 1791081687 · focus · HN ↗
    In those two cases they also use VMs because they don't really have another cheap option.
    Neither XNU/Darwin nor Windows have had an oob option for running Linux images. WSL is rather new in comparison.
    pjmlp · 1791102060 · focus · HN ↗
    Windows has native support for Win32 containers though, those don't need WSL.
    c0balt · 1791159686 · focus · HN ↗
    Sure but almost no OSS projects build containers for Windows (to my knowledge). The same goes for XNU/darwin afaik. They may get binaries but container images often assume Linux by default.
    Developers, ime, also don't really want to start building their own container images for auxiliary services like, e.g., PostgreSQL, MongoDB or MySQL. Having virtualized Linux support means you can take the existing ecosystem and make it accessible to the other two.
  2. otterley · 1791091516 · focus · HN ↗
    Of course it’s not a bad idea. It’s just a bad article.
2. avsm · 1791101158 · focus · HN ↗
  > 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). <a href="https://lwn.net/Articles/755230/" rel="nofollow">https://lwn.net/Articles/755230/
  1. unsnap_biceps · 1791134727 · focus · HN ↗
    "Could" is not the same as "always" which is what the article title is claiming.
rvz · 1791071536 · focus · HN ↗
...*on macOS only and runs qemu as the emulator.
We know. But of course the hype of "microVMs" is just a rebranding of an existing technologies with some modifications.
Linux: KVM + Linux kernel (without extra drivers) = Firecracker "microVM".
This is what Docker uses for macOS:
macOS: QEMU + Virtualization.framework + Linux kernel (without extra drivers) = "microVM".
In reality, it is different depending on the OS that you are using.
garypdx · 1791073353 · focus · HN ↗
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?
1. bradknowles · 1791075203 · focus · HN ↗
  Lots. Remember the first VM OS? Running on IBM mainframes? Do you remember what the name of it was? Or when that came out?
  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.
  1. mech422 · 1791076041 · focus · HN ↗
    Damm...thats going waayy back - but I want to say VS/VME (VM/VME) in the early 70s and vms in the mid 70s ?
2. yjftsjthsd-h · 1791082782 · focus · HN ↗
  Most of those are shared kernel, though, which is very much what you want to avoid if security is a primary goal.
  1. happymellon · 1791118962 · focus · HN ↗
    Docker is a shared kernal.
    yjftsjthsd-h · 1791137671 · focus · HN ↗
    Yes, and this article is about Docker Desktop running it in a VM with its own kernel.
    happymellon · 1791180207 · focus · HN ↗
    Running all the containers with a shared kernel...
kj4ips · 1791074510 · focus · HN ↗
I often wonder what would have happened if rkt had been more successful.
Betelbuddy · 1791076636 · focus · HN ↗
Its bending history to call what before were Linux Vms inside Mac or Windows to have containers to that is a real MicroVM.
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
<a href="https://docs.docker.com/security/security-announcements/" rel="nofollow">https://docs.docker.com/security/security-announcements/
1. user_account · 1791133786 · focus · HN ↗
  right, I cringed at this claim from the article
  > and considered more secure than, traditional Linux Docker containers.
davoneus · 1791078954 · focus · HN ↗
I wonder if this is due to Microsoft pushing forward with wslc on the pay 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.
screm · 1791079833 · focus · HN ↗
And yet it's never picked by coding agents for sandboxes -> <a href="https://armature.tech/leaderboards#app/sandboxes">https://armature.tech/leaderboards#app/sandboxes
segmondy · 1791083011 · focus · HN ↗
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.
1. throooooo · 1791098293 · focus · HN ↗
  I washed my hands of Docker back when they changed the licensing of Docker Desktop. Podman is fine.
otterley · 1791091482 · focus · HN ↗
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.
jeswin · 1791092369 · focus · HN ↗
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.
1. LeBit · 1791118869 · focus · HN ↗
  smolvm uses only the required memory and releases what isn’t needed anymore
qalmakka · 1791095081 · focus · HN ↗
> 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
happosai · 1791096472 · focus · HN ↗
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.
1. jbverschoor · 1791097140 · focus · HN ↗
  Apple containers
2. LeBit · 1791118819 · focus · HN ↗
  Smolvm
GuestFAUniverse · 1791099234 · focus · HN ↗
Would have been nice to properly isolate the bazillion ufw users too.
Pretty strange article considering all the Docker shortcomings.
avsm · 1791100690 · focus · HN ↗
For the nostalgia seekers, I uploaded the OG Docker for Mac beta video: <a href="https://crank.recoil.org/w/3re5G972kkqjzzujxHQ3E6" rel="nofollow">https://crank.recoil.org/w/3re5G972kkqjzzujxHQ3E6
I do think this was well ahead of its time. Under the hood, we designed a Linux distro called LinuxKit (<a href="https://github.com/linuxkit/linuxkit" rel="nofollow">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!)
spwa4 · 1791115536 · focus · HN ↗
The big plus of using microVMs is that a bunch of container limitations fall away. In Linux, over time people have been eliminating the limitations of containers. Chroot, network namespaces, filesystem namespaces, process namespaces, ... everything is trying to go into the direction of getting to microVMs making things more complicated at every step of the way.
But decent VM automation on VirtualBox (for the first ~5 years had MUCH better API/RPC and frankly still does than anything else) got you all that 10+ years ago.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.