Docker in Sandbox: Run Docker Inside an AI Agent Sandbox with Sandbox0

Docker in Sandbox for AI agents is no longer a niche runtime feature.

AI agents are moving from code snippets to real developer work.

That changes what the runtime has to provide. A serious coding agent does not only need a shell and a temporary directory. It needs to check out a repository, install dependencies, run integration tests, start databases, build images, preview services, and clean up after itself.

In many real projects, those workflows already depend on Docker.

That is why "Docker in sandbox" is becoming a core capability for agent infrastructure. Vercel supports Docker inside its Firecracker-backed Sandbox. Cloudflare documents rootless Docker-in-Docker for its Sandbox SDK. Modal recommends its beta VM Sandbox runtime for Docker workloads. Runloop publishes Docker-in-Docker Devbox blueprints. Docker's own AI sandbox product frames the same requirement around an isolated Docker daemon for coding agents.

The market signal is straightforward: AI agents need environments that look much closer to a developer machine than to a single code runner.

Sandbox0 Docker in Sandbox is built for that runtime gap: run Docker inside an AI agent sandbox without giving the agent control of a shared host Docker daemon.

The built-in default and coding-agent templates include the Docker client and daemon. Start dockerd inside the sandbox when a workflow needs it. Agent tools can then use familiar commands such as docker run, docker build, and Docker Compose style workflows without depending on a Docker daemon on the host machine.

Why Docker Matters for AI Agent Sandboxes#

Most production repositories are not tested with one process.

A backend test suite may need PostgreSQL, Redis, Kafka, MinIO, or a browser service. A generated application may need to be built into an image before a deployment pipeline will accept it. A coding agent may need to validate a Dockerfile, run a service image, or reproduce the exact command a human developer would run locally.

Without Docker support, teams often end up with weak substitutes:

• mock every dependency and miss integration failures
• give the agent access to shared staging services
• mount the host Docker socket into an execution container
• move builds back to CI and lose interactive feedback
• hand-write one-off service startup scripts for every template

Those options are acceptable for demos. They are brittle for production agent systems.

An agent sandbox with a local Docker daemon gives the agent a more realistic developer environment:

• start Redis or PostgreSQL next to the test process
• build a temporary image from generated code
• run a containerized CLI or language tool
• validate Dockerfiles before pushing a change
• exercise Compose-style workflows inside the sandbox
• keep containers and test dependencies local to the sandbox lifecycle

That last point matters. The goal is not only to make docker run work. The goal is to keep the blast radius of agent-created containers inside the runtime boundary where the agent is already operating.

What Sandbox0 Docker in Sandbox Provides#

Sandbox0's built-in default and coding-agent templates provide Docker binaries and writable runtime storage. They do not start dockerd before the sandbox is claimed; the workload starts it once per runtime generation.

Conceptually:

The important behavior is simple:

• docker run starts containers inside the sandbox.
• docker build stores layers in the sandbox Docker data root.
• Docker state lives under /var/lib/docker.
• /var/lib/docker is ephemeral sandbox runtime state.
• Source code, generated files, database dumps, and artifacts can live in the sandbox rootfs and be preserved through rootfs snapshots.

This separation is intentional. Docker layers and throwaway containers are runtime cache. Agent workspaces and outputs are product state.

If a sandbox is deleted, Docker images, containers, layers, and Docker volumes under /var/lib/docker are discarded. Create a named rootfs snapshot before cleanup when the workspace must seed a later sandbox; keep authoritative application data in an external system.

Example: Run Test Databases Inside the Sandbox#

A common use case is integration testing.

Claim a default sandbox, start its Docker daemon, then start Redis and PostgreSQL with host networking. Commands in the same sandbox can reach those services on 127.0.0.1:

bash
SANDBOX_ID="$(s0 -o json sandbox create --template default --hard-ttl 1800 | jq -r '.id')"
trap 's0 sandbox delete "$SANDBOX_ID" >/dev/null 2>&1 || true' EXIT

