Anyone who has ever left docker compose up running through a lunch break knows the small tax of Docker Desktop's VM. The fan spins up. File watchers go flaky. You alt-tab away, come back, and the container has quietly held onto memory it is no longer using. On August 12, Docker announced that its own virtualization layer, Docker VMM, is now in public beta on Docker Desktop for macOS and Windows.
The rebuild, in one paragraph
Docker VMM is Docker's first-party virtual machine monitor. It sits between your Mac or Windows host and the Linux userland that actually runs your containers. Until now, Docker Desktop leaned on a third-party VMM for that job. Docker says it rebuilt the layer from scratch, this time with container workloads as the only design goal. The same engine also powers Docker Sandboxes, the isolated dev environment product Docker ships alongside Desktop.
Where you feel it: file I/O and idle memory
The blog post lists four claims worth reading with an engineer's day in mind. Container startup should be faster: on the first launch, on project switches, and on the "I just closed my laptop over lunch" restart. File I/O between the host and the container should be faster, which is the friction almost every Docker Desktop user has cursed at least once. Memory management is smarter about handing RAM back to the host when a container goes idle. And on Windows specifically, Docker is claiming the "isolation you'd expect from Hyper-V with the speed you'd expect from WSL2".
No numbers. The post does not publish a benchmark, so the actual size of these wins is something you get to measure on your own project. If your test suite spends real minutes cross-mounting a big JS repo into the container, that is the place to look first.
Flipping it on
You do not need a waitlist or a feature flag.
- Update Docker Desktop to v4.86 or later.
- On macOS, if you were already on Docker VMM in the previous release, the auto-update carries you over.
- On Windows, open Settings, then General, then flip the Docker VMM toggle.
Roll it back the same way if it misbehaves.
What is not in the beta
Linux is not part of this beta. Docker says Linux support arrives at GA, and the post does not put a date on GA. If your team is a mix of macOS laptops and Linux workstations, you will only see the change on half the fleet for now.
The beta also does not come with a public benchmark or an explicit list of workloads where Docker VMM lags the old backend. The vendor claim is that container startup, file I/O, memory, and Windows stability all improve. Believe it after you time your own build.
What I am watching next
The interesting question for a developer-experience beat is not the synthetic-benchmark question. It is whether Docker VMM makes docker compose up stop being the thing you tab away from. That means bind-mount file I/O on real repos, and the polling latency for tools like Vite, Turbopack and pytest-watch. The Windows and macOS story on that front has been rough for years.
I am also curious about the memory reclaim behavior. If Docker VMM really does hand RAM back to the host when a container idles, you can leave more of a stack running through the workday without your machine slowing to a crawl. A quiet change like that would matter more than any startup number.
For now: update, flip the switch, run the workload you actually complain about. The Linux GA timeline is worth pinning down before you commit a whole team.
