Docker Desktop is replacing its third-party VM layer with Docker VMM

Docker rebuilt the virtual-machine monitor underneath Docker Desktop as a first-party component and put it into public beta in Desktop 4.86. Since BTN’s original dossier, Docker Desktop 4.88.0 shipped on August 24 with two VMM-specific changes that materially qualify the beta: Docker says it fixed a regression that had reduced container inbound network throughput to roughly 0.3 GB/s, and Docker VMM on Mac can now use more than 28 GiB of host memory. The release notes also fix a settings bug where changing the hypervisor could have no effect while Resource Saver was active. Docker still describes VMM as the path toward a common first-party virtualization layer shared with Docker Sandboxes, with general availability targeted for late October 2026.

Owning Desktop’s VM layer lets Docker tune startup, file I/O, networking, memory reclamation and isolation directly, but 4.88 demonstrates why the public-beta label matters operationally. A networking regression severe enough for Docker to quantify at roughly 0.3 GB/s could materially distort local service, proxy, database or test performance, while the earlier 28 GiB Mac ceiling constrained memory-heavy development stacks. Builders evaluating VMM should therefore treat point releases as part of the migration, benchmark representative workloads on the exact Desktop version they plan to deploy, and keep an alternative hypervisor path until the VMM reaches GA and accumulates broader stability evidence.

Docker Desktop runs its Linux engine inside a VM on macOS and Windows, so its VMM sits beneath ordinary local container workflows. Docker says Desktop previously depended on a third-party VMM; Docker VMM is built and maintained in-house and tuned for container workloads. That gives Docker direct control over startup, networking, file sharing, memory behavior and isolation, and the same virtualization engine also powers Docker Sandboxes.

Docker Desktop 4.88.0, released August 24, says it fixes a Docker VMM regression that reduced container inbound network throughput to roughly 0.3 GB per second. The release note does not publish the affected workload matrix, host configurations or a benchmark showing restored throughput, so builders should not infer a universal before-and-after figure. It is nevertheless strong first-party evidence that the beta has already produced a material networking regression and that VMM performance can change meaningfully between Desktop point releases.

The same 4.88 release says Docker VMM on Mac can now use more than 28 GiB of host memory. That removes a practical ceiling for memory-heavy local stacks, large databases, model-serving experiments and multi-service development environments. Docker does not specify a new universal maximum in the release note, so teams should verify the effective limit on their own hardware and Desktop configuration.

Docker’s original VMM announcement claims faster startup, better host-container file I/O, improved memory reclamation and better Windows stability, but those remain vendor claims without broad independent benchmark coverage. The 4.88 regression fix reinforces a safer rollout pattern: test bind mounts, inbound networking, databases, Compose stacks, memory pressure, Resource Saver transitions and suspend/resume behavior on the exact Desktop build before making VMM the team default.

Docker says the first-party VMM is also used by Docker Sandboxes and targets general availability for late October 2026, when it plans to make Docker VMM the default for new Docker Desktop installs. The architectural direction remains significant because local container development and isolated agent execution increasingly share the same Docker-controlled virtualization foundation; regressions or improvements in that layer can therefore affect more than ordinary containers.