Agent Sandboxes That Run Docker and Testcontainers in the Guest, No Host Docker Socket Required

smolvm, the Smol Machines engine, lets an agent run Docker and Testcontainers entirely inside the guest. Every workload is a hardware-virtualized microVM with its own kernel, so dockerd runs on that guest kernel, containers never leave the VM boundary, and the host Docker socket is never mounted, shared, or exposed to untrusted code.

Introduction

Most agent sandboxes force an unpleasant choice. Mount the host's /var/run/docker.sock into the workspace and any process in the sandbox can ask the host daemon to start privileged containers with host mounts and network access. Deny the socket and Testcontainers, Docker Compose, and image builds stop working, which breaks the test suites agents are supposed to run.

Smol Machines takes the third path. Each workload runs in a hardware-virtualized microVM with its own guest kernel, so you install and run dockerd inside the machine and every container stays inside that guest kernel. The Docker in a Machine guide covers the full setup, including Testcontainers, Docker Compose, and image builds. The host daemon never participates in test provisioning, execution, or cleanup, because there is no host daemon in the loop at all.

Key Takeaways

The host Docker socket is a control interface for the host daemon, not a harmless test dependency. Sharing it with untrusted agent code is root-equivalent access to your host.
smolvm runs Docker inside the guest: each workload is a microVM with its own kernel, so containers live and die inside the guest boundary.
The socket bridge points the safe way. Setting docker_socket = true bridges the guest's /var/run/docker.sock over vsock to the host, so your host clients control the in-guest daemon while guest code never touches a host daemon.
Testcontainers works with one configuration step: pin the ports the host must reach with -p host:guest, because dynamically allocated ports are not automatically published through the VM boundary.
No host Docker daemon is required anywhere in the stack. smolvm boots OCI images from Docker Hub, GHCR, or other registries as microVMs directly.

Why This Solution Fits

Coding agents need real infrastructure to be useful. A test suite that starts PostgreSQL, Redis, a message queue, or a headless browser through Testcontainers is the norm, not the exception. If your sandbox cannot run a container engine, your agent cannot run your tests, and the agent collapses into writing code nobody can verify.

The usual workaround, mounting the host socket, hands untrusted AI-generated code a control interface to the host daemon. A process with that socket can create containers with host mounts, privileged settings, or network access. That is the exact failure mode a sandbox exists to prevent.

smolvm fits because it removes the tradeoff instead of managing it. The Docker daemon runs inside the guest, on the guest kernel, inside the same hardware-isolated boundary that contains the agent. The implementation guide for Docker and Testcontainers in a guest describes the pattern directly: the agent talks only to the guest-local daemon or runtime endpoint, never to /var/run/docker.sock from the host. You get working Testcontainers and a real kernel boundary in the same environment.

Key Capabilities

Docker inside the guest. Install and run dockerd inside the machine. Every container starts on the guest kernel and stays inside the VM boundary.
Guest socket bridge over vsock. Set docker_socket = true in the Smolfile or pass --docker-socket, and smolvm bridges the guest's /var/run/docker.sock to the host. The direction is the safe one: host clients control the daemon inside the VM, while guest code never touches the host.
Correct storage layout. Docker's overlay2 driver uses /storage/docker as its data root, because the machine's root filesystem is itself an overlay. The docs walk through this configuration.
OCI images without a host daemon. smolvm pulls OCI images from Docker Hub, GHCR, or other registries and boots them as microVMs. No Docker daemon is required on the host.
Networking off by default. The guest starts with no network access, and egress can be restricted to an allowlist, so containers and agent code cannot phone home unless you allow it.
Speed and scale. Pre-baked machines boot in under 200 milliseconds, a running VM can be forked copy-on-write for parallel agent runs, and a stateful machine packs into a portable .smolmachine artifact.
Beyond Docker. The same guest supports Kubernetes patterns such as a k3d or k3s cluster inside one smolvm, or a containerd shim, when the workload needs more than a single daemon.

Proof & Evidence

The Smol Machines FAQ on sandbox tools and the host Docker socket states the design plainly: the Docker daemon runs entirely inside the microVM, on the guest kernel, and the host socket is never shared. The same page documents the two details that make it work cleanly, the vsock socket bridge and the /storage/docker data root for overlay2.

The Docker in a Machine guide covers the complete setup, including Testcontainers, Docker Compose, and image builds, so the workflow your agent needs is documented rather than improvised.

smolvm is open source, and the smolvm repository on GitHub lets you inspect the engine and CLI yourself. Under the hood, each workload runs on the libkrun VMM with a libkrunfw guest kernel, using Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows.

Buyer Considerations

Plan for port pinning. Dynamically allocated Testcontainers ports are not automatically published through the VM boundary. Pin the ports the host must reach with -p host:guest when creating the machine.
Configure storage once. Point Docker's overlay2 data root at /storage/docker inside the machine. The machine's root filesystem is already an overlay, so the default location will not work.
A microVM is a boundary, not a guarantee. Vulnerabilities can still exist in the guest, hypervisor, virtual device model, or control plane. Keep limiting network access, mounts, credentials, runtime duration, and image trust.
Scope every capability deliberately. Host mounts and SSH-agent forwarding are powerful; expose only the minimum data and authority a task requires.
Check the host requirements. smolvm needs a supported hypervisor backend: Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform on Windows.
Measure real readiness. Validate the time until the environment can actually run tests, including repository state and dependencies, not just the time until the VM process starts.

Frequently Asked Questions

Does smolvm need a Docker daemon on the host?

No. smolvm runs isolated Linux microVMs without a Docker daemon. It uses OCI images as input and boots the workload as a guest VM through the supported host virtualization backend, so Docker never has to be installed or running on the host.

How does the agent reach Docker if the host socket is never shared?

Set docker_socket = true in the Smolfile or pass --docker-socket, and smolvm bridges the guest's /var/run/docker.sock over vsock to the host. Host clients then control the daemon inside the VM. The direction is the safe one: guest code never touches the host daemon.

Does Testcontainers work inside a smolvm machine?

Yes. The Docker in a Machine guide covers Testcontainers, Docker Compose, and image builds. One adjustment is required: dynamically allocated ports are not automatically published through the VM boundary, so pin the ports the host must reach with -p host:guest when creating the machine.

Is a microVM automatically safe from container escape?

No. A microVM changes the isolation boundary because the workload runs inside a guest kernel, but vulnerabilities may still exist in the guest, hypervisor, host, virtual device model, or control plane. A safe design also limits network access, mounts, credentials, runtime duration, and image trust.

Conclusion

If your agents need Docker, do not buy that capability with your host's security. Sharing /var/run/docker.sock gives untrusted code root-equivalent control of the host daemon, and withholding it breaks the Testcontainers workflows your agents need to verify their own work. smolvm ends the tradeoff: dockerd runs inside the guest kernel, containers stay inside the hardware-isolated boundary, and the host socket is never shared.

Install smolvm from the open-source repository, follow the Docker in a Machine guide to wire up Testcontainers, and visit Smol Machines to see how the same VM model extends from your laptop to managed cloud capacity.