Docker’s Rebuilt VMM Turns Container Virtualization Into a First-Party Bet

Docker announced a public beta on August 12, 2026 of a rebuilt Docker VMM, the virtualization layer that sits underneath Docker Desktop on Mac and Windows. The company describes the release, live starting with Docker Desktop v4.86, as a complete overhaul built from the ground up, and for the first time it extends beyond Apple Silicon Macs to Windows as well. General availability is targeted for the end of October 2026, when Docker VMM is set to become the default engine for new Docker Desktop installs across Mac, Windows, and Linux.

The announcement, co-authored by Docker’s Deanna Sparks and Colin Hemmings, frames the rebuild as Docker finally owning a piece of infrastructure it has depended on other vendors for since Docker Desktop first shipped.

What a Virtual Machine Manager Actually Does

Docker itself is Linux-native. Every container it runs expects a Linux kernel underneath it. On macOS and Windows there is no Linux kernel to hand containers directly, so Docker Desktop quietly creates and manages a virtual machine to host the Docker engine, then handles the networking and filesystem plumbing needed to make that VM feel invisible to a developer running docker build or docker run.

The component responsible for creating and running that VM is the virtual machine monitor, or VMM, sometimes also called a hypervisor. It is the layer that sits between the host’s hardware and the containers Docker runs. Most developers never interact with it directly. They notice it only when it goes wrong: slow container startup, sluggish file syncing between host and container, or memory that Docker Desktop refuses to give back after a container shuts down.

Docker’s post is blunt about the historical arrangement: “Docker Desktop has always relied on a third-party VMM for this.” On Mac, that meant HyperKit in Docker Desktop’s early years and, more recently, Apple’s own Virtualization Framework, which Docker began steering users toward after it retired QEMU as a supported backend in 2025. On Windows, it has meant sitting on top of Microsoft’s WSL 2 or Hyper-V.

A Beta That Predates Today’s Rebuild

Today’s release is not the first appearance of Docker VMM. Docker had already shipped an opt-in “Docker VMM (BETA)” option for Apple Silicon Macs by April 2025, when the company’s own QEMU deprecation notice described it as “our fastest option for Apple Silicon Macs.” That means Docker has been iterating on its own virtualization engine, in some form, for well over a year before this week’s announcement.

What changed on August 12 is scope and ownership. Docker now says the engine has been rebuilt from the ground up, extends to Windows for the first time as a first-party option rather than a wrapper around WSL 2 or Hyper-V, and no longer needs a feature flag or waitlist to try. Any Docker Desktop user on v4.86 or later can turn it on immediately: Mac users already on the Docker VMM beta are upgraded automatically, and Windows users opt in through Settings, then General, then a new Docker VMM toggle.

Linux support is notably absent from the beta and is scheduled to arrive only at general availability, a reminder that “cross-platform” here currently means two of Docker Desktop’s three supported host operating systems.

The Claims: Faster Startup, Smarter Memory, a New Deal for Windows

Four Concrete Improvements

Docker’s post lists four things it says beta users will notice: faster container startup across first launches, project switches, and restart recovery; faster file I/O between container and host; memory that gets returned to the host once containers go idle instead of sitting reserved; and, specific to Windows, the first VMM built and maintained by Docker itself rather than inherited from Microsoft’s virtualization stack.

Why “Hyper-V Isolation, WSL2 Speed” Is a Real Tradeoff, Not Just a Slogan

For the Windows claim, Docker’s own framing is that switching to Docker VMM gets developers “the isolation you’d expect from Hyper-V with the speed you’d expect from WSL2.” That line makes more sense with context Docker’s post does not spell out. WSL 2 is not really an alternative to Hyper-V: it runs on top of it. Microsoft’s own documentation confirms WSL 2 works by running a full Linux kernel inside “a lightweight utility virtual machine,” and that this utility VM is itself a Hyper-V virtual machine under the hood, just a stripped-down one tuned for fast boot times, a small resource footprint, and tight Windows integration rather than for hard isolation boundaries. A general-purpose Hyper-V VM, by contrast, is provisioned and managed more like a traditional virtual machine: more isolated, more configurable, and slower to start.

Docker’s pitch is that a VMM built specifically for container workloads, instead of general Linux compatibility (WSL 2’s job) or general VM hosting (Hyper-V’s job), can land closer to both ends of that tradeoff at once. That is a plausible engineering argument, but it is still Docker’s own characterization of a beta release. No independent benchmarks of the rebuilt engine have been published yet.

One Engine, Two Products

Docker frames the rebuild as more than a Docker Desktop feature. The same virtualization engine that powers Docker VMM also powers Docker Sandboxes (SBX), the isolated-environment product Docker has been building out for AI coding agents. “That’s not a coincidence; it’s intentional,” the post says: every performance and stability improvement that lands in Docker VMM lands in SBX at the same time, since both run on the same underlying runtime.

That connection matters more than it might first appear. Docker has spent much of 2026 building out an AI agent security story, from SBX’s isolation model to the Open Secure AI Alliance it joined with NVIDIA. A faster, more stable, first-party hypervisor is not just a developer-experience upgrade for people running docker compose up. It is also the isolation boundary Docker is asking enterprises to trust when an AI agent executes code on their behalf. The company’s stated long-term goal, a unified runtime spanning laptop, cloud, and on-prem where containers, Compose apps, and agents are all first-class on one foundation, only holds together if the engine underneath all three is solid.

What to Watch Before General Availability

Docker has given itself until the end of October 2026, roughly eleven weeks from this announcement, to take Docker VMM from opt-in beta to default engine for new installs across three operating systems. That is an aggressive timeline for a from-scratch hypervisor rewrite, and Docker’s own post is candid that the beta period exists specifically to stress-test “the container startup patterns you hit every day” against real developer workflows rather than synthetic benchmarks.

Teams evaluating the beta should treat Docker’s performance claims as a starting point, not a verified result, until independent measurements appear. The more concrete near-term signal to watch is simpler: whether Docker hits its own October general availability date with Linux support included, or whether, like many hypervisor rewrites before it, the last mile of platform parity takes longer than the announcement implies.