Docker Sandboxes vs. Docker containers
The differences
Docker container
Built to ship your application
|
Docker Sandbox
Built to keep an agent off your machine
|
|
|---|---|---|
|
Boundary |
Namespaces and cgroups, inside the shared kernel |
The hypervisor. A hardware boundary per sandbox |
|
Kernel |
One, shared by every container on the machine |
One per sandbox, dedicated to that session |
|
An escape targets |
The kernel your other work runs on |
The hypervisor your OS already hardens |
|
Docker inside |
Docker-in-Docker or a mounted host socket. Both need elevated privileges |
A private daemon inside the microVM. No socket mount, no host privileges |
|
Agent build commands |
|
|
|
Who sets the limits |
Your Dockerfile and run flags |
Files, network and secrets, defined before the agent starts |
|
Credentials |
Environment variables and mounts inside the container |
Injected into network requests as it leaves the boundary |
|
Lifetime |
As long as the service runs |
One agent session. Delete it and start fresh |
|
Install |
Docker Desktop on macOS and Windows. Docker Engine on Linux |
One command, standalone. No Docker Desktop license
|
Why the two get confused
Docker has meant containers for more than a decade. A new product with Docker on the front reads, reasonably, as a container with a new name. Sandboxes share a vendor and a workflow with containers. They do not share a boundary.
Where the boundary sits
|
macOS |
Apple Hypervisor.framework, called directly |
|
Windows |
Windows Hypervisor Platform, called directly. No compatibility layer. |
|
Linux |
KVM, the same boundary a server workload gets |
Inside a sandbox
The diagram above shows where the boundary sits. This shows what sits inside it. Drag to rotate, open it up, and select a layer to read what it does.
What a container cannot give an agent
An agent writes code, runs it, and installs what it wants, while you are not watching. Three things follow.
The kernel is the shared part
An escape targets a kernel. In a container, that kernel is yours, and every container on the machine shares it.
Docker-in-Docker undoes the boundary
Agents build images and run compose files. In a container that means Docker-in-Docker, and its elevated privileges reach the host you were isolating.
A prompt is not a boundary
Tell an agent to avoid a directory and you have a request. Deny in the prompt and it reaches for the API instead.
What Sandboxes do not change
Nothing here changes how you package software
Your service still builds and deploys as a container, and it should. Sandboxes hold agent sessions on a developer machine.
A sandbox boots a kernel, so it holds more memory than a container
You run one per agent session, not one per service. Size it for the session, not for the fleet.
Central policy needs the enterprise deployment
On your own machine you set the boundary per sandbox. Policy enforced across an organization comes with enterprise deployment.
Common questions
Is a Docker Sandbox just a container?
No. A container is a process isolated by namespaces and cgroups in the kernel it shares with the machine. A sandbox is a microVM, a virtual machine stripped to what one workload needs, with a kernel of its own. No flag on docker run produces a second kernel.
Do Docker Sandboxes share the host kernel?
No. Each sandbox boots its own kernel. The host kernel sits on the other side of a hardware boundary, and so does every other sandbox.
Can an agent escape a Docker Sandbox?
An escape would have to cross the hypervisor rather than the kernel, which is the boundary a virtual machine gives you. Files, network and secrets are set before the session starts, so nothing the agent decides can widen them.
On macOS my containers already run in a Linux VM. Is that the same thing?
No. That is one Linux VM with one kernel, shared by every container on the machine, and Docker-in-Docker inside it still needs elevated privileges. A sandbox is one microVM per agent session, on Apple’s Hypervisor.framework directly.
Can my agent run docker build and docker compose?
Yes. Each sandbox has a private Docker daemon inside the microVM, so build and compose work without a host socket mount and without host privileges.
Are sandboxes slower to start than containers?
A sandbox boots a kernel, so it does more work at start than a container does. The VMM calls each platform’s hypervisor directly, with no translation layer to pay for.
Do I need Docker Desktop?
No. Sandboxes install standalone, with no Docker Desktop license. They work with Claude Code, Codex, OpenCode, GitHub Copilot, Gemini CLI, Kiro and Docker Agent.
Should my team use containers or sandboxes?
Both, for different jobs. Containers build, ship and run the software your team writes. Sandboxes keep the agent that writes it away from your files and credentials.