Why MicroVMs: The Architecture Behind Docker Sandboxes

Why MicroVMs: The Architecture Behind Docker Sandboxes | Docker

Skip to content

Insights on the state of AI agents from 800+ builders and leaders. Download your copy

✕

[](http://www.docker.com/)

• AI

AI

• Docker for AI Simplifying Agent Development
• Docker MCP Catalog and Toolkit Connect and manage MCP tools
• Docker Model Runner Local-first LLM inference made easy
• Docker Sandboxes New Isolated environments for coding agents

More resources for developers


• Products

Products

• Docker Hardened Images New Ship with secure, enterprise-ready images
• Docker Desktop Containerize your applications
• Docker Hub Discover and share container images
• Docker Scout Simplify the software supply chain
• Docker Build Cloud Speed up your image builds
• Testcontainers Desktop Local testing with real dependencies
• Testcontainers Cloud Test without limits in the cloud
• Docker MCP Catalog and Toolkit New Connect and manage MCP tools
• Docker Offload Break free of local constraints


• Developers

Developers

• Documentation Find guides for Docker products
• Getting Started Learn the Docker basics
• Resources Search a library of helpful materials
• Training Skill up your Docker knowledge
• Extensions SDK Create and share your own extensions
• Community Connect with other Docker developers
• Open Source Explore open source projects
• Preview Program Help shape the future of Docker
• Customer Stories Get inspired with customer stories

More resources for developers


Get the latest Docker news

• Pricing
• Support
• Blog
• Company

Company

• About Us Let us introduce ourselves
• What is a Container? Learn about containerization
• Why Docker Discover what makes us different
• Trust Find our customer trust resources
• Partners Become a Docker partner
• Customer Success Learn how you can succeed with Docker
• Events Attend live and virtual meet ups
• Docker Store Gear up with exclusive SWAG
• Careers Apply to join our team
• Contact Us We’d love to hear from you


Search

Sign InGet Started

Toggle menu

Why MicroVMs: The Architecture Behind Docker Sandboxes

Posted Apr 16, 2026

Srini Sekaran and Craig Gumbley

Last week, we launched Docker Sandboxes with a bold goal: to deliver the strongest agent isolation in the market.

This post unpacks that claim, how microVMs enable it, and some of the architectural choices we made in this approach.

The Problem With Every Other Approach

Every sandboxing model asks you to give something up. We looked at the top four approaches.

Full VMs offer strong isolation, but general-purpose VMs weren’t designed for ephemeral, session-heavy agent workflows. Some VMs built for specific workloads can spin up more effectively on modern hardware, but the general-purpose VM experience (slow cold starts, heavy resource overhead) pushes developers toward skipping isolation entirely.

Containers are fast and are the way modern applications are built. But for an autonomous agent that needs to build and run its own Docker containers, which coding agents routinely do, you hit Docker-in-Docker, which requires elevated privileges that undermine the isolation you set up in the first place. Agents need a real Docker environment to do development work, and containers alone don’t give you that cleanly.

WASM / V8 isolates are fast to spin up, but the isolation model is fundamentally different. You’re running isolates, not operating systems. Even providers of isolate-based sandboxes have acknowledged that hardening V8 is difficult, and that security bugs in the V8 engine surface more frequently than in mature hypervisors. Beyond the security model, there’s a practical gap: your agent can’t install system packages or run arbitrary shell commands. For a coding agent that needs a real development environment, WASM isn’t one.

Not using any sandboxing is fast, obviously. It’s also a liability. One rm -rf, one leaked .env, one rogue network call, and the blast radius is your entire machine.

Why MicroVMs

Docker Sandboxes run each agent session inside a dedicated microVM with a private Docker daemon isolated by the VM boundary, and no path back to the host.

That one sentence contains three architectural decisions worth unpacking.

Dedicated microVM. Each sandbox gets its own kernel. It’s hardware-boundary isolation, the same kind you get from a full VM. A compromised or runaway agent can’t reach the host, other sandboxes, or anything outside its environment. If it tries to escape, it hits a wall.

Private, VM-isolated Docker daemon. This is the key differentiator for coding agents. AI is going to result in more container workloads, not fewer. Containers are how applications are developed, and agents need a Docker environment to do that development. Docker Sandboxes give each agent its own Docker daemon running inside a microVM, fully isolated by the VM boundary. Your agent gets full _docker build_, _docker run_, and _docker compose_ support with no socket mounting, no host-level privileges, none of the security compromises other approaches require. This means we treat agents as we would a human developer, giving them a true developer environment so they can actually complete tasks across the SDLC.

No path back to the host. File access, network policies, and secrets are defined _before_ the agent runs, not enforced by the agent itself. This is an important distinction. An LLM deciding its own security boundaries is not a security model. The bounding box has to come from infrastructure, not from a system prompt.

Why We Built a New VMM

Choosing microVMs was the easy part. Running them where developers actually work was the hard part.

We looked hard at existing options, but none of them were designed for what we needed. Firecracker, the most well-known microVM runtime, was designed for cloud infrastructure, specifically Linux/KVM environments like AWS Lambda. It has no native support for macOS or Windows, full stop. That’s fine for server-side workloads, but coding agents don’t run in the cloud. They run on developer laptops, across macOS, Windows, and Linux.

We could have shimmed an existing VMM into working across platforms, creating translation layers on macOS and workarounds on Windows, but bolting cross-platform support onto a Linux-first VMM means fighting abstractions that were never designed for it. That’s how you end up with fragile, layered workarounds that break the “it just works” promise and create the friction that makes developers skip sandboxing altogether.

So we built a new VMM, purpose-built for where coding agents actually run.

It runs natively on all three platforms using each OS’s native hypervisor: Apple’s Hypervisor.framework, Windows Hypervisor Platform, and Linux KVM. A single codebase for three platforms and zero translation layers.

This matters because it means agents get kernel-level isolation optimized for each specific OS. Cold starts are fast because there’s no abstraction tax. A developer on a MacBook gets the same isolation guarantees and startup performance as a developer on a Linux workstation or a Windows machine.

Building a VMM from scratch is not a small undertaking. But the alternative, asking developers to accept slower starts, degraded compatibility, or platform-specific caveats, is exactly the kind of asterisk that makes people run agents on the host instead. Our approach removes that asterisk at the hypervisor level.

Fast Cold Starts

We rebuilt the virtualization layer from scratch, optimizing for fast spin up and fast tear downs. Cold starts are fast. This matters for one reason: if the sandbox is slow, developers skip it. Every friction point between “start agent” and “agent is running” is a reason to run on the host instead. With near-instant starts, there is no performance reason to run outside it.

What This Means In Practice

Here’s the concrete version of what this architecture gives you:

Full development environment. Agents can clone repos, install dependencies, run test suites, build Docker images, spin up multi-container services, and open pull requests, all inside the sandbox. Nothing is stubbed out or simulated. Agents are treated as developers and given what they need to complete tasks end to end.

Scoped access, not all-or-nothing. You define the boundary: exactly which files and directories the agent can see, which network endpoints it can reach, and which secrets it receives. Credentials are injected at runtime and outside the MicroVM boundary, never baked into the environment.

Disposable by design. If an agent goes off track, delete the sandbox and start fresh in seconds. There is no state to clean up and nothing to roll back on your host.

Works with every major agent. Claude Code, Codex, OpenCode, GitHub Copilot, Gemini CLI, Kiro, Docker Agent, and next-generation autonomous systems like OpenClaw and NanoClaw. Same isolation, same speed, one sandbox model across all of them.

For Teams

Individual developers can install and run Docker Sandboxes today, standalone, no Docker Desktop license required.

For teams that want centralized filesystem and network policies that can be enforced across an organization and scale sandboxed execution, [get in touch](https://www.docker.com/products/docker-sandboxes/) to learn about enterprise deployment.

The Tradeoff That Isn’t

The pitch for sandboxing has always come with an asterisk: _yes, it’s safer, but you’ll pay for it in speed, compatibility, or workflow friction._

MicroVMs eliminate that asterisk. You get VM-grade isolation with cold starts fast enough that there’s no reason to skip it, and full Docker support inside the sandbox. There is no tradeoff.

Your agents should be running autonomously. They just shouldn’t be running without any guardrails.

Use Sandboxes in Seconds

Install Sandboxes with a single command.

macOS_brew install docker/tap/sbx_

Windows_winget install Docker.sbx_

Read the docs to learn more.

agentsAI/MLsandboxesEngineeringProducts

Table of contents

[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.docker.com%2Fblog%2Fwhy-microvms-the-architecture-behind-docker-sandboxes%2F "Visit this Linkedin profile")[](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.docker.com%2Fblog%2Fwhy-microvms-the-architecture-behind-docker-sandboxes%2F "Visit this X profile")[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.docker.com%2Fblog%2Fwhy-microvms-the-architecture-behind-docker-sandboxes%2F "Visit this Facebook profile")

Related Posts

• Mar 31, 2026 #### Docker Sandboxes: Run Agents in YOLO Mode, Safely Agents have crossed a threshold. Over a quarter of all production code is now AI-authored, and developers who use agents are merging roughly 60% more pull requests. But these gains only come when you let agents run autonomously. And to unlock that, you have to get out of the way. That means letting agents run… 
• Apr 14, 2026 #### Why We Chose the Harder Path: Docker Hardened Images, One Year Later We’re coming up on a year since launching Docker Hardened Images (DHI) this May, and in this blog we celebrate the milestones, talk about our approach, and look at some practices in the industry. 
• Apr 13, 2026 #### How to Analyze Hugging Face for Arm64 Readiness Learn how to scan Hugging Face Spaces for Arm64 readiness using Docker MCP Toolkit and Arm MCP Server in minutes. 
• Apr 8, 2026 #### Reclaim Developer Hours through Smarter Vulnerability Prioritization with Docker and Mend.io We recently announced the integration between Mend.io and Docker Hardened Images (DHI) provides a seamless framework for managing container security. By automatically distinguishing between base image vulnerabilities and application-layer risks, it uses VEX statements to differentiate between exploitable vulnerabilities and non-exploitable vulnerabilities, allowing your team to prioritize what really matters. TL;DR: The Developer Value Proposition… 

Products

• Products Overview
• Docker Desktop
• Docker Hub
• Docker Scout
• Docker Build Cloud
• Testcontainers Desktop
• Testcontainers Cloud
• Docker MCP Catalog and Toolkit
• Docker Hardened Images

Features

• Command Line Interface
• IDE Extensions
• Container Runtime
• Docker Extensions
• Trusted Open Source Content
• Secure Software Supply Chain

Developers

• Documentation
• Getting Started
• Trainings
• Extensions SDK
• Community
• Open Source
• Preview Program
• Newsletter

Pricing

• Personal
• Pro
• Team
• Business
• Premium Support and TAM
• Pricing FAQ
• Contact Sales

Company

• About Us
• What is a Container
• Blog
• Why Docker
• Trust
• Customer Success
• Partners
• Events
• Docker System Status
• Newsroom
• Swag Store
• Brand Guidelines
• Trademark Guidelines
• Careers
• Contact Us

Languages

• English
• 日本語

• [](http://twitter.com/docker)
• [](https://www.linkedin.com/company/docker)
• [](https://www.instagram.com/dockerinc/)
• [](http://www.youtube.com/user/dockerrun)
• [](https://www.facebook.com/docker.run)
• [](http://www.docker.com/blog/feed)

© 2026 Docker Inc. All rights reserved

Terms of ServicePrivacyLegal

Cookies Settings

By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts.

Cookies Settings Reject All Accept All Cookies

Privacy Preference Center

When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.

More information

Allow All

Manage Consent Preferences

#### Functional Cookies

• [x] Functional Cookies

These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.

#### Strictly Necessary Cookies

Always Active

These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.

#### Performance Cookies

• [x] Performance Cookies

These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.

#### Targeting Cookies

• [x] Targeting Cookies

These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.

Cookie List

Clear

• [x] checkbox label label

Apply Cancel

Consent Leg.Interest

• [x] checkbox label label

• [x] checkbox label label

• [x] checkbox label label

Reject All Confirm My Choices