The Questions Every Team Asks About Docker Sandboxes
Docker Sandboxes launched in March 2026. Since then, I’ve heard the same questions at meetups, on Slack, and during Docker Captain briefings. Instead of writing another overview piece, I want to answer the specific concerns developers keep raising.
Why MicroVMs? Why Aren’t Containers Enough?
This is the most common question, and it’s a fair one. Containers have been the default isolation boundary for a decade. They work well for running trusted application code on shared infrastructure.
The problem is that AI coding agents are not trusted application code. When you run Claude Code or Codex in autonomous mode, the agent performs several tasks. It installs packages, executes scripts, and modifies files. It even spins up its own containers. It makes decisions you didn’t approve in advance. Containers use Linux namespaces and cgroups to isolate processes. But all containers on your machine share the same kernel. A kernel vulnerability affects every container on that host.
MicroVMs give each sandbox its own dedicated kernel. The agent gets root inside its own world. It can do whatever it wants, and your host doesn’t know or care. Destroy the sandbox, start fresh. That’s a fundamentally different security boundary than what containers provide.
Why Did Docker Build Their Own VMM Instead of Using Firecracker?
I hear this at almost every technical discussion. Firecracker is battle-tested technology from AWS. It runs Lambda and Fargate. Why reinvent the wheel?
The answer is straightforward: Firecracker only targets Linux deployment environments. Docker needed sandbox isolation for macOS and Windows. That’s where developers write code. Building their own VMM gave Docker control over the cross-platform experience. Cold starts are quick, so there’s no real reason to skip isolation. Plus, you get complete Docker support in the sandbox.
How Do I Customize a Sandbox?
This question drove the launch of Sandbox Kits. Before kits, customizing a sandbox was tough. You had to install tools manually each time you set one up. Or, you had to build custom template images using Dockerfiles.
Kits are YAML artifacts that package a set of capabilities for a sandbox.
A single spec.yaml can:
- Declare tools to install
- Set environment variables
- Inject credentials
- Allow network domains
- Drop in files
- Run startup commands
You apply a kit with a –kit flag when creating a sandbox, and you can distribute kits as local directories, ZIP files, OCI artifacts, or Git URLs.
The community repo at github.com/docker/sbx-kits-contrib already has working examples. The code-server kit sets up a browser-based IDE in the sandbox. It connects to Claude, helping those who haven’t tried it understand the concept better.
If you’ve written Dockerfiles or Compose files before, the mental model is similar. Kits are to agent environments what Dockerfiles are to application environments. They offer a clear, shareable, and versioned way to define their contents.
What Happens to My Credentials?
This is the question that gets the best reaction when answered. Credentials never enter the sandbox. The host-side proxy intercepts outbound requests and injects API keys on the way out. The agent works with a placeholder value. The real secret stays on the host and gets substituted at the proxy layer.
This means that even if the sandbox is fully compromised, there are no secrets inside to exfiltrate. For teams in regulated industries, where audits check credential management, this design choice is very important. It’s not just “the agent runs in a box.” It’s “the agent runs in a box that has no keys.”
Does This Require Docker Desktop?
No. The sbx CLI is a standalone binary. You install it with brew install docker/tap/sbx on Mac or winget install Docker.sbx on Windows. You sign in with a Docker account and you’re running. It is not tied to Docker Desktop licensing.
This is important because many enterprise teams face challenges with Docker Desktop licensing. Sandboxes sidestep that conversation entirely.
What About Port Publishing and Other Gaps?
Being honest here: automatic port publishing isn’t available yet. User-configurable parameters for kits are on the roadmap. The kit format itself is labeled experimental, and Docker says the spec may change as the feature evolves.
That said, Docker has shipped multiple sbx releases in the past few weeks and the pace of iteration has been fast. If you’re evaluating this for your team, the core isolation and credential management work today. The rough edges are in the customization and distribution layer.
Where Does This Leave Containers?
Containers aren’t going anywhere. They remain the top choice for running your application workloads, CI pipelines, and development environments. What’s changing is that a new category of workload has emerged: untrusted, autonomous code execution by AI agents. Containers weren’t designed for that threat model. MicroVMs were.
Think of it less as containers versus microVMs and more as the right isolation boundary for the right workload. Containers for your apps. Sandboxes for your agents.
