Comparison
Docker Sandboxes vs a persistent cloud computer for coding agents (2026)
Docker Sandboxes run a coding agent such as Claude Code, Codex or OpenCode inside a microVM. Locally they use your own machine's resources for free and see your project folder directly. In Docker's cloud they keep working while your laptop is shut, billed per second, and by default expire after an hour, which stops a resumable sandbox; extensions reach at most 24 hours from creation. A persistent cloud computer, such as a Sanbox Computer, is a machine the agent keeps: it stays on until you stop it, keeps its disk across stops, and runs in EU data centres. Use Docker Sandboxes to make agents on your laptop safer. Use a persistent computer when the agent should work for days without you.
What are Docker Sandboxes?
Docker Sandboxes is Docker's product for running AI coding agents in isolated environments, managed with the sbx CLI. There are two kinds, with separate credentials, network policies and lifecycles.
Local sandboxes run on your machine as microVMs:
- Each sandbox has its own Docker daemon, image cache and installed packages, and the host Docker daemon is blocked.
- Your project folder is mounted through a filesystem passthrough, so edits show up instantly on both sides. Clone mode mounts the repo read-only and works in a private clone instead.
- All outbound TCP traffic, including HTTP, HTTPS and SSH, is blocked unless a rule allows the destination. A host-side proxy injects credentials, so the agent can't read the raw keys.
- A stopped sandbox keeps its packages, images and files until you remove it with
sbx rm. - The
sbxCLI and local compute are free, including for commercial work. Central policy management needs a paid subscription. - They need macOS 14 or later on Apple silicon, Windows 11 with Windows Hypervisor Platform, or Ubuntu 24.04 or later with KVM. Docker Desktop isn't required.
Docker lists Claude Code, Codex, Copilot, Cursor, Devin, Docker Agent, Droid, Gemini, Kiro and OpenCode as supported agents, plus an agent-less Shell sandbox.
Cloud sandboxes were announced on 2026-09-24. They run on Docker-managed infrastructure with the same microVM isolation as local sandboxes, Docker says:
- They are part of the Docker Agentic Platform, which Docker's docs label experimental. Compute is pay-as-you-go per second, from about $0.07 an hour (1 vCPU) to $1.12 an hour (16 vCPUs), and the first $25 of compute is free. Stopping a cloud sandbox keeps its memory and filesystem, and stopped sandboxes aren't billed for compute.
- They don't mount local folders: you clone a repo inside the sandbox or copy files in with
sbx --cloud cp. - A cloud sandbox expires after one hour by default. You can extend that, but not past 24 hours from creation. On expiry, resumable sandboxes are stopped and the rest are deleted. Resuming keeps the state and starts a new time-to-live.
- Sizes run from 1 CPU and 2 GiB to 16 CPUs and 32 GiB, with 2 CPUs and 4 GiB by default.
- Docker's docs don't state where the cloud regions are.
What is a persistent cloud computer?
It's a machine in the cloud that belongs to one agent and outlives any session. The agent keeps its repo, packages, logins and running services, and you reach it from any device.
On Sanbox, each Computer is a Firecracker microVM with its own kernel and private disk, in EU data centres.
- OpenCode Computers run OpenCode as a private server and stay active until you stop them. You can also install Claude Code or Codex on one with npm.
- Docker Computers run Docker Engine, Buildx and Compose inside the microVM. They have no agent and no model, so you drive them from your coding agent, CI or app with
sanbox execandsanbox cp.
sanbox templates create --name compose-stack --type docker-computer \
--network-policy registries.json --json
sanbox run --template <template-id> --json
sanbox cp ./app <run-id>:/workspace
sanbox exec <run-id> --cwd /workspace/app -- docker compose up -d
On a Docker Computer, images, build caches and volumes live on the disk, so stop, resume, fork, snapshots and warm pools keep them. Containers come back after a resume only if they have a restart policy such as restart: unless-stopped. See Docker Compose inside an agent computer for the full recipe.
How do they compare?
Docker facts were checked on docs.docker.com and docker.com on 2026-11-06.
| Docker local sandbox | Docker cloud sandbox | Sanbox Computer | |
|---|---|---|---|
| Runs on | Your machine | Docker-managed cloud; ask Docker for regions | EU data centres |
| Isolation | microVM | microVM | Firecracker microVM |
| Your files | Host folder mounted live | Clone or copy in | Copy in with sanbox cp or clone |
| Lifetime | Until you remove it | 1 hour by default; extensions end at 24 hours from creation; a resume starts a new time-to-live | Until you stop it (OpenCode and Hermes Computers) |
| Runs while your machine is off | No, it uses your machine | Yes | Yes |
| Docker inside | Own Docker daemon | See Docker's exec and healthcheck note | Docker Computer: Engine, Buildx, Compose |
| Outbound network | Deny by default | Separate network policy | Deny by default, per host and port |
| Credentials | Injected by host proxy | Separate cloud secret store | Secret Proxies inject on the way out |
| Agents | 10 listed agents plus Shell | Claude Code and other agents via sbx --cloud | OpenCode, Browser, Hermes Computers; install Claude Code or Codex yourself |
| Price | Free | Per second, about $0.07 to $1.12 an hour by size ($0.14 for the default 2 CPUs, 4 GiB) | Per organisation; talk to us |
For Compose in the cloud, Docker's docs flag a "Docker exec and healthcheck limitation" that can affect container setup and Compose service readiness. Read it before you move a Compose-heavy workflow there.
When is a local Docker sandbox enough?
- You work at your desk and want the agent boxed in while you watch.
- The agent should edit your real checkout, with changes visible in your editor straight away.
- You want to keep costs at zero and use your own CPU and memory.
- You want one
sbxcommand to start any of ten supported agents.
When do you want a persistent cloud computer?
- The agent works while you're away. A local sandbox needs your machine on. A cloud computer doesn't.
- The work lasts longer than a day. A Docker cloud sandbox expires an hour after it starts unless you extend it, and extensions end at 24 hours from creation. Resumable ones stop rather than vanish, and a resume starts a new time-to-live; a
restarttimeout action stops and starts the sandbox for you. An OpenCode or Hermes Computer has no expiry and stays on until you stop it. - Services must keep running: a dev server, a database, a queue worker or a watcher.
- Data must stay in the EU. Sanbox stores Computers, disks, snapshots and logs in EU data centres under an Article 28 DPA with Sanlabs GmbH, a company under German law.
- A team shares the machines. Developers, Admins and Owners in a Sanbox organisation can operate any run, including its terminal, files and browser. Viewers can't run or change anything.
- You want reusable starting points. Snapshot a prepared Computer and start new ones from it, or keep up to 5 ready in a warm pool.
Where Docker Sandboxes are stronger
- Free local use, including commercial work, on hardware you already own.
- Live access to your host files, with no copying.
- One CLI for local and cloud, so the same commands work in both.
- Broad agent support out of the box: ten named agents plus a plain shell.
- Bigger cloud sizes, up to 16 CPUs and 32 GiB.
- Memory kept across a cloud stop. Docker says a stopped cloud sandbox keeps its memory and filesystem. A Sanbox stop keeps the disk only.
- Governance features: organisation admins can manage policies centrally.
- Kits, an open specification for packaging an agent sandbox as OCI images, which Docker says it will submit to the CNCF.
- Host integrations locally, such as GPU, USB, display and nested virtualisation, which Docker's comparison page lists for local sandboxes.
When not to use Sanbox
- You want the agent to edit your local checkout live. Sanbox Computers work on their own disk.
- You need GPUs or WebSockets into the machine.
- You need large disks self-serve. Computers take 1 to 8 GB, and larger disks are enabled on request.
- You want the coding agent and Docker ready-made in the same machine. Sanbox's Docker Computer has no agent, Node or Python preinstalled; you drive it from outside with
sanbox exec. - You only run an agent while you're at your desk. A free local sandbox costs less.
For a business use case, talk to us. Our forward-deployed engineers can build it with you.
Related
- How do I run Docker Compose inside an AI agent's sandbox?
- Container, microVM or VM: which isolation for coding agents?
- Claude Code on the web vs your own cloud computer
- How do I run Claude Code on a cloud computer that keeps its files?
Sources
- Docker, Docker Sandboxes (local and cloud, free local use), Architecture and Security defaults, checked 2026-11-06
- Docker, Supported agents and Install (host requirements), checked 2026-11-06
- Docker, Cloud sandboxes, Cloud sandbox usage (expiry, sizes, resume) and Local vs cloud, checked 2026-11-06
- Docker, Docker Agentic Platform (labelled experimental), Agentic Platform plan and Docker Agentic Platform product page (hourly rates by size, $25 of free compute), checked 2026-11-06
- Docker, Cloud Sandboxes press release, 2026-09-24 (microVM isolation, 1 to 16 vCPUs, Kits), checked 2026-11-06