Docker replaces the third-party hypervisor under Docker Desktop with its own VMM
On August 12, 2026 Docker opened the public beta of Docker VMM, an in-house virtualization layer that replaces Apple Virtualization and Hyper-V under Docker Desktop. The promised gains cover startup, file I/O and memory, but they also make Docker the sole owner of the stack.
August 12, 2026. Docker opened the public beta of Docker VMM, a home-grown virtualization layer that replaces the third-party hypervisor Docker Desktop has relied on since its earliest days. Shipping in version 4.86 for macOS and Windows, it promises faster startup, faster file I/O, and memory management that hands idle RAM back to the host. General availability targets late October 2026, with Linux support landing at the same time.
The stakes fit in one sentence: for the first time, Docker owns the entire stack beneath its containers — from the engine down to the virtual machine that hosts it. That is a strategic pivot as much as a performance promise, and it is worth looking at what actually changes.
What the VMM is, and why nobody sees it
Under Docker Desktop, a Linux container never runs directly on a Mac or a Windows box: it runs inside a small, invisible Linux virtual machine, managed by a virtual machine monitor (VMM). That VMM creates the VM, wires up the local network, shares files, and translates hardware calls. Most developers never think about it — until the day it is slow, unstable, or holds onto memory it should have released.
Until now, Docker Desktop delegated this job to a third party. On macOS it used Apple’s Virtualization framework (after years of HyperKit, the historical in-house VMM). On Windows it leaned on WSL2 or Hyper-V. Docker VMM changes that: it is a hypervisor built by Docker, for container workloads, with no middle vendor in the way.
The difference is not cosmetic. A general-purpose VMM has to serve virtual machines of every shape. A VMM written for one job — running Docker’s Linux engine — can strip out everything that does not serve that job: unused devices, generic boot paths, file-sharing indirections. That is precisely Docker’s argument: “we own the full stack, so we can tune every part of the engine for container workloads.”
The four promised gains
The beta page lists four concrete effects, aimed squarely at daily friction:
- Faster startup, from first launch to project switches to restart recovery;
- Better file I/O, with noticeably faster host-container sharing — the edit-compile-test loop wins on every build;
- Smarter memory management, returning RAM to the host when containers sit idle;
- Improved Windows stability, with a VMM built and maintained by Docker for Windows users for the first time.
The last point deserves a technical note: on Windows, Docker VMM remains a fully isolated VM, but Docker positions it as the best of both worlds — Hyper-V-grade isolation with WSL2-grade speed. Isolation stays total, which rules out the “container running as a host process” scenario and its security implications.
A configuration detail that matters: VirtioFS becomes mandatory
What the announcement buries is a configuration constraint. Docker VMM supports only one file-sharing mechanism: VirtioFS. Users still on gRPC-FUSE (or the legacy osxfs sharing) will be switched over to VirtioFS the moment they enable the beta.
The choice is coherent: VirtioFS is now the fastest implementation, with claimed gains of up to 98 % on some filesystem operations. But for teams whose workflows depended on specific behavior of the old sharing — large monorepos, nested mounts in particular — moving to Docker VMM is not just a checkbox. It is a file-sharing migration in disguise.
How to enable it, and how to verify
Enabling it is deliberately simple, with no waitlist and no feature flag to request. You need Docker Desktop 4.86 or newer, then:
- on macOS, users who had already selected “Docker VMM” in settings are updated to the new engine automatically when they upgrade to 4.86;
- on Windows, the option appears under Settings → General as a “Docker VMM” toggle you switch on manually.
Once it is running, two commands confirm the engine state and the embedded version:
# Docker Desktop and engine versions
docker version
# Detailed info: host OS, VM kernel, engine version
docker infoThe Server → Operating System field in docker version reports the Linux distribution embedded in the VM, and docker info confirms the kernel running under the new VMM. If you need to check the active sharing mechanism, it is under Settings → General → Choose file sharing implementation, where Docker Desktop lists VirtioFS as the only option compatible with Docker VMM.
The strategic bet: one engine for everything else
The beta is not just about performance. Docker says it outright: the Docker VMM engine is the same one powering Docker Sandboxes (SBX), the isolated environment for coding agents. Every engine improvement therefore lands in both products at once.
And the roadmap goes further. Docker’s stated endgame is a unified runtime spanning laptop, cloud, and on-premises, where containers, Compose apps, and agents are all first-class on a single foundation. Docker VMM is presented as step one on that path — which is why Docker is investing in a hypervisor even as the market drifts toward lighter runtimes.
The timing is no accident. Docker Desktop has become the company’s central commercial product, the one that funds everything else. By taking the VMM back in-house, Docker removes a technical dependency on Apple and Microsoft — two vendors whose virtualization priorities do not necessarily match Docker’s. It is also a way to tighten the experience: the enterprise admin controls and governance features announced for the future will plug directly into this engine.
The flip side: a single point of failure
Let us be blunt. Swapping a battle-tested hypervisor for a beta VMM is not a neutral move. Apple Virtualization and Hyper-V carry years of hardening; Docker VMM is starting from zero. If the new engine ships a bug — a memory leak, a sharing corruption, a VM crash — the user has no fallback: there is no other VMM to select behind it.
The risk window is short but real: the beta runs through the fall, and general availability targets late October 2026 — barely ten weeks after the opening. For a tool installed on millions of developer machines, that is an aggressive pace. The sensible play is to treat the beta as what it is: a testbed to enable on non-critical machines first, not on the laptop of whoever has to ship to production.
Verdict
Docker VMM is a sound strategic bet and a genuine comfort promise for developers. The logic holds: a hypervisor tuned for a single job almost always beats a general-purpose one, and owning the stack lets Docker iterate without waiting on Apple’s or Microsoft’s calendar.
The recommendation is conditional but firm: if you are on macOS or Windows, upgrade to 4.86 and enable the beta on a secondary dev machine — the startup and I/O gains are real, and the feedback helps the October GA. If your file sharing depends on gRPC-FUSE or exotic mounts, test VirtioFS before you switch, because it is the only supported mechanism. And if your machine is critical, wait for GA: ten weeks of beta is not a stability guarantee. Docker no longer has an excuse for a mediocre VMM — it now owns the problem, which is exactly why the beta deserves close attention.