Docker VMM goes public beta with Docker Desktop's virtualizer rewritten in-house

Docker put its own virtual machine monitor under Docker Desktop and shipped it as a public beta on Mac and Windows this week, per a Docker blog post dated August 12. The engine that boots the Linux VM behind every container on a laptop is now Docker's own code, described in the announcement as a complete overhaul of the layer. For a CI/CD practitioner the immediate change is local: the inner loop runs on a rewritten hypervisor before anything reaches the pipeline.

What Docker actually swapped out

Docker Desktop has always run containers inside a Linux VM on Mac and Windows, because Docker's runtime is Linux-native. The v4.86 release swaps in a first-party virtualizer built by Docker for the job. Same VM boundary, new engine.

The change is invisible if you do not look for it. Containers still start with docker run, images still land in the same local cache, docker compose still works. The beta is about what happens below the socket.

The performance pitch, and the number that isn't there

Docker's beta note claims measurably faster container startup, significantly faster file sharing between container and host, and idle memory returned to the host when containers sit unused. On Windows the post frames the goal as Hyper-V-style isolation with WSL2-style speed.

What the post does not include is a benchmark. There is no chart, no seconds-per-cold-start, no gigabytes-per-second bind-mount number. "Measurably" is a claim about a measurement that has not been published yet. For anyone deciding whether to opt in on a fleet this matters. A beta is exactly when the vendor should be handing you the numbers, not the adjectives.

The pieces most likely to move are the ones that hurt today. macOS bind-mount throughput has been the long-running complaint of anyone running a Node, Python or Ruby workflow against a large source tree. If Docker VMM narrows that gap, the win lands on every docker compose up where the source directory is mounted in. Cold-start latency matters less to CI, where the VM is warm for the whole job, and more to local docker run --rm loops where the shell waits.

Enabling it

Docker Desktop v4.86 is the floor. On Mac, machines already using Docker VMM get the new engine automatically on upgrade. On Windows, the toggle is in Settings then General, under a new Docker VMM option. There is no waitlist and no feature flag beyond that toggle. Linux support is not in the beta and is deferred to general availability.

Docker's stated GA target is the end of October. Until then the code carries beta labeling and the usual caveat: expect it to move.

What breaks, and how you notice

Two failure modes are worth watching on any hypervisor swap. First, filesystem semantics: bind mounts, symlinks, inotify events and case sensitivity behave differently between VMM implementations, and the corner cases surface in build tools that watch files. Second, network path MTU and DNS resolution inside the VM. These are the pieces that break silently and show up as flaky integration tests rather than a crash.

If your local pipeline includes anything that assumes the previous VMM's exact behaviour, catch it in a branch first and keep CI on hosted runners while you do. That is not a criticism of Docker VMM. That is what a public beta means.

The wider stack

Docker VMM lands in territory several projects already share. Lima, Colima, Podman Desktop's machine backend, Rancher Desktop, orbstack and finch all wrap a Linux VM behind a Docker- or Kubernetes-shaped socket on macOS. Each trades install size against memory footprint against how invisible the VM feels from the host. The competitive framing is less about which layer is fastest today and more about which is the default. Docker Desktop still owns the seat under most developers' inner loop, and the default engine shapes the assumptions the rest of the toolchain quietly builds against. Bringing that engine in-house means the next round of Docker Desktop performance work is not gated on an upstream project's roadmap.

The read for CI teams

Hosted runners are unaffected. Nothing about your build cluster changes. What changes is the machine your developers reproduce failures on, and how closely that machine matches the runner it targets. Watch the beta notes when the benchmark numbers land. Until then the pitch is a claim without a chart.