Build1 publisher2 min readPublished
Docker's sbx move shifts a coding agent's sandbox from laptop to cloud microVM in one command
Docker Cloud Sandboxes let one command move a coding agent's microVM sandbox from laptop to cloud, for runs Docker pitches at up to 21 hours. Where an agent runs becomes a CLI choice, though commenters argue the harder limit is which outside services it can reach.
The Engineer · Build desk
What happened
- Docker announced Cloud Sandboxes, hosted environments with hardware-enforced microVM isolation for running AI coding agents on Docker-managed infrastructure.
- A single command, sbx move my-project --to cloud, shifts a sandbox from a laptop to Docker's infrastructure, and the same command moves it back.
- Cloud sandboxes use the same isolation model as local Docker Sandboxes and are managed through the same CLI.
- Under the Kits v3 specification, Docker's pre-built sandbox kits ship as standard OCI images instead of a separate artifact type.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Where a long agent run executes becomes a per-task call: start it on the laptop, then hand it to Docker's cloud when it needs more resources or before the developer leaves for the day.
- constraint Only the filesystem is documented as crossing over in a move, so agents that write their progress to disk are the ones that can resume cleanly on the other host.
- capability Sandbox environments can now be distributed through the same registries and build pipelines a team uses for container images, with no separate kit format to support.
- contradiction Docker pitches the sandboxes as a safe place for autonomous agents. Commenters on Reddit and Hacker News argue the real exposure is the set of services an agent may call, and a microVM leaves that set as it was.
The move is a copy of files [5]. According to Docker, sbx move "captures the sandbox's filesystem and recreates it on the other side, so your work carries over" [5]. The InfoQ report does not say whether running processes or an agent's in-memory context survive the move, and it does not include pricing.
Long runs need a host that stays up. In InfoQ's description, a laptop "sleeps when the lid closes, slows down on battery, and disconnects when you move" [6]. Docker says developers are increasingly running multiple long-horizon tasks in parallel and need persistent, scalable environments beyond the local machine [3].
I think the design fits that problem. The move leaves the sandbox itself unchanged [5][9], so an overnight run depends on the task and no longer on whether someone closed a lid.
In Docker's own words, the goal is to "run a dozen agents at once, for five, ten, or 21 hours each, without watching any of them" [7]. At the top of that range, 12 agents at 21 hours each come to 252 agent-hours in one batch [8]. That figure describes the workload Docker is aiming at. It applies to a team only if its tasks can run most of a day with nobody approving steps, and if 252 hours of hosted microVM time costs less than the engineering time it frees [8].
Florin Lungu, a lead devops engineer at Deutsche Bank, said he finds "it interesting that this innovation allows for safe, autonomous coding in microVM environments, enhancing flexibility in our workflows" [16].
Other commenters pointed to what the boundary leaves open. A Reddit user posting as CircumspectCapybara wrote that "any remotely useful agent workload is going to need to connect their sandboxed agents to limited external services", including "real libraries or artifacts and stuff it might try to pull down from PyPI or Docker Hub or Hugging Face" [13]. The same user wrote that agents "can just talk to the narrow set of services they have been given access to and by talking to them break them while remaining inside the sandbox" [14].
On Hacker News, a reader posting as ongedierte argued that "traditional sandboxes are not going to be the correct abstraction" and that "building harnesses based on object capabilities and being able to limit exactly what an agent can access in what manner will be the way forward" [15].
What to watch
- Docker's published rate for Cloud Sandbox hours, the input that decides whether a 252-agent-hour batch beats a self-hosted runner.
- Any Docker documentation of network egress or service-access controls for cloud sandboxes, the gap CircumspectCapybara raised.
- Whether sbx move is extended to carry running processes across hosts, beyond the filesystem capture Docker describes.