Docker Cloud Sandboxes: what moves to the cloud, and what stays behind?

An agent can propose a large dependency upgrade, but someone still has to provide the machine on which it runs. If that machine is a laptop, a closed lid or interrupted connection can become part of the project’s critical path. Docker Cloud Sandboxes, announced on September 24, puts that execution environment on Docker-managed infrastructure.

The interesting question is what developers can actually hand over. A cloud machine can outlive a laptop session; it cannot decide whether a change deserves to reach production. Our reading of the documentation is that this is most useful for separating lengthy execution from the developer’s interactive workspace, with review still happening at the end.

What is available?

The launch announcement describes microVM-based environments and ready-made agent kits. The official console screenshot used as this article’s cover shows the launch controls, not a test we conducted.

The cloud documentation labels the cloud CLI experimental and requires an Agentic Platform subscription. The default expiration is one hour, with stop or delete behavior configured for the timeout; a longer job needs an appropriate timeout and a plan to preserve its output. Cloud workspaces do not mount a laptop directory: a project must be cloned or copied in. That distinction matters before promising that an existing development setup will transfer unchanged.

Consider a dependency migration in a small website. A useful brief would identify the target versions, required checks and deliverable branch. It would also say which files must remain untouched. Moving the task away from the laptop does not remove the need for those acceptance criteria; it makes writing them down more valuable.

A move is a snapshot, not a running process teleport

The move reference describes a filesystem snapshot recreated as a new sandbox. Process memory does not move. The source remains a separate environment. Mounted host workspaces and managed secrets are excluded, but credentials saved by a tool inside the sandbox can travel with its files.

This gives “resume later” a precise meaning. Before moving a long job, save useful intermediate results to the sandbox filesystem and know how to restart the work from those results. After the move, verify the destination rather than assuming the original process is still running.

A practical handover note might contain three items: the last completed test, the next command and the location of generated artifacts. Those are our suggested operating practices, not a claim that Docker automatically creates such a note. For a team, keeping that information with the task also makes a human takeover less fragile.

The permissions need a second look

According to the local-versus-cloud comparison, secrets and network policies are separate between the environments. Local policies are not copied. Cloud does not currently support the same HTTP method/path filtering, and exposed ports use public HTTPS URLs rather than laptop loopback addresses.

Before handing over work	Why we would check it
Repository and branch	Keep the agent’s changes separate from a developer’s uncommitted work.
Destination credentials	Give this particular task only the access it needs.
Network destinations	A build may need package downloads while having no reason to contact a production database.
Output and review route	A completed process is useful only if its changes and test results can be inspected.

The table is our review checklist. It is not a list of guarantees from the product. Isolation is valuable, but permissions granted inside an isolated environment can still have consequences outside it. In particular, we would start a trial with a disposable branch and without production deployment credentials.

What does the compute cost?

Docker’s announced hourly rates are below. Charges are metered by the second; these figures are compute prices.

Size	CPU / memory	USD per hour
Micro	1 vCPU / 2 GiB	0.07
Small	2 vCPU / 4 GiB	0.14
Medium	4 vCPU / 8 GiB	0.28
Large	8 vCPU / 16 GiB	0.56
XL	16 vCPU / 32 GiB	1.12

The billing documentation separates this from model inference billed by the chosen provider. Our arithmetic: four hours on Small costs $0.56 in compute; ten such jobs cost $5.60. Neither is a complete agent budget. Repeated model calls, failed approaches and the time needed to review a result belong in the calculation too.

For an initial experiment, we would compare one bounded task on the laptop and in the cloud, recording completion, total cost and reviewer time. Paying less per machine-hour is not an improvement if the task takes much longer or produces work that must be redone.

Kits make the setup reviewable

A separate September 24 Kit Specification announcement describes packaging agent configuration in ordinary, pinnable OCI images. The specification is Apache 2.0 licensed. That does not make the managed cloud service itself an open-source project.

The useful editorial angle is reproducibility: a team needs to know which agent setup ran a task, not only which prompt it received. A pinned kit can be part of that record. We would still record the code revision and task instructions alongside it.

Docker also provides an official keynote page for its broader agent infrastructure presentation.

Our assessment: this is a relevant infrastructure release for teams already running lengthy coding tasks. The first evaluation should be a repeatable, low-stakes job with explicit limits. The headline benefit is a place for the work to continue; the quality of the finished change still needs to be earned and checked.