Docker Cloud Sandboxes Architecture Diagram: Local MicroVM to Cloud Agent Isolation

On September 24, 2026, Docker introduced Cloud Sandboxes: the same microVM isolation as Docker Sandboxes, on Docker-managed compute, with one CLI move between a laptop and that cloud. This Docker Cloud Sandboxes architecture diagram is a news diagram of that launch, not a benchmark and not a scale claim. It shows the Laptop CLI, the microVM pool, Kits, MCP, a secrets proxy, network policies, and a filesystem move. The cloud side is labeled Cloud Sandboxes control plane. That name is this diagram’s label for the Docker-managed cloud side, not an official component in the two Docker sources. Facts follow only the launch post and the same-day press release.

What this Docker Cloud Sandboxes architecture diagram shows

Two places share one isolation model. On the left is the Laptop CLI. Local Docker Sandboxes stay free, standalone, and do not require Docker Desktop. On the right, the Cloud Sandboxes control plane is this diagram’s label for the Docker-managed cloud side, where the same microVM runs. It is not a component name in the launch post or the press release. Between them, a filesystem move. Docker’s command is sbx move my-project --to cloud. A move captures the sandbox filesystem and recreates it on the other side, in both directions. With the sandbox, the art shows Kits, MCP, a secrets proxy, and network policies. The diagram is the September 24, 2026 announcement.

The problem this architecture is solving

Earlier Docker Sandboxes answered whether an agent could run unattended: a microVM with its own kernel and Docker daemon, isolated from the developer machine. The September post says the newer question is where the hours happen. Long-horizon work does not fit a laptop that sleeps or disconnects. Cloud Sandboxes is always-on Docker-managed capacity you do not provision yourself. Interactive work stays local. Docker’s claim is that trust should not depend on where the agent runs.

Main components and trust boundaries

The trust boundary is the microVM, not a container shared with the host. The press release says containers still matter but were not designed for the isolation agents demand, which is why local sandboxes were a separate product and Cloud Sandboxes extends that isolation. Each task gets its own microVM, secrets, and network policy. Parallelism is a product claim, not a published capacity test.

Kits package the agent, its tools, and access rules as one OCI image. Rules travel inside the Kit, and mixins let teams reuse standard parts. Docker has committed to submit the Kits spec to the CNCF; the release does not say the CNCF has accepted it. Named ready kits include Claude Code, Codex, Copilot, Antigravity, Open Code, and Hermes. MCP servers (Jira, Linear, Grafana, incident.io, or any streamable HTTP endpoint) connect once and are reached through one gateway from cloud, local, or a client such as the ChatGPT desktop app. The secrets proxy injects a stored key per request so the agent never sees the value. Network policy limits endpoints. Docker AI Governance is coming soon, so it stays off the shipped path. Local and cloud keep separate secrets, templates, and network policies; a filesystem move does not merge those stores.

Request or data path, step by step

The terminal path is brew install docker/tap/sbx, sbx login, then sbx --cloud run claude. You need sbx 0.45.1 or later and pay-as-you-go on a Docker Personal or Pro account. In the browser, sign in, choose a kit, and click Run. The press release says secrets, policy, MCP gateways, and agent configuration are already in the environment. Its line that sandboxes “boot up in low hundreds of milliseconds” has no percentile or method.

The agent then runs in the microVM: own kernel and Docker daemon, Kit tools, MCP through the gateway, secrets per request, egress limited by policy. sbx move captures the filesystem either way. The launch post meters compute-seconds only. A paused sandbox costs nothing. Volumes, egress, and hosting public images and Kits are free, and you can bring your own model key. Sessions default to one hour and cap at 24 hours. Regions, GPUs, and discounts are not described.

The diagram: labeled boxes and failure or isolation edges

Boxes on the diagram: Laptop CLI, Cloud Sandboxes control plane, microVM pool, Kits, MCP, secrets proxy, network policies, and the filesystem move. Cloud Sandboxes control plane is the diagram’s label for the Docker-managed cloud side, not a name the two Docker sources give that side. The filesystem move captures the sandbox filesystem in both directions. The isolation edge is the microVM pool: each microVM has its own kernel and daemon. The laptop can sleep while the cloud microVM continues. The agent does not hold raw secrets. Egress stops at the network policies.

What the source does not claim

Both documents are a September 24, 2026 announcement (WeAreDevelopers North America), not a case study and not an evergreen spec. The press release says Cloud Sandboxes are available now, and Kits are on Docker Hub and GitHub. It does not publish a boot-time distribution behind “low hundreds of milliseconds,” a method for the parallelism claim, or an error budget. CNCF language is a submit commitment. Enterprise governance is coming soon. Local sandboxes remain a separate free path. The session cap is stated; behavior past that cap is not.

FAQ

Is Cloud Sandboxes a different isolation model from local Docker Sandboxes?

No. The September 24, 2026 launch post says Cloud Sandboxes is the same microVM on Docker-managed compute, with the same CLI. The press release says the same sandbox and the same policies locally or in Docker’s cloud. Local and cloud still keep separate secrets, templates, and network policies.

What does sbx move copy between a laptop and Cloud Sandboxes?

The launch post says a move captures the sandbox filesystem and recreates it on the other side, both directions. The command is sbx move my-project --to cloud. It does not say the move merges secrets, templates, or network policies. Those stores stay separate.

How do Kits, the secrets proxy, and network policy limit an agent?

Kits package the agent, its tools, and access rules as an OCI image. The secrets proxy injects a stored key per request so the agent does not see the secret. Network policies limit endpoints. Docker AI Governance is described as coming soon, not as a shipped enterprise control.

Conclusion

The September 24, 2026 launch, as published, is a Laptop CLI, a Docker-managed cloud side the diagram labels Cloud Sandboxes control plane, a microVM pool whose microVMs keep their own kernel and Docker daemon, Kits, MCP, a secrets proxy, network policies, and a filesystem move both ways that does not merge policy stores. The boot-time line and the parallelism claim stay hedged. The launch post and the press release are the sources. More diagrams are on the ByteDiagram blog.