Writing

Docker cloud sandboxes keep agents running after you close the laptop

You know the pattern. I've hit it often enough to treat a closed laptop as a destructive action. You start an agent on a local task, and it's making progress. Then you need to leave for the day, so you close the laptop, and the whole run dies with it. This is the default experience for anyone experimenting with agent workflows on a developer machine: the process lives inside your terminal session, and when the session goes away, so does the work.

Docker's new cloud sandboxes solve this by acting like screen or tmux for containers. If you've used either, you know the trick: you detach a session, the process keeps running on the server, and you reattach later from anywhere. Docker cloud sandboxes do the same for agent workloads, but instead of an SSH session you have to babysit, the agent runs inside a managed microVM. It keeps going after you disconnect.

Each agent gets its own microVM, which means isolation and a clean environment for every run. You can configure network access—some agents need egress to internal APIs, others should only reach the public internet or nothing at all. Moving files between your laptop and the cloud sandbox is a single command, so the context you already have doesn't need to be rebuilt from scratch.

You could get a similar effect by SSHing into a cloud VM, starting screen, and detaching. But then you have a VM to provision, patch, and remember to turn off. The microVM is the unit here: it exists for one agent, it's isolated by default, and it stops billing when the work stops. That's the part screen or tmux alone doesn't give you.

Compute is metered from $0.07 per hour. The important part isn't the exact number; it's that you're paying for detached execution, not idle infrastructure. A cloud instance usually costs money whether or not your agent is running. The sandbox meter runs only while the microVM is doing work, which changes the economics enough that detaching becomes a rational choice instead of an extra bill.

Teams start agents locally because it's fast: no cloud account, no provisioning, no waiting. But a proof of concept that dies when you close the laptop never graduates. The moment an agent is expected to run longer than a coffee break, it needs an execution environment that doesn't depend on your machine staying awake.

For teams moving agents from proof of concept to something closer to production, this is the operational primitive that has been missing. You get isolated, ephemeral, cost-controlled execution that survives your laptop closing. That combination is hard to assemble from raw cloud primitives: you can spin up a VM and keep it running, but now you're managing infrastructure. Or you can use a CI runner, but that's built for jobs, not long-running agents. A sandbox sits in between.

The pattern behind this matters beyond Docker. Agent workflows are starting to look less like short commands and more like background processes that need to outlive the interactive session that launched them. Closing a laptop shouldn't be a destructive act for a task that still has work to do. Detached execution used to be a Unix trick; now it's becoming a deployment property.

Docker's announcement has the details on how cloud sandboxes work and how to get started. It's worth reading if you're building agent infrastructure or just tired of losing runs to a closed lid.

Originally covered at docker.com ↗