Docker has extended its sandbox offering from a laptop‑only model to a fully managed cloud version, called Cloud Sandboxes. The change lets the same microVM‑based environment be started locally or on Docker‑managed compute with a single command, and agents can be moved between the two without losing state. For AI engineers, platform teams, and security practitioners this means long‑running AI agents can now execute for hours in an isolated, centrally managed environment while preserving the same isolation guarantees they had on their laptop.
What Changed: Unified Local and Cloud Sandboxes
Previously Docker Sandboxes ran only on a developer’s machine, each agent inside a microVM that provided its own kernel and Docker daemon. The new Cloud Sandboxes keep that isolation model but host the microVMs on always‑on compute managed by Docker. The CLI remains the same; the only difference is that the underlying host is a cloud instance that can be provisioned on demand. A command such as sbx move my-project --to cloud captures the sandbox’s filesystem and recreates it in the cloud, and the reverse direction works as well.
Architectural Implications
Each sandbox is a self‑contained microVM with dedicated network policies, secret injection, and optional connectivity to external services via a single MCP gateway. Because the isolation boundary is identical in both locations, trust in the agent does not depend on where it runs. Kits provide pre‑built images for popular coding agents (Claude Code, Codex, Copilot, etc.) and can be extended with custom agents. Secrets are stored once and proxied into the sandbox per request, meaning the agent never sees the raw secret value. Network policies are defined once and applied uniformly, and Docker plans to add centralized governance for enterprises.
Operational Considerations
Cloud Sandboxes are billed per second of compute, with a paused sandbox incurring no cost. Size options range from a 1 vCPU/2 GiB micro instance at $0.07 per hour to a 16 vCPU/32 GiB XL instance at $1.12 per hour. Sessions run for a default of one hour and can extend up to 24 hours. The model enables running dozens or hundreds of agents in parallel without manual provisioning; each receives its own microVM, secrets, and network policy. The CLI commands for cloud usage are identical to local ones, e.g., sbx --cloud run codex, and the web console offers a point‑and‑click alternative. A limited‑time credit of $250 is available for new accounts.
Security Perspective
The microVM isolation isolates the agent’s kernel, Docker daemon, filesystem, and network from the host machine, protecting local files, network interfaces, and stored secrets. Secret injection occurs at the proxy layer, reducing the attack surface for secret leakage. Network policies are enforced per sandbox, limiting outbound connections to explicitly allowed endpoints. Because the same isolation model applies locally and in the cloud, the security posture remains consistent across environments.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Practitioners should evaluate whether their AI‑driven workloads exceed the practical limits of a laptop (e.g., multi‑hour test suites or large refactors). If so, adopting Cloud Sandboxes provides a seamless migration path with identical tooling and isolation guarantees. Key actions include: defining appropriate network policies for the services agents need, configuring secret injection once and reusing it across environments, selecting a sandbox size that matches the workload’s compute profile, and incorporating the sbx move workflow into CI/CD pipelines to hand off long‑running tasks. Monitoring compute usage and session duration will help control costs, while the upcoming Docker AI Governance feature can be used to enforce enterprise‑wide policy compliance.
