Docker has launched Cloud Sandboxes, moving its microVM-based environment for coding agents from the developer laptop to Docker-managed cloud compute. The product is aimed at a problem that becomes more important as coding agents run for hours rather than minutes: where does the work continue when the laptop sleeps, disconnects, or simply cannot host dozens of concurrent jobs?
The company says Cloud Sandboxes use the same sandbox abstraction as its local product, with the same CLI and a microVM isolation model. A developer can start locally, then move the sandbox to Docker's cloud with sbx move; Docker says the move captures the sandbox filesystem and recreates the environment on the other side. The company also positions the service for parallel workloads, with each cloud sandbox receiving its own compute environment, secrets and network policy.
A sandbox now has a cloud destination
The most important change is not another coding-agent interface. It is the separation of an agent's working environment from the developer's physical machine.
Docker's existing Sandboxes product places an agent inside a microVM with its own Linux kernel and Docker daemon. Cloud Sandboxes extends that operating model to hosted compute. Docker says a developer can start a task locally, move it to the cloud, disconnect, and later review the result. The move is bidirectional, so cloud work can also be brought back to a local sandbox.
That creates a more continuous execution model. A long refactor, migration, test loop or other multi-hour job no longer has to stay attached to the machine where it began. For teams experimenting with several agents at once, Docker also removes part of the provisioning problem: the launch material explicitly describes running many isolated tasks in parallel without setting up separate infrastructure first.
Long-running agents make infrastructure part of agent design
This matters because the limiting factor for an agent is increasingly not only the model. Once an agent can work for five, ten or twenty hours, infrastructure choices become part of the workflow.
A laptop is a poor long-duration worker: it sleeps, changes networks, runs on battery and competes with interactive work. A managed sandbox can remain available while the human is offline. But moving execution into the cloud also changes the operational boundary. Teams now have to think about the lifetime of the sandbox, what credentials are available inside it, which networks it can reach, how state is moved, and who is responsible for shutting the environment down.
The Aipolix conclusion is that long-horizon agents turn sandbox orchestration into an infrastructure problem. Model quality still matters, but so do environment lifecycle, isolation, policy and cost. Cloud Sandboxes is significant because Docker is packaging those concerns behind the same tool developers already use for local agent isolation.
Isolation matters more when nobody is watching
Docker says each sandbox runs in a microVM with its own kernel, rather than sharing the host kernel like a normal container. Its security documentation describes multiple isolation layers around process, filesystem, networking and credentials. The agent has broad control inside its sandbox, but the VM boundary is intended to keep that authority away from host resources that were not explicitly shared.
For cloud use, the practical point is that unattended execution needs more than a separate machine. Agents still require network access and credentials to do useful work. Docker says Cloud Sandboxes can apply per-sandbox network policy and can proxy-inject stored secrets so the agent does not directly receive the underlying secret value.
Those are useful controls, but they should not be read as proof that arbitrary agent workloads are automatically safe. The claims are Docker's own, and the launch does not provide independent comparative security testing. Organizations still need to decide which repositories, secrets, MCP servers and external services an agent is allowed to reach.
Pricing makes the infrastructure trade-off visible
Docker is pricing Cloud Sandboxes as metered compute. Its launch post lists sizes from one vCPU and 2 GiB of memory at $0.07 per hour to 16 vCPUs and 32 GiB at $1.12 per hour. Docker says compute is metered by the second, paused sandboxes cost nothing, and volumes and egress are not separately charged under the launch pricing.
That gives teams a direct way to compare background-agent execution with keeping their own development or CI infrastructure available. A two-vCPU sandbox is listed at $0.14 per hour, so a ten-hour agent task would have a compute price of about $1.40 before model inference costs. Docker allows customers to bring their own model key, so inference remains a separate cost controlled by the selected model provider.
The launch documentation also says a cloud sandbox can run for up to 24 hours per session. That is long enough for many background coding tasks, but it is still a lifecycle boundary that agent workflows need to handle explicitly.
The abstraction is stronger than the first governance layer
Cloud Sandboxes makes local-to-cloud execution simpler, but the first release does not eliminate governance work. Docker's launch material says broader centralized enterprise governance is part of the direction of the product rather than a reason to assume every organizational control already exists in the initial service.
That distinction is important. Individual sandbox isolation, network policy and secret handling are execution controls. Enterprise governance adds different questions: who can create cloud sandboxes, which kits and agents are approved, what policies are mandatory, how usage is audited, and what happens when different teams need different access boundaries.
Cloud Sandboxes is therefore best understood as infrastructure for agent execution, not a complete agent-governance system. Its importance is that the execution layer is becoming portable: the same agent workspace can move from a developer machine to managed cloud compute while preserving the sandbox model.
For teams building long-running coding agents, that changes the design question. The choice is no longer simply which model or coding agent to use. It is also where the agent runs, how its authority is constrained, what state follows it, and how much unattended execution costs.