# Docker and nested KVM inside an AI agent sandbox

> 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.

Source: https://sandboxer.com/guides/docker-and-kvm-inside-an-agent-sandbox. Updated 2026-10-24.

**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

```bash
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](/use-cases/android-emulator).
- **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:

```bash
sbx exec sb_k3v9x2mq --timeout 600 "docker pull postgres:17 && docker pull node:22"
sbx snapshot sb_k3v9x2mq docker-ready
sbx new --from docker-ready
```

## FAQ

### 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.