s0 sandbox exec "$SANDBOX_ID" --no-wait --ttl 1800 -- /bin/sh -lc '
set -e
if ! docker info >/dev/null 2>&1; then
    rm -f /var/run/docker.sock /run/docker.sock /var/run/docker.pid
    /usr/bin/dockerd \
        --host=unix:///var/run/docker.sock \
        --data-root=/var/lib/docker \
        --exec-root=/var/run/docker \
        --storage-driver=vfs \
        --iptables=false \
        --ip6tables=false \
        --bridge=none \
        --ip-forward=false \
        --ip-masq=false \
        >/tmp/sandbox0-dockerd.log 2>&1 &
    until docker info >/dev/null 2>&1; do sleep 1; done
fi
docker rm -f test-redis test-postgres >/dev/null 2>&1 || true
docker pull redis:7-alpine
docker pull postgres:16-alpine
docker run -d --name test-redis --network=host redis:7-alpine
docker run -d --name test-postgres \
    --network=host \
    -e POSTGRES_PASSWORD=postgres \
    -e POSTGRES_DB=app_test \
    postgres:16-alpine
until docker exec test-redis redis-cli ping | grep -q PONG; do sleep 1; done
until docker exec test-postgres pg_isready -U postgres >/dev/null; do sleep 1; done
'

s0 sandbox exec "$SANDBOX_ID" -- /bin/sh -lc '
REDIS_URL=redis://127.0.0.1:6379 \
DATABASE_URL="postgres://postgres:[email protected]:5432/app_test?sslmode=disable" \
go test ./...
'

This is the same shape as a developer running local service dependencies before a test suite, but the services live inside the sandbox instead of on a shared workstation or CI worker.

For agents, that is a cleaner contract. The agent can start what it needs, test against it, and delete the sandbox when the run is over.

Example: Build and Run a Temporary Image#

Docker in Sandbox also helps when the agent needs to validate generated container artifacts.

Inside a Docker-enabled sandbox:

bash
cat > main.go <<'EOF'
package main
import "fmt"
func main() { fmt.Println("hello from docker in sandbox") }
EOF

CGO_ENABLED=0 go build -o hello main.go

cat > Dockerfile <<'EOF'
FROM scratch
COPY hello /hello
ENTRYPOINT ["/hello"]
EOF

docker build -t sandbox0-docker-test .
docker run --rm sandbox0-docker-test

The build cache and image layers are useful during the run, but they are not treated as durable application state. Keep the Dockerfile, source, build logs, SBOM, or exported artifact in the normal workspace so a rootfs snapshot can preserve them.

Why Not Mount the Host Docker Socket?#

Mounting the host Docker socket is the easiest way to make Docker commands work inside a container.

It is also the wrong default for autonomous agents.

The Docker socket is a control plane for the host Docker daemon. A process that can drive that socket can usually create containers, mount host paths, inspect other containers, and modify state outside the intended execution environment. For trusted CI jobs, teams sometimes accept that tradeoff. For agent-generated commands and untrusted code, it weakens the runtime boundary.

Docker in Sandbox should mean "the sandbox has its own Docker daemon," not "the sandbox can control the host daemon."

Start dockerd inside the Sandbox0 sandbox and expose only that sandbox-local Docker socket to its processes. That keeps agent-created containers attached to the sandbox lifecycle instead of a shared host Docker daemon.

The Isolation Boundary: Docker Still Needs Guest Privilege#

Running a Docker daemon inside a sandbox is not a harmless checkbox.

Docker needs Linux capabilities, process isolation, cgroups, networking behavior, and a writable daemon data directory. Sandbox0 runs the guest inside gVisor and does not expose a host Docker socket. A template's mainContainer.securityClass can select standard or privileged guest capabilities, but even the privileged class stays inside runsc and does not grant host devices or host-kernel capabilities.

Hosted default sandboxes provide 500m CPU, 2 GiB memory, and 8 GiB of ephemeral storage. coding-agent provides 1 CPU, 4 GiB memory, and 16 GiB of ephemeral storage. In both cases /var/lib/docker is claim-lifetime ephemeral state and is discarded when the runtime allocation is replaced.

For production self-hosted deployments, run Sandbox0 workloads on dedicated Nomad clients. Operators configure the standard and privileged runtime classes, node capacity, NBD devices, and shared one-shot carrier pool. Docker remains an explicit guest capability rather than access to a shared host daemon.

