What Docker Cloud Sandboxes mean for builders running AI agents

What Docker Cloud Sandboxes mean for builders running AI agents

On September 24, 2026, Docker announced Cloud Sandboxes at WeAreDevelopers North America. The short version: the same microVM sandbox Docker already offered for running AI coding agents on your laptop now also runs on Docker-managed cloud compute, and you can move a sandbox between the two with one command.

That sounds like a small product extension. It is actually a useful signal about where agent tooling is heading. Agents are no longer only answering questions in a chat window. They are running refactors, dependency migrations, and test loops that take hours. The questions have shifted from "can the model do this?" to "where does this work run, and what is it allowed to touch?"

This post is a builder-focused read of the launch: what shipped, how it works, and what small teams should take away from it.

What Docker announced

According to Docker's launch blog, press release, and documentation:

• Cloud Sandboxes run AI agents in microVMs on Docker-managed infrastructure instead of your own machine.
• Same isolation model as local sandboxes. Each agent gets its own microVM with its own kernel and Docker daemon, separate from the host.
• Same CLI. Cloud sandboxes use the existing sbx CLI. Adding the global --cloud flag sends supported commands to the Cloud Sandboxes API, for example sbx --cloud run claude.
• Move between laptop and cloud. sbx move my-project --to cloud captures the sandbox filesystem and recreates it on the other side. Docker says this works in both directions.
• Kits. Pre-built sandboxes for popular coding agents, including Claude Code, Codex, Copilot, Antigravity, Open Code, and Hermes, or your own.
• Built-in plumbing. Secrets, network policies, agent configuration, and an MCP gateway come included. Docker also says cloud sandboxes boot in the low hundreds of milliseconds.
• Availability. Available now on a pay-as-you-go plan for Docker Personal and Pro accounts. Local Docker Sandboxes remain free and standalone, with no Docker Desktop required.

As reported by The Register, Docker president and COO Mark Cavage described the launch on stage as "a simple, flexible set of compute shapes with simple low, low pricing."

How it works

The core idea is one sandbox that can live in two places.

Locally, a Docker Sandbox is a microVM on your machine. The agent can install packages, run containers, and execute code, but it does so inside its own kernel boundary rather than directly on your host. If the agent does something it should not, such as trying to reach the Docker socket or mount host paths, the microVM boundary is meant to stop it. In Docker's keynote demo, as described by The Register, an agent found a Docker socket and tried to use it to escape; the isolation held because the sandbox was a full microVM.

In the cloud, the same kind of microVM runs on machines Docker operates. What changes is not the isolation model but the environment around it: the machines are always on, you can run many at once, and your laptop can sleep while the work continues.

A few mechanics worth knowing before you plan around it:

• Secrets are proxied. Docker says you store keys once and the Cloud Sandboxes proxy injects them per request, so the agent never sees the raw secret. That limits what a prompt injection can steal.
• Network policies define which endpoints agents can reach. Docker says centralized governance for enterprises is coming later through Docker AI Governance.
• MCP gateway. Connect MCP servers such as Jira, Linear, or Grafana once and have agents reach them through a single gateway, locally or in the cloud.
• Separate state. The docs are clear that local and cloud sandboxes keep separate secrets, templates, and network policies. A cloud sandbox cannot mount a host workspace or use host hardware, so you clone repositories inside it instead.
• Lifetimes. Cloud sandboxes expire after one hour by default and are deleted when they expire. Sessions can run up to 24 hours. Copy out anything you want to keep.

Pricing

Docker meters compute by the second and says a paused sandbox costs nothing. Volumes, egress, and hosting public images and Kits are listed as free. Model inference is not included; you bring your own model key and pay your provider.

Size	vCPUs	Memory	Per hour
Micro	1	2 GiB	$0.07
Small (default)	2	4 GiB	$0.14
Medium	4	8 GiB	$0.28
Large	8	16 GiB	$0.56
XL	16	32 GiB	$1.12

For a small team, the takeaway is that the sandbox compute is likely to be the cheaper line item. The model tokens an agent burns over a multi-hour task will usually matter more, so budget for both.

Why this matters for builders

Agents are becoming background workers. Docker frames the launch around long-horizon tasks that run for hours. A laptop sleeps, throttles on battery, and drops off the network. That is fine for a 30-second task and a real problem for an overnight migration. Moving long jobs to always-on compute is the obvious next step, and Docker is betting that the isolation boundary should not change when you do.

Isolation is now a baseline expectation. Running an agent with broad access to your machine, your credentials, and your network is a risk that teams are taking more seriously. A microVM with its own kernel is a stronger boundary than a plain container sharing the host kernel. Whether you use Docker's product or not, "what can this agent reach?" should be a design question, not an afterthought.

Portability is the interesting part. The most notable design choice is not the cloud itself but the single model across both environments. Docker says it built one sandbox in two places rather than a separate cloud product, so trust does not depend on where the agent happens to run. For builders, that means you can prototype locally and only pay for cloud compute when the task actually needs it.

Practical takeaways

If you are experimenting with coding agents this quarter:

1. Start local. Local Docker Sandboxes are free. Get your agent workflow, secrets, and network policy right on your own machine first.
2. Move only long or parallel work to the cloud. Interactive iteration belongs close to you. Overnight refactors and parallel test runs are where cloud sandboxes earn their cost.
3. Treat local and cloud config as separate. Secrets, templates, and policies do not carry over automatically. Re-check them before a move.
4. Plan for expiry. Default one-hour lifetimes mean you need a habit of pushing branches or copying out artifacts before a sandbox is deleted.
5. Lock down network access. Give agents an allowlist of endpoints, not the open internet, especially when they hold credentials to business systems.
6. Keep a human review step. Unattended does not mean unreviewed. Have agents open pull requests rather than push to production.

The stack-ownership angle

Cloud Sandboxes are a managed service, and for many teams that is the right call: nothing to provision, per-second billing, and a clean exit when the job ends. But the design also reflects a principle worth keeping in mind as agents start touching real business data.

The value of a sandbox comes from you deciding its boundaries: which files, which networks, which secrets. That only works well when you understand and control the systems the agent is operating on. If your ERP, CRM, or inventory data sits in a closed platform you cannot inspect, you are limited to whatever automation the vendor allows. If you own the software and the source code, you can point an agent at a staging copy, give it a tight policy, and review exactly what it changed.

That is the same instinct behind choosing business software you can deploy yourself. Agents will increasingly do real work inside your systems. The teams that benefit most will be the ones that own those systems well enough to set the rules.