Runtime

Local Docker vs a cloud sandbox for running AI agent code

Local Docker runs agent code on your own machine, beside your files and network; a cloud sandbox runs it on a throwaway microVM elsewhere.

A Runtime sandbox takes the agent's code off your laptop for $0.03125 an hour while it waits and $0.08 with 2 vCPUs busy, and the first 50 hours are free. Each one is a Firecracker microVM with its own Linux kernel, and a new one ran its first Python command 351 ms after the create request at the median, measured on 24 September 2026 (speed). Docker still works: it runs inside the sandbox.

What a local container shares with you

Docker's defaults are made for your own trusted software. For code a model wrote, each default is something the code can reach:

What Local Docker, as Docker documents it
Kernel On Linux, your machine's. Docker Desktop "runs the Docker Engine inside a lightweight Linux virtual machine"
Files "Bind mounts have write access to files on the host by default", unless mounted ro
CPU and memory "By default, a container has no resource constraints", until you pass --memory and --cpus
Network Whatever you give it; --network none leaves "only the loopback device"
The daemon "Requires root privileges unless you opt-in to Rootless mode"; "only trusted users should be allowed to control your Docker daemon"
Your keys Anything you pass in -e or mount is readable by the code

Docker says of bind mounts that "you can change the host filesystem via processes running in a container, including creating, modifying, or deleting important system files or directories." Mounting a project so the agent can edit it is exactly that.

Docker also offers Docker Sandboxes, which run coding agents in a microVM on your machine, with "a separate kernel per sandbox" and outbound traffic "governed by a deny-by-default policy".

What changes in a cloud sandbox

Concern Local Docker Runtime sandbox
Where the code runs Your laptop or build server A microVM on dedicated servers Runtime operates
Your files Reachable through whatever you mount Only what you upload; results come back with files.download
Your network What you configure; --network none for none Private and internal addresses refused; allow and deny lists on top
API keys Visible to the code Secrets the sandbox never holds; the host's proxy adds them per host
Root inside Maps to root on the host unless user namespaces are on Root of the guest only; network, CPU, memory and cost set on the host
Many at once As many as your machine fits Eight on the trial, 100 on a paid account to start
Laptop closed Everything stops Runs on, or pauses with memory and processes, 1 to 365 days
Showing someone A tunnel you set up A preview URL for any port, private with a token by default
Cost Your own hardware and power $0.025 per active vCPU-hour, $0.0075 per GiB-hour

Docker's user namespace remapping, which changes the root row, is off until you enable it on the daemon.

What it costs

Local Docker's cost is the machine you already own. A Runtime sandbox of 2 vCPU and 4 GiB, per hour and per working month of 8 hours a day for 21 days:

Use Per hour 168 hours
Mostly waiting $0.03125 168 × $0.03125 = $5.25
Both CPUs busy $0.08 168 × $0.08 = $13.44
Paused $0.00 compute Storage at $0.08 per decimal GB per 30-day month

The free trial's 50 hours come first, with no card (pricing).

The Runtime equivalent

Send the project you would have mounted, run its Compose stack inside the sandbox, and bring the results back. The containers share the sandbox's kernel, not yours.

TypeScriptimport { mkdtemp, writeFile } from "node:fs/promises";import { tmpdir } from "node:os";import { join } from "node:path";import { Sandbox } from "withruntime";const project = await mkdtemp(join(tmpdir(), "agent-"));await writeFile(join(project, "main.py"), "print('built in the sandbox')\n");await using sbx = await Sandbox.create({ diskMiB: 8192 });await sbx.files.upload(project, "/workspace/project");await sbx.exec("sudo enable-docker", { check: true, timeoutMs: 300_000 });const run = await sbx.exec(  "docker run --rm -v /workspace/project:/app -w /app python:3.12-slim python main.py",  { timeoutMs: 300_000 },);console.log(run.stdout);await sbx.files.download("/workspace/project", join(project, "..", "agent-out"));
Pythonimport pathlibimport tempfilefrom withruntime import Sandboxproject = pathlib.Path(tempfile.mkdtemp())(project / "main.py").write_text("print('built in the sandbox')\n")with Sandbox.create(disk_mib=8192) as sbx:    sbx.files.upload(str(project), "/workspace/project")    sbx.exec("sudo enable-docker", check=True, timeout_ms=300_000)    run = sbx.exec(        "docker run --rm -v /workspace/project:/app -w /app python:3.12-slim python main.py",        timeout_ms=300_000,    )    print(run.stdout)    sbx.files.download("/workspace/project", str(project.parent / "agent-out"))

The bind mount here writes to the sandbox's disk, which is thrown away with it. docker compose up -d works the same way, and a published port can be forwarded to your machine with runtime sandbox port-forward (Docker).

Which one fits

  • Local Docker for your own code and services, fast iteration on a project you trust, and anything that must stay on your machine.
  • A cloud sandbox for code you did not write: an agent's commands, a model's answers, a user's upload. Also when you need many at once, a run that outlives your laptop, or a link to show someone the result.

Start from your terminal:

Terminalnpx withruntime sandbox run --trial -- python3 -c 'print(6 * 7)'

The first run prints a link to approve in your browser; there is no API key to copy.

More: run Docker in a sandbox, microVM vs container, Firecracker vs Docker, coding agent sandbox, preview agent-built apps.

Sources

Checked 25 September 2026.

Facts on this page were checked on 25 September 2026.

Claim 50 hours free