The product point is not to hide this tradeoff. It is to make Docker support an explicit platform capability with an explicit operational boundary.

Docker State vs. Workspace State#

Docker in Sandbox is most useful when the platform is clear about what persists.

There are two different states:

Treating Docker state as durable by default can be expensive and surprising. Image layers are large. Test databases can grow quickly. Agent-created containers are often intermediate work, not long-term output.

Sandbox0 keeps the default boundary conservative: Docker state is sandbox-local and ephemeral, while reusable workspace state is captured through rootfs snapshots.

That matches how agent workflows usually behave:

• use Docker to create the temporary environment
• run tests or builds
• copy meaningful outputs into the workspace
• snapshot, fork, or restore the sandbox rootfs
• delete the sandbox and discard container runtime state

This keeps the durable storage plane focused on files the product actually needs.

How This Compares to Other Agent Sandbox Docker Support#

The ecosystem is converging on the same requirement, but the implementations have different tradeoffs.

The interesting part is not who can run docker hello-world.

The interesting part is the runtime contract around Docker:

• Is Docker state durable or ephemeral?
• Does the agent get the host Docker socket or a sandbox-local daemon?
• Can the sandbox run service dependencies beside tests?
• Can the platform separate temporary container state from durable workspace state?
• Who is allowed to enable the privilege needed for Docker?
• How does the network policy model interact with containers started inside the sandbox?

Those are infrastructure questions, not SDK convenience questions.

What Docker in Sandbox Unlocks for Agents#

Docker support makes several agent workloads more realistic.

Integration Tests#

Agents can run test suites that depend on real services. Instead of mocking PostgreSQL or Redis, the agent can start service containers and run the same test command a human would run locally.

Container Image Validation#

Agents can edit a Dockerfile, build the image, run it, inspect logs, and catch broken build steps before opening a pull request or handing work back to CI.

Generated App Preview#

When an agent generates a containerized app, it can run the image inside the sandbox and expose the relevant service through Sandbox Services when an external preview is needed.

Tool Compatibility#

Many developer tools assume Docker exists. Docker in Sandbox reduces the amount of special-case template work required to support those tools.

Safer Autonomy#

The agent can perform Docker-heavy work without controlling a shared host Docker daemon. That does not remove every security consideration, but it gives the platform a clearer runtime boundary to manage.

When Not to Use Docker in Sandbox#

Docker is powerful, but it is not always the right primitive.

Use the default Sandbox0 template when the workload only needs normal shell commands, language runtimes, file APIs, or lightweight tools.

Use Docker in Sandbox when the workload actually needs Docker semantics:

• service containers
• image builds
• Compose-style local dependency graphs
• containerized CLIs
• Dockerfile validation
• test flows that are already Docker-native

If you only need a long-running HTTP process, use Sandbox Services. If you need a reusable filesystem checkpoint, create a rootfs snapshot. If you need to protect outbound traffic or inject credentials, use Sandbox Network and credential policies.

Docker is part of the runtime toolbox. It should not become the only way to model every agent workload.

Build Agents Against Real Developer Environments#

The practical test for an AI agent runtime is simple:

Can the agent run the commands the repository already expects?

For many teams, those commands include Docker. They start databases, build images, run Compose workflows, and validate containerized applications.

Sandbox0 Docker in Sandbox gives agents that capability inside an isolated gVisor runtime. The workload starts a sandbox-local Docker daemon, keeps Docker runtime state under ephemeral /var/lib/docker, and lets reusable workspace state be captured in rootfs snapshots.

That is the right shape for production agent infrastructure: real developer workflows, explicit operational boundaries, and no dependency on a shared host Docker daemon.

Read the Docker in Sandbox docs, or start from the Sandbox0 self-hosted configuration guide if you are enabling Docker in Sandbox for your own deployment.

References#

• Vercel: Run Docker containers inside Vercel Sandbox
• Vercel Sandbox docs
• Cloudflare Sandbox SDK: Run Docker-in-Docker
• Modal: VM Sandboxes
• Runloop: Running Docker on a Devbox
• Docker Sandboxes
• Docker Sandboxes: Isolation layers