Docker Cloud Sandboxes move long-horizon agent work from the laptop to the cloud with one command

September 24, 2026. Docker ships Cloud Sandboxes, an extension of the Sandboxes it launched earlier in the year. Timir Karia and Srini Sekaran, who signed the announcement, distill the inflection point into one sentence: coding agents have moved from tasks that last seconds to tasks that last hours. Why it matters: the question used to be “can the model hold the task together?” Now it is “where do those hours happen?” — and a laptop was never built to answer that.

The problem: agents that outlast your computer

The biggest change of the past twelve months is not model quality, it is autonomy. A heavy refactor, a dependency migration, a test suite that takes an hour to run: these are now tasks you hand off to an agent and review when they finish, instead of supervising every five minutes.

That shift from short to long changes the nature of the constraint. A laptop is built around a person. It sleeps when the lid closes, it throttles on battery, it disconnects when you move. None of that matters for a thirty-second task. All of it matters for a task that runs overnight.

Docker had already answered the first question — “is it safe to run an agent unattended?” — with Sandboxes: microVM environments with their own kernel and their own Docker daemon, isolated from the host machine. Cloud Sandboxes answers the second: how do you run a dozen agents at once, for five, ten, or twenty-one hours each, without watching any of them?

Cloud Sandboxes: the same microVM, somewhere else

The architecture decision is the heart of the announcement. Cloud Sandboxes is not a separate product with its own commands: it is the same microVM, running on Docker-managed compute. The isolation model is identical. The CLI is identical. What changes is that the machines underneath are always on, and there are as many of them as you need.

The practical consequence is a single command. To move an in-progress project from the laptop to the cloud:

sbx move my-project --to cloud

The move captures the sandbox’s filesystem and recreates it on the other side, in both directions. You iterate with an agent on the code in front of you, then hand long tasks and loops to a background agent and close the laptop.

Docker is explicit that these are not two tiers of one product. Interactive work belongs on the laptop; work that takes hours belongs in the cloud. Most developers need both, and now they do not have to pick. How much you trust an agent should not depend on where it happens to be running.

What an autonomous agent needs

An agent doing long-horizon work without a human needs three things: a way to start with nothing to install, tools to do its job, and limits on what it can reach. Cloud Sandboxes ships all three.

Kits. A kit is a pre-configured, pre-built sandbox for an agent. The leading coding agents are ready today — Claude Code, Codex, Copilot, Antigravity, Open Code, and Hermes — and you can add your own. Starting one is a single line, such as sbx --cloud run codex.

MCP. The MCP servers your agents need — Jira, Linear, Grafana, incident.io, or any streamable HTTP endpoint — are connected once, and every agent reaches them through a single gateway, whether it runs in the cloud, locally, or in other clients.

Secrets. Keys and tokens are stored once. The Cloud Sandboxes proxy injects them per request, so agents never see the actual secret. A prompt injection cannot touch a secret the agent never possessed.

Policies. Network rules define which endpoints agents can reach, once. Centralized governance for enterprises arrives later through Docker AI Governance.

Metered to the second

Cloud Sandboxes is pay-as-you-go, metered by the second and nothing else. A paused sandbox costs nothing, and volumes, egress, and hosting public images and kits are free. You can bring your own model key and keep your existing inference provider.

Sandboxes run for one hour by default and up to 24 hours per session. On the terminal, installation is brew install docker/tap/sbx; in the browser, you pick a kit in the web console and click Run.

Why now, and not before

The timing is no accident. Docker shipped Sandboxes earlier this year to answer a safety question: can an agent run unattended inside a microVM isolated from the machine? The Cloud Sandboxes question is different, and newer: can an agent run for twenty-one hours with no local machine switched on at all?

Both questions trace back to the same shift. Coding agents have become reliable enough to be trusted with background work — refactors, migrations, test generation — that outlasts a working session. At that point, the local infrastructure becomes the limiting factor, not the model. Cloud Sandboxes is Docker’s answer to that moving bottleneck: the same isolation contract, on machines that never sleep.

The other half of the timing is MCP. The adoption of the Model Context Protocol standardized how agents attach to their tools — Jira, Linear, Grafana — and that standardization is exactly what makes a single gateway viable. Without it, every agent would demand its own integration, and a cloud sandbox would lose much of its operational value.

One consequence of metering by the second is that experimentation becomes cheap. You can rent a Small sandbox for an hour, point a pre-built agent at a real task, and stop the meter once you have seen enough. That shifts how teams evaluate agents: instead of provisioning a persistent environment and committing to it, you can treat each sandbox as a disposable workspace — spun up for one task, dissolved when the agent finishes. Paused sandboxes costing nothing removes the last excuse to keep an idle environment running “just in case”, and the bring-your-own-model-key option means you keep your existing inference costs rather than paying Docker a second time.

Verdict

If you run coding agents on long tasks — refactors, migrations, overnight test suites — Cloud Sandboxes deserves an immediate test: the isolation is identical to what you already know locally, and a Small instance costs less per hour than a coffee, metered to the second with free pause. If you only use agents interactively, on your own machine, local Sandboxes suffice: pay for the cloud only once your tasks outgrow a laptop’s uptime. The architectural takeaway is elsewhere: by refusing to make Cloud Sandboxes a separate product, Docker is staking a claim on a question most teams will soon have to answer — an agent’s isolation should not depend on where it runs. That is a bet worth watching, because it is the same one the industry has to make about every abstraction: trust belongs in the isolation model, not in the machine that happens to host it.

References

• Docker — Introducing Cloud Sandboxes: Start on Your Laptop, Finish in the Cloud (September 24, 2026)
• Docker — Docker and CNCF partner on an open spec for agent permissions (September 24, 2026)