Docker VMM Public Beta: What Docker's First-Party Virtualization Engine Changes

On August 12, 2026, Docker shipped the public beta of Docker VMM — a virtualization layer it built and now owns end to end, replacing the third-party engines Docker Desktop has relied on since it first needed a Linux VM on Mac and Windows. Until now, that VM ran on Apple's Virtualization Framework on macOS and on WSL2/Hyper-V on Windows — infrastructure Docker didn't control and couldn't tune specifically for container workloads. Docker VMM is Docker's own hypervisor code, shipping in Docker Desktop 4.86+, and it's opt-in during the beta. Here's what actually changed, how to turn it on, and the known rough edges before you flip it on a machine you rely on.

Why Docker built its own hypervisor

Docker Desktop's core job is running a Linux VM that hosts your containers, then bridging networking and filesystem access between that VM and your host OS. For years, the actual virtualization — the part that creates and schedules the VM — was someone else's code: Apple's Virtualization Framework on macOS, and WSL2 (itself layered on Hyper-V) on Windows. That meant Docker's ability to fix VM-level performance problems, ship updates on its own schedule, or optimize specifically for how containers actually use memory and disk was bounded by what the underlying platform exposed.

Docker VMM removes that dependency. It's a purpose-built VMM tuned for container workloads specifically — not general-purpose VM hosting — and it's the same engine underneath both Docker Desktop and Docker Sandboxes (Docker's isolated environments for running untrusted or AI-agent-generated code). Owning the stack also sets up enterprise features Docker has been signaling for a while: admin-level controls over VM resource policy that aren't possible when the hypervisor belongs to someone else.

What's actually different

Docker's stated performance goals for the new engine: faster container startup (first launch, project switches, and restart recovery specifically called out), noticeably faster file I/O between host and container — which matters directly for edit-compile-test loops in a mounted project directory — smarter memory reclamation when containers sit idle, and on Windows specifically, isolation on par with Hyper-V but with WSL2-like speed, which have historically been a tradeoff against each other. Docker hasn't published hard benchmark numbers (latency deltas, memory percentages) alongside the beta — the public claims are qualitative, so treat "faster" as directionally true and verify it against your own workload rather than a vendor number.

Step 1 — Check your Docker Desktop version

Docker VMM requires Docker Desktop 4.86 or later. Check your installed version:

1docker --version
2docker info --format '{{.ServerVersion}}'

If you're on an older release, update Docker Desktop first — the VMM toggle won't appear otherwise.

Step 2 — Give the Linux VM enough memory before switching

Docker recommends at least 4 GB of memory allocated to the Docker Linux VM before you switch engines. Check and adjust this first:

1. Open Docker Desktop Settings → Resources.
2. Confirm Memory is at or above 4 GB. If it's lower, raise it.
3. Apply the change (this alone may prompt a restart — that's fine, do it before touching the VMM setting).

Step 3 — Enable Docker VMM

The toggle lives in the same place on both platforms:

1. Open Docker Desktop Settings → General.
2. Find the Virtual Machine Manager section.
3. Select Docker VMM.
4. Click Apply & restart.

On Mac, this is a straightforward switch away from Apple's Virtualization Framework. On Windows, it replaces the WSL2/Hyper-V-backed engine — note that this is a different toggle from your WSL distro settings, and enabling Docker VMM doesn't uninstall or disable WSL2 itself, it just stops Docker Desktop from using it as the VM backend.

Step 4 — Rebuild your mental model of file sharing

Docker VMM does not carry over bind mount auto-shares. If a container that previously mounted a host directory without any explicit configuration starts throwing file-sharing errors after the switch, that's why:

1. Open Settings → Resources → File sharing.
2. Manually add the host directories your containers actually mount.
3. Restart the affected containers.

This is the single most common "it broke after I enabled VMM" report — check it first before assuming something else is wrong.

Step 5 — Watch for the two known compatibility gaps

Docker has flagged two specific rough edges in the beta, both worth checking against your own stack before you commit a whole team to the switch:

• Rosetta emulation of amd64 images on Apple Silicon performs poorly under Docker VMM. If your workflow depends on running x86_64 images on an M-series Mac via Rosetta, benchmark it before switching your primary machine — this is a known regression, not a one-off report.
• MongoDB and Cassandra can fail when running on virtiofs. Both databases do enough low-level file I/O (memory-mapped files, custom storage engines) that virtiofs edge cases surface more readily than with typical stateless app containers. If you run either locally for development, test data persistence and startup specifically before relying on VMM for that project.

Best practices

• Pilot on one machine, not your whole team's fleet at once. This is a beta; treat the rollout like any other infrastructure change — one volunteer, one project, verified working, before it becomes the default for everyone.
• Re-add file shares deliberately, not reactively. Audit which directories your docker-compose.yml files and docker run -v commands actually mount, and pre-add them in Settings rather than discovering each one via a failed container start.
• Keep an eye on the GA timeline if you depend on Linux hosts. Docker VMM doesn't support Linux as a Docker Desktop host yet — that's targeted for the general-availability release around the end of October 2026, alongside VMM becoming the default engine for new installs on all three platforms.
• Report regressions through the built-in feedback tool, not just a support ticket — Docker is explicitly using the beta period (through fall 2026) to gather real workflow data, and in-product feedback is how it gets triaged against actual usage patterns.

Common mistakes to avoid

• Switching on a machine mid-sprint without a rollback plan. You can switch back to the previous engine the same way you enabled VMM — via Settings → General → Virtual Machine Manager — but do that testing on a non-critical machine first, not the one you need working in an hour.
• Assuming WSL2 gets uninstalled. Enabling Docker VMM on Windows changes what Docker Desktop uses internally; it doesn't remove your WSL distros or affect other tools that use WSL2 directly.
• Not raising VM memory first. Switching with less than 4 GB allocated is the fastest way to get a confusing, unrelated-looking failure on first restart.
• Benchmarking against marketing language instead of your own workload. Docker's performance claims are real directionally, but they're not substitutes for timing your own project's build and startup before and after.

Troubleshooting

Containers with mounted volumes fail to start after switching. This is almost always the bind-mount auto-share gap — go to Settings → Resources → File sharing and manually add the missing paths.

amd64 images under Rosetta are noticeably slower on Apple Silicon. This is a documented current limitation of the beta, not a misconfiguration. If Rosetta performance is load-bearing for your workflow, stay on the previous engine until this is addressed.

MongoDB or Cassandra containers fail to persist data or crash on startup. Test against virtiofs specifically — this is a known interaction, and switching that one service's volume driver or staying off VMM for that project is currently the workaround.

The VMM option doesn't appear in Settings at all. Confirm you're on Docker Desktop 4.86 or later; the toggle isn't present on older releases.

FAQ

Is Docker VMM the default engine now? No. It's opt-in during the public beta, which runs through fall 2026. Docker's stated target is for VMM to become the default for new installs at general availability, around the end of October 2026.

Does Docker VMM work on Linux hosts? Not yet. Linux support is planned for the GA release, not the current beta.

Do I lose my existing containers or images when I switch? No — switching the VMM engine changes the virtualization layer underneath Docker Desktop, not your images, containers, or volumes. File-sharing paths for bind mounts are the one thing you need to re-add manually.

Can I switch back if something breaks? Yes, the same Settings → General → Virtual Machine Manager control lets you select the previous engine and restart.

Is this related to Docker Sandboxes? Yes — Docker VMM is the same underlying virtualization layer that powers Docker Sandboxes, Docker's isolated execution environments for untrusted or AI-agent-generated code. Improvements to VMM benefit both products.

Key takeaways

Further Reading

• Docker Hub OIDC for GitHub Actions: Retire Your Stored Access Tokens — another recent first-party Docker infrastructure change worth auditing your pipelines against.
• Docker vs Containerd Understanding: the Shift in Kubernetes 1.24+ — background on container runtime layers if the VM-vs-runtime distinction here is new to you.
• A Comprehensive Guide to Docker Commands: Simplified for Everyone — reference if you're still building daily-driver Docker CLI fluency.
• Official announcement: Announcing: Docker VMM Public Beta
• Official docs: Docker VMM