Docker Cloud Sandboxes: Agent Pricing, MicroVM Isolation and OCI Kits

By AiCybr Editorial · Published September 25, 2026

Docker released Cloud Sandboxes on September 24, 2026, extending its coding-agent sandbox runtime from developer machines to Docker-managed cloud compute. The service uses the same microVM isolation model and sbx command-line interface as local Docker Sandboxes, supports moving a sandbox between local and cloud execution, and starts at $0.07 per compute hour.

The accompanying Sandbox Kit Specification v3 packages an agent, tools and requested access to resources such as networks, credentials and volumes as an OCI image. Docker published the specification under Apache 2.0 and said it is bringing the work to the Cloud Native Computing Foundation for neutral governance.

For developers already using Claude Code, Codex, Copilot or another coding agent, the practical change is that long-running jobs can continue after a laptop disconnects while retaining a defined sandbox boundary, network policy and secret-delivery mechanism.

Cloud Sandbox pricing and limits

Docker meters Cloud Sandbox compute by the second. Paused sandboxes have no compute charge, while Docker says volumes, egress, and hosting public images and Kits are free. Model inference is separate: users can bring their existing model-provider key.

Size	vCPUs	Memory	Published price per hour
Micro	1	2 GiB	$0.07
Small	2	4 GiB	$0.14
Medium	4	8 GiB	$0.28
Large	8	16 GiB	$0.56
XL	16	32 GiB	$1.12

A sandbox runs for one hour by default and can run for up to 24 hours per session. Docker's launch documentation requires sbx 0.45.1 or later for Cloud Sandboxes and says the pay-as-you-go plan is available to Docker Personal and Pro accounts.

At the published rates, a continuously active 24-hour job costs about $1.68 on Micro, $3.36 on Small, $6.72 on Medium, $13.44 on Large or $26.88 on XL, before model-provider charges. Those are simple rate calculations from Docker's hourly prices, not bundled job prices.

What runs inside a Docker Sandbox

Docker Sandboxes use a dedicated microVM for each sandbox. Each environment receives its own kernel and an isolated Docker daemon, allowing an agent to build images, run containers and use Docker Compose without exposing the host Docker socket.

Cloud Sandboxes carry that model onto Docker-managed infrastructure. Docker says the CLI, isolation model and policy behavior remain consistent between local and cloud execution. The underlying compute location changes; the agent workflow does not need a separate cloud-specific harness.

A developer can start locally and move the filesystem state to cloud execution with:

sbx move my-project --to cloud

Docker documents the move as bidirectional: the sandbox filesystem is captured and recreated at the destination, allowing work to move from local to cloud and back.

Agents available through Kits

Docker's launch material lists ready-to-run Kits for Claude Code, Codex, Copilot, Antigravity, Open Code and Hermes. Custom Kits can package other workloads.

For a cloud run, Docker's documented flow is:

brew install docker/tap/sbx
sbx login
sbx --cloud run codex

The service can also be managed through Docker's web console.

Secrets, MCP and network policy

Long-running agents usually need more than CPU and a checkout. Docker's cloud design includes three controls that materially affect unattended execution.

Secrets are stored outside the agent environment and proxy-injected per request. Docker says the agent does not receive the underlying secret value, reducing direct credential exposure to agent context and prompt-injection paths.

MCP access can be configured through a gateway for services and tools such as Jira, Linear, Grafana and other streamable HTTP endpoints. The same configured MCP services can then be reached from supported local and cloud sandbox workflows.

Network policies define which endpoints a sandbox may access. Docker says centralized enterprise governance for these policies is planned through Docker AI Governance.

These controls complement the microVM boundary: the VM limits access to the host and neighboring environments, while network and credential policies define which external resources an agent can legitimately reach.

Sandbox Kit Specification v3

The second part of Docker's September release addresses reproducibility of agent authority. A v3 Kit is an ordinary OCI image containing the workload plus a typed description of requested capabilities.

Docker describes three core elements carried by a Kit:

the agent or workload;
the tools it needs;
its requested access to hosts, credentials and volumes.

Using OCI means a Kit can use existing image workflows for building, pushing, pulling, signing and scanning. Pinning an image also pins the declared requests associated with that version, giving reviewers a versioned artifact whose authority changes can be inspected alongside workload changes.

Docker Sandboxes release 0.45.0, published September 21, introduced support for v3 Kits and reusable mixins. Docker's release notes state that v3 workloads and v3 mixins must be used together; they cannot be combined with v1 or v2 Kits. Existing built-in agents and customizations using v2 remain supported.

Open specification and CNCF path

Docker published the Sandbox Kit Specification as open source under Apache 2.0. The company says it is bringing the specification to the Cloud Native Computing Foundation (CNCF) for neutral governance.

The specification uses OCI extension mechanisms instead of defining a separate image format. That lets registries and existing image security tooling process Kit artifacts using familiar container-image infrastructure.

Docker also lists ecosystem work with AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, Snyk and others on Kits for agent tooling and services.

Where Cloud Sandboxes fit

Cloud Sandboxes are most directly useful when an agent job outlives an interactive development session: large refactors, dependency migrations, long test suites, parallel issue queues or overnight tasks. The launch service can also create many isolated sandboxes without a team provisioning the underlying machines itself.

The pricing model makes workload duration and parallelism the main compute-cost variables. A developer who needs only short local sessions can continue using local Docker Sandboxes; a team handing off multi-hour jobs can move those environments to managed compute without changing the basic sbx workflow.

Model cost remains an independent budget item because Cloud Sandbox pricing covers the execution environment, not inference. Workloads that make large numbers of model calls can therefore spend substantially more on the model provider than on the sandbox itself.

Deployment checklist

For an existing Docker Sandboxes user evaluating the cloud service:

update sbx to 0.45.1 or later for the documented Cloud Sandboxes workflow;
choose the smallest CPU/RAM tier that reliably runs the repository's build and test workload;
keep model-provider cost separate from sandbox compute when estimating job cost;
define outbound network access and credentials before allowing unattended execution;
use a Kit when the agent, tools and requested authority should be versioned and reviewed as one artifact;
review v3 compatibility before combining older Kit customizations with v3 workloads.

The release gives Docker a single local-to-cloud execution model for coding agents while the Kit specification addresses a separate operational problem: making an agent's requested authority portable, versioned and inspectable.