Docker and nested KVM inside an AI agent sandbox
Updated October 24, 2026 .md
Short answer: Use a sandbox that is a full virtual machine rather than a container. A Sandboxer sandbox is a Cloud Hypervisor microVM with its own kernel, Docker preinstalled and /dev/kvm available, so an agent can run docker build, docker compose, kind, QEMU or the Android emulator inside it without mounting the host's Docker socket.
At a glance#
| In a Sandboxer sandbox | |
|---|---|
| Docker | Preinstalled (Docker 29.9 when we checked), daemon running, user is in the docker group |
docker run, build, compose |
Work as on any Linux machine |
/dev/kvm |
Present and writable by user (kvm group); the vCPUs expose vmx/svm |
| Nested VMs | QEMU, Firecracker and the Android emulator run inside; use large or xlarge |
| Kubernetes | kind and k3s work |
| Isolation from other sandboxes | Separate VM and kernel per sandbox; VM-to-VM traffic is blocked |
Check it in your own sandbox#
sbx new --type large
sbx exec sb_k3v9x2mq "docker run --rm hello-world | grep Hello"
sbx exec sb_k3v9x2mq "ls -l /dev/kvm && id -nG"On a sandbox we created for this guide, docker run --rm hello-world printed Hello from Docker!, /dev/kvm was crw-rw---- root kvm, and id -nG listed user sudo docker kvm.
Why a container sandbox makes this hard#
A container shares the host's kernel. To give an agent Docker inside a container, the usual options are:
- Mount the host's Docker socket. The agent then controls the host's Docker daemon, and through it the host. That's not a sandbox any more.
- Docker-in-Docker with
--privileged. It works, but a privileged container gives up most of the isolation that made it a sandbox. - Rootless or user-namespace setups. Safer, but more setup and more things that don't work the same.
A microVM avoids the trade-off. The agent is root in its own VM, with its own kernel and its own Docker daemon, and the boundary is the hypervisor rather than the host kernel.
Nested virtualization#
Because /dev/kvm is exposed, tools that need hardware virtualization run inside the sandbox:
- Android emulator: see the Android emulator use case.
- QEMU/KVM for testing an OS image or a kernel.
- Firecracker if you're building your own microVM tooling.
Nested VMs are heavier than containers. Pick large (8 vCPU, 16 GB) or xlarge (16 vCPU, 32 GB; needs the $100 plan or higher).
Keep the work after the agent stops#
A stop saves memory as well as disk. Containers you started, their volumes, and the Docker build cache are still there after sbx resume, and running containers keep running. To start every new sandbox with your images already pulled, prepare one and save it as a named snapshot:
sbx exec sb_k3v9x2mq --timeout 600 "docker pull postgres:17 && docker pull node:22"
sbx snapshot sb_k3v9x2mq docker-ready
sbx new --from docker-readyFAQ#
Can an AI agent run Docker safely?#
Yes, if Docker runs inside the agent's own VM rather than on your host. In a microVM sandbox the agent's containers and daemon live inside that VM, so nothing it runs touches your machine or other sandboxes.
Does nested KVM work in a cloud sandbox?#
On Sandboxer, yes: /dev/kvm is available inside every sandbox. Elsewhere it depends on the provider; a sandbox that is a container rather than a VM usually has no /dev/kvm to give you.
Is docker.sock mounted from the host?#
No. Each sandbox runs its own Docker daemon inside its own VM. There's no host socket to mount.
Which size should I use for Docker?#
default (4 vCPU, 8 GB) is fine for builds and a few containers. Use large or xlarge for many containers, browsers or nested VMs.
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.