Docker announced Cloud Sandboxes on September 24, 2026, giving developers a way to start an AI-agent task locally and continue it on Docker-managed infrastructure. The workflow is aimed at jobs that need to keep running after a developer disconnects, or that should execute away from a local workstation.
The feature is not a general-purpose replacement for local development. Current Docker documentation describes cloud sandbox support and the Docker Agentic Platform as experimental. Cloud execution also uses a separate environment with its own credentials, network policy, storage, lifecycle, and quotas. Developers should therefore treat a local-to-cloud handoff as a controlled filesystem transfer, not as live migration.
What changed
Cloud Sandboxes run agents through Docker’s sbx command-line interface. The launch announcement describes support for agent workflows, kits, MCP connectivity, proxy-mediated secrets, network policies, and microVM-based isolation. The current documentation confirms that cloud sandboxes run on Docker-managed infrastructure, while also warning that the CLI support is experimental and subject to change.
Cloud access currently requires sbx version 0.45.0 or later, Docker account sign-in, cloud-access activation, and an active Docker Agentic Platform pay-as-you-go subscription. The launch announcement separately specifies sbx 0.45.1 or later for its workflow examples. Docker’s current signup documentation says the Agentic Platform has no recurring subscription fee: compute is metered by runtime, CPU, and memory, while model-provider inference is billed separately. The Agentic Platform subscription is attached to a personal Docker account and billed separately from a Docker subscription.
This terminology is worth noting because the announcement refers to Docker Personal and Pro accounts, while current documentation describes Agentic Platform activation as the requirement for cloud access. The supplied documentation does not establish that those descriptions are interchangeable.
How local-to-cloud handoff works
The documented workflow includes sbx login, sbx --cloud diagnose, cloud-specific secret configuration, and cloud commands such as sbx --cloud create, sbx --cloud attach, sbx --cloud cp, and sbx --cloud rm. The global --cloud flag selects the cloud resource store, which is separate from the local one.
A move creates a filesystem snapshot, transfers that snapshot across the local/cloud boundary, and creates an independent destination sandbox. The source remains in place. Running processes, memory, open sockets, workspace mounts, bind mounts, clone-mode volumes, attached external resources, and managed secrets are not transferred. A move therefore cannot preserve the exact live execution state of an agent.
Files containing credentials require particular care. Managed secrets are not copied by a move, but credentials written as ordinary files inside the sandbox filesystem are part of the snapshot unless they are removed beforehand. Local network rules also do not carry over. After a local-to-cloud move, the cloud network policy applies, and eligible TCP ports may be exposed through cloud URLs.
The reverse direction has similar boundaries. A cloud-to-local move uses the local runtime’s defaults. Cloud network rules, cloud URLs, attached cloud volumes, and environment variables do not transfer back to the local runtime. Moves preserve CPU architecture, and the source platform must remain compatible with the destination.
Cloud resources are separate from local resources
Cloud sandboxes cannot mount a host workspace or use host hardware. That means a cloud agent cannot rely on local GPU, USB, display, nested virtualization, or other workstation resources. Files needed by the task must be cloned or transferred into the cloud sandbox rather than supplied through a local workspace path.
Cloud and local sandboxes also have separate stores for secrets, templates, volumes, sandbox instances, and network policies. A successful move can therefore leave important setup behind. Administrators should configure only the cloud credentials, MCP integrations, network access, and storage required for the task, then inspect the destination before deleting the original.
The launch material describes microVM isolation, but that should not be treated as a formal guarantee that removes all risks associated with autonomous agents. The practical security boundary still depends on the files, credentials, network access, ports, and policies configured for each destination sandbox.
Compute sizes, quotas, and expiration
Docker’s current limits documentation maps the named cloud sizes to the following resources:
- micro: 1 CPU and 2 GiB of memory
- small: 2 CPUs and 4 GiB of memory
- medium: 4 CPUs and 8 GiB of memory
- large: 8 CPUs and 16 GiB of memory
- xl: 16 CPUs and 32 GiB of memory
The documented default account quotas are 10 concurrent sandboxes, 50 stored sandboxes, 100 volumes, 100 secrets, and three images being prepared simultaneously. Docker notes that individual accounts may have different quotas, so teams should confirm their actual limits rather than assume that these defaults are guaranteed.
Cloud sandboxes expire after one hour by default. Depending on configuration and support, expiration can stop a sandbox for later resumption or delete it. Expiration settings can be configured for cloud moves and inspected or extended afterward. Any unattended job that may run longer than the default lifetime needs an explicit timeout and retention plan.
Who benefits from the workflow?
The most direct use case is local iteration followed by remote execution. A developer can prepare a repository and agent locally, transfer the filesystem state to the cloud, and then disconnect while the cloud agent continues working. This is useful for long-running tasks, but it is not equivalent to leaving the local process running on another machine.
Teams managing untrusted or autonomous coding-agent tasks may also value the separation between the host environment and the cloud sandbox. However, the cloud destination must be configured independently, and the experimental status means operators should avoid treating the service as a stable, capacity-guaranteed production platform. Cloud and local performance should not be assumed to match because their resource sizes and available capabilities differ.
What you should do
- Install the current documented
sbxrelease, using version 0.45.0 or later. For the launch workflow, Docker specifies 0.45.1 or later. - Activate an Agentic Platform pay-as-you-go subscription and sign in to the same Docker account with
sbx login. - Run
sbx --cloud diagnosebefore attempting a cloud workload. - Configure cloud credentials separately from local credentials, and avoid placing sensitive credentials in ordinary files that may be included in a filesystem snapshot.
- Review the files, ports, network policy, volumes, architecture, resource size, and expiration behavior after every move.
- Set an appropriate TTL and timeout action for work that must survive beyond the default one-hour expiration.
- Plan concurrency around the documented quota of 10 cloud sandboxes unless the account’s actual quota is known to differ.
Availability and open questions
Cloud Sandboxes are available through Docker-managed infrastructure and the sbx CLI, with the launch material also describing web-console access. Current Docker documentation labels the CLI support and Agentic Platform experimental. The supplied documentation does not establish geographic availability, data-residency options, or capacity guarantees.
The announcement mentions a $250 promotional credit, but the supplied sources do not document its eligibility, expiration, redemption process, or usage restrictions. Developers should not assume that the credit applies to their account until Docker provides those terms.
For now, Cloud Sandboxes are best understood as an experimental remote execution path for agent workloads, with explicit boundaries around state transfer and resource configuration. The workflow can extend local development into the cloud, but it requires destination-side setup and operational checks rather than a simple continuation of the local machine.
