MicroVMs vs containers: why each sandbox is a microVM

What is the difference between a container and a microVM?

A container isolates code with Linux namespaces and cgroups on the host's own kernel, while a microVM gives code its own kernel behind hardware virtualization. gVisor sits between the two. Sandboxer's guide on container vs microVM for untrusted code summarizes the three boundaries:

Why does a shared kernel matter for agents?

A shared kernel matters because one exploitable kernel bug becomes a way out for every container on that host. The same guide lists the usual ways a container sandbox leaks:

• Mounting the host's Docker socket, which hands over control of the host
• Running with --privileged so Docker-in-Docker works
• Kernel bugs reachable from any container
• Host paths, host networking or credential files mounted in for convenience

Inside a microVM, the first two stop being risky: the code gets its own Docker daemon and its own root, inside its own VM. A kernel bug then stays inside the guest unless it can also break the hypervisor.

What does a Sandboxer microVM look like?

Each sandbox runs Ubuntu 24.04 on Sandboxer's own kernel build under Cloud Hypervisor, with its own root filesystem, network stack and process tree. You work as an ordinary user with sudo. Because it is a real machine, the things that need workarounds in containers simply work:

• systemd, so services you enable come back after a resume
• Docker with BuildKit and Compose, without privileged mode
• /dev/kvm, so QEMU, Firecracker and the Android emulator run accelerated

The four sizes, from small to xlarge, are the same machine with the same features. See Docker and nested virtualization.

Are microVMs slower than containers?

A microVM boots a kernel and uses more memory than a container, so there is some extra cost per sandbox. For agent work that runs for minutes or hours, Sandboxer's guide notes that the startup difference rarely matters.

Sandboxer also keeps booted, paused sandboxes ready in each region, so a new sandbox from the standard image usually does not boot at all. Its docs report a median of 0.18 seconds from create to ready in us-east, measured on 2026-10-28, and about 1.3 to 2 seconds when no ready sandbox of that size is available.

Does a microVM make everything safe?

No. A microVM narrows the escape routes, but some risks remain your responsibility:

Sandboxer helps with no-secret sandboxes and scoped keys, covered in security and isolation.

How do other sandbox services compare?

Sandboxer publishes comparison pages that it says are based on each provider's own public docs. In those pages, E2B and Vercel Sandbox are described as using Firecracker microVMs, Modal as using gVisor by default, and Daytona as offering many sandbox classes, from containers to VMs, plus Windows and GPUs. Each makes different trade-offs, and Sandboxer's own guides point readers to other services for needs it does not cover, such as GPUs or Windows.