Docker VMM in public beta: the other half of your slow build

Docker Desktop v4.86 ships a rebuilt, first-party virtualization layer for Mac and Windows, aimed at the two things that make container development on a laptop feel slow: startup and file sharing. Here is what the new engine changes, what it cannot touch, and why the Dockerfile half of the problem gets more visible as the platform half gets faster.

You save a file, the container rebuilds, and you wait. Eleven seconds, or forty if the dependency install reruns. It happens often enough that you stop registering it as waiting and start registering it as the texture of the job.

Some of that time belongs to the platform. On a Mac or a Windows machine your containers live inside a Linux VM, and something has to boot that VM, bridge its network into yours, and move files across the boundary between the two. Docker calls that component the VMM, and until now it has been someone else's: "Docker Desktop has always relied on a third-party VMM for this." As of v4.86 there is a first-party one, in public beta on both Mac and Windows.

I have not benchmarked it, and Docker has not published numbers, so what follows is a mental model rather than a performance review. The question I actually care about is which part of a slow loop a new engine can plausibly fix, and which part stays on my side of the boundary.

What the new engine claims

Docker calls out three developer-visible wins. None of them come with published figures yet, which is worth keeping in mind when you read them:

• Container startup is measurably faster across scenarios.
• File sharing between container and host is significantly faster. In Docker's words: "When you're in an edit-compile-test loop, you'll see improvements every single build."
• Idle memory goes back to the host, so Docker Desktop stops sitting on RAM you are not using.

Windows gets a fourth, and it may be the real headline there: this is the first Docker-maintained VMM on the platform, pairing Hyper-V isolation with WSL2-like speed. If you have spent years picking one of those and living with what the choice cost you, that is a bigger deal than a startup benchmark.

The file-sharing claim is the one I would watch. Host and container filesystem sharing has been the standing tax on container development outside Linux, and it is the reason a bind-mounted node_modules feels like it is running underwater. Plenty of teams paid that tax by moving their entire dev loop inside the container. If the tax drops far enough, some of those workarounds stop earning their complexity.

You do not have to wait for Docker's numbers to know what the claim is worth on your machine. The tax lives on the bind-mount path, so time that path once per engine:

#!/usr/bin/env bash
# Run once on the old engine, once on Docker VMM. Same repo, same image.

# Honest worst case: a dependency install over a bind mount.
docker run --rm -v "$PWD:/work" -w /work node:22-slim \
  sh -c 'time npm ci --no-audit --no-fund'

# Raw read throughput across the mount boundary.
docker run --rm -v "$PWD:/work" -w /work alpine \
  sh -c 'time tar cf /dev/null .'

Point it at a real repository rather than a toy directory. Mount overhead scales with file count, which is why a node_modules install is the honest worst case.

Turning it on

There is no feature flag and no waitlist. On Mac, if you already had Docker VMM selected in Settings, upgrading to v4.86 moves you onto the new engine automatically. On Windows you opt in: open Settings > General, find the new Docker VMM option, and switch it on.

To check which Docker Desktop you are on:

docker version --format '{{.Server.Platform.Name}}'
# Docker Desktop 4.86.0 (209721)

That reports the Desktop version and nothing about the engine choice. Which VMM you are running lives in a settings pane, and the daemon never mentions it.

The half that stays yours

A faster VMM makes the platform faster. It does not make your image smaller, your layers better ordered, or your build context less absurd. Most of the Dockerfiles I read have a version of this in them:

FROM node:22-slim
WORKDIR /app
COPY . .
RUN npm ci
CMD ["node", "server.js"]

Every edit to any file in the repo invalidates that COPY . . layer, and everything after it rebuilds. The dependency install reruns because you changed a comment in a route handler. Move the manifest copy ahead of the install and the cache survives your edits:

FROM node:22-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
CMD ["node", "server.js"]

Four lines reordered, and the forty-second rebuild becomes a one-second one. No VMM in any timeline was going to give you that.

If you have written React, you already know this bug

The build cache is a dependency array. Each instruction is a memoized step keyed on what it depends on, and Docker reruns it when the key changes. Writing COPY . . before your install is the same mistake as putting a freshly allocated object literal in a useMemo dependency array: the key changes on every pass, so the memo never hits and the expensive work runs every time.

The .dockerignore file is the other half of that analogy. It decides what is even eligible to change the key, which is why a missing one lets a stray log file or a local node_modules bust a cache layer that has nothing to do with either. It also decides how much data crosses the host-to-VM boundary on every build, which is exactly the boundary Docker VMM just optimized. The two effects stack.

Roughly, the split looks like this:

None of the right-hand column is new advice. What changes is the ratio. As the platform floor drops, the share of your loop that is your own Dockerfile's fault goes up, and the fix that was worth doing anyway becomes the fix that is worth doing first. I maintain docker-doctor partly because I got tired of finding the same four mistakes by hand; it is static analysis, so it never talks to your daemon and does not care which VMM you picked.

Sharp edges

This is a beta and it behaves like one. A few things I would keep in view:

• There are no published numbers. If the speed matters to a decision you are making, time your own loop before and after — the two commands earlier are the cheap version. Your build shape is the only benchmark that predicts your build.
• Mac users get switched without choosing. Upgrading to v4.86 with VMM already selected moves you onto the new engine. Worth remembering the next time a build feels different and you go looking for what you changed.
• Windows switchers leave WSL2 semantics behind. Resource limits stop living in .wslconfig, \\wsl$ paths no longer reach the engine's filesystem, and bind-mount performance changes shape in both directions. Scripts that assume the WSL2 backend need a second look.
• The engine is invisible to tooling. Nothing in docker version tells you which VMM is running, so comparing notes with a teammate comes down to comparing screenshots of a settings pane.
• Idle memory behaviour is changing under you. Returning RAM when containers go idle is the right default, but if you sized Desktop's memory allocation around the old behaviour, that tuning is now describing a machine that no longer exists.
• GA is close enough to plan around. Docker is targeting the end of October 2026, at which point Docker VMM becomes the default engine for new installs on Mac, Windows, and Linux. This is less an invitation to try something and more a couple of months of warning before a default changes.

Why it matters past your laptop

One line in the announcement is easy to skim: the engine behind Docker VMM also powers Docker Sandboxes, and Docker says that is deliberate, so every improvement lands in both. That is more interesting than it sounds if you run coding agents in sandboxes.

Agents are pathological container users. They build, run, tear down, and build again dozens of times inside a single task, and each cycle pays the startup and file-sync cost in full. A faster engine underneath is a faster agent loop, compounded across every iteration you are not watching. It also means a sloppy Dockerfile written by an agent gets rebuilt dozens of times rather than once, which is why I ship a sandbox kit that preinstalls the linter and tells the agent to run it before committing.

Docker is pulling the floor out from under the slow parts, and that is genuinely good news for anyone who develops on a Mac or a Windows machine. Whether your loop actually gets faster depends on how much of the slowness was ever the floor's fault. Mine, when I looked honestly, was four lines in the wrong order.