Today we’re announcing the public beta of a fully rebuilt Docker VMM: a new first-party virtualization layer underneath Docker Desktop, optimized for containers, and now available on both Mac and Windows starting with Docker Desktop v4.86.
What’s Changed, and Why It Matters
Part of the magic of Docker Desktop is how it provides a seamless deployment of the Linux-native Docker engine on other platforms, like macOS and Windows. To support that, Desktop automatically creates and manages a VM and all the complicated integration of your local network and filesystem, in a safe and performant way.
Creating that VM is the job of a virtual machine monitor, the layer that sits between your hardware and the containers Docker runs. Most developers never think about it. But when it’s slow, unstable, or holding onto your machine’s memory it should have released, you notice it constantly.
Docker Desktop has always relied on a third-party VMM for this. Now it runs on Docker VMM, built by us from the ground up. That means we own the full stack, and we can tune every part of the engine for container workloads specifically. That translates directly to you: an engine that improves continuously, responds to developer feedback, and ships on our own schedule.
This matters for everyone running Docker Desktop today. Performance, stability, and governance improvements at the virtualization layer enhance the experience across the board, for every workflow, on every team.
Image 1: Isometric diagram of the Docker stack: Host, DockerVMM, and Docker Engine layers.
The Performance Improvements Are Real
Here’s what you’ll notice when you start using the beta release of Docker VMM:
Faster startup. Container startup is measurably faster across the board, from first launch to project switches to restart recovery.
Better file I/O. File sharing between container and host is significantly faster. When you’re in an edit-compile-test loop, you’ll see improvements every single build.
Smarter memory management. Docker VMM returns memory to the host when containers are idle, so Docker Desktop isn’t holding onto RAM you’re not using.
Improved stability on Windows. For the first time, Windows developers get a VMM built and maintained by Docker, with performance and stability work coming straight from us.
Stronger isolation, better performance. DockerVMM still runs in a fully isolated VM, optimized for performance. On Windows, that means the isolation you’d expect from Hyper-V with the speed you’d expect from WSL2.
One Engine, Everywhere You Run Docker
The virtualization engine powering Docker VMM also powers Docker Sandboxes (SBX). That’s not a coincidence; it’s intentional. Every improvement lands in both products, so you get them wherever you choose to run Docker.
This matters beyond performance. As we build deeper capabilities into the engine, including enterprise admin controls and tighter governance for dev environments, they surface across both products. Longer term, we’re building toward a unified runtime that spans laptop, cloud, and on-prem, where containers, Compose apps, and agents are all first-class on one foundation. Docker VMM is how Docker Desktop gets there, and this is step one.
How To Enable It
On Mac: If you are already using Docker VMM in Settings, you will be automatically updated to the new engine when you upgrade to v4.86.
On Windows: Open Settings > General and you will see a new “Docker VMM” option. Switch it to opt in.
Image 2: Feature Flag for Docker VMM in Settings
No feature flag, no waitlist. Any Docker Desktop user on v4.86 or later can switch today. Note: Linux support will be available at GA.
What’s Next
Beta runs through fall, focused on real developer workflows: builds, file syncs, and the container startup patterns you hit every day.
GA is targeted for the end of October 2026, when Docker VMM becomes the default engine for new Docker Desktop installs across Mac, Windows, and Linux. GA is the baseline, and from there, the pace picks up. Everything we build next sits on this foundation.
Try It Today
Update to Docker Desktop v4.86 to get started.
Noticing a difference? Have ideas for where you’d want us to go next? We’re collecting feedback through in-product responses, our community Slack, and support channels.
This is the best Docker Desktop has ever run, and it only gets better from here.
Learn more
- Read more on Docker Docs
Docker VMM is available today in public beta in Docker Desktop v4.86 for Mac and Windows. Follow the Docker blog to stay up to date on GA and what comes next.
Facts Only
* A public beta of a rebuilt Docker VMM is available in Docker Desktop v4.86 for Mac and Windows.
* Docker VMM is a new first-party virtualization layer underneath Docker Desktop.
* The system supports the automatic creation and management of a VM and integration for running the Linux Docker engine on macOS and Windows.
* Performance improvements include faster container startup times.
* File I/O between containers and the host is significantly faster.
* Memory management is improved by returning unused memory to the host when containers are idle.
* Windows developers gain a VMM built and maintained by Docker.
* Docker VMM powers Docker Sandboxes (SBX).
* Users can enable the feature via settings on Windows or automatic update on Mac when upgrading to v4.86.
* General Availability (GA) is targeted for the end of October 2026 across Mac, Windows, and Linux.
Executive Summary
A new first-party virtualization layer named Docker VMM has been released in public beta within Docker Desktop v4.86 for Mac and Windows. This layer functions as a virtualization engine underneath Docker Desktop, managing the creation and integration of a virtual machine for running the Linux-native Docker engine on non-Linux operating systems. The development of Docker VMM aims to give Docker full control over the virtualization stack, shifting from relying on third-party Virtual Machine Monitors.
The beta release focuses on performance improvements across several areas: faster container startup times, significantly faster file I/O between containers and the host, smarter memory management by returning unused RAM to the host, and enhanced stability specifically on Windows. The technology also powers Docker Sandboxes (SBX), aiming toward a unified runtime foundation spanning local development environments, cloud infrastructure, and on-premise systems.
The rollout is immediate for existing users of Docker Desktop v4.86 or later via an opt-in setting in the system settings on Windows, and automatic update on Mac upon upgrading to the new version. The general availability (GA) is targeted for the end of October 2026 across Mac, Windows, and Linux.
Full Take
The narrative centers on shifting control and ownership of the virtualization layer from third parties to the product owner, positioning Docker VMM as a foundational element for future unified container runtime goals. The pattern involves framing performance gains not just as technical achievements but as direct improvements to the developer experience (faster loops, better stability), which naturally creates high perceived value. This builds trust by offering tangible, immediate benefits before revealing the long-term architectural goal of a unified runtime across different deployment environments.
The implication is that fragmentation in the virtualization layer introduced friction; unification solves this friction, promising holistic improvements for developers regardless of their host OS or infrastructure context. The timeline suggests a measured, feature-driven approach, balancing immediate beta utility with a distant GA target. A potential point of scrutiny lies in the commitment to long-term governance and enterprise controls; the narrative emphasizes performance first, but deeper integration into administration and governance must be sustained without creating new friction for end-users or adding undue complexity before the 2026 timeline. The move toward a unified runtime across laptop, cloud, and on-prem suggests an attempt to establish a strong control plane dominance over the developer's entire workflow environment.
Bridge Questions: If performance gains are realized and stability is enhanced, what specific governance controls will be introduced in the subsequent phases to satisfy enterprise demands? How will the transition from a beta feature to a default engine ensure that the performance optimizations do not inadvertently compromise security isolation expectations on systems like Windows? What metrics will define the success of this unified runtime approach beyond raw speed?