Which sandbox providers offer “its own virtual machine”?

Each sandbox is a separate virtual machine (microVM or full VM), not a container sharing a kernel with neighbours. Fully: Blaxel, Boat, Cloudflare Sandbox, E2B, InstaBox, Lizard, Morph, Runtime, Sandboxer, Sprites, Vercel Sandbox and boxd. With a catch: Agent 37, Daytona, Modal and Tensorlake.

Which sandbox providers offer “root access”?

You (and the agent) can act as the administrator: install anything, change system settings. Fully: Agent 37, Blaxel, Boat, Cloudflare Sandbox, Daytona, E2B, InstaBox, Lizard, Modal, Morph, Runtime, Sandboxer, Sprites, Tensorlake, Vercel Sandbox and boxd.

Which sandbox providers offer “docker inside”?

You can run Docker containers inside the sandbox. Fully: Blaxel, Boat, Daytona, E2B, InstaBox, Morph, Runtime, Sandboxer, Tensorlake, Vercel Sandbox and boxd. With a catch: Agent 37, Cloudflare Sandbox, Modal and Sprites.

Which sandbox providers offer “nested virtualisation”?

You can start virtual machines inside the sandbox, for tools that need their own VM. Fully: Boat, Runtime, Sandboxer and Tensorlake. With a catch: Agent 37, Daytona, Modal and Morph.

Which sandbox providers offer “your own image”?

Start machines from your own Dockerfile or image instead of the provider's default. Fully: Agent 37, Blaxel, Cloudflare Sandbox, Daytona, E2B, Modal, Runtime, Tensorlake and Vercel Sandbox. With a catch: InstaBox, Morph, Sandboxer and boxd. Not at all: Boat, Lizard and Sprites.

Isolation: what kind of computer you get

The idea

A sandbox is a boundary before it is a computer. The boundary is drawn by the host: a container shares the host's kernel, a virtual machine has its own. The stronger the boundary, the more the inside behaves like a real server, and the more it costs to start.

Four kinds show up in this market. A container shares the host kernel and is the weakest boundary. gVisor intercepts system calls in user space, which is stronger than a container but still not a kernel of its own. A microVM, usually Firecracker or Cloud Hypervisor, has its own kernel and starts in milliseconds. A full VM is the same idea with a conventional machine model, and it is the only kind where nested virtualisation is routinely expected.

The boundary and the capability list are different things. A microVM can still refuse kernel modules, omit systemd, or ship without Docker. So the useful question is not “is it a VM?” but “what can I run inside it, and what happens when the agent breaks it?”

Where providers split

The claim on the left, the provider's own words on the right

The default type is often the weaker one

Agent 37's default instance is a gVisor container. Docker does not work there; you choose the vm type, at 2.5× the compute rate, to get a real kernel. Its own docs describe the vm type as being for Docker, Kubernetes, databases and Android emulators.

Most of the others make the microVM the default: E2B, Vercel, Sandboxer, InstaBox, Lizard, Runtime and Sprites all describe a per-sandbox kernel. Morph goes further and sells full VMs with Docker-in-Docker and systemd as the normal case.

A real kernel does not guarantee a normal server

Sprites is a hardware-isolated microVM, but it does not run systemd; its own service manager starts services on wake. Blaxel's default kernel refuses module loading and kernel tracing to every process, including root, and iptables has to be enabled at creation. Lizard documents root but not whether a Docker daemon runs inside.

E2B is the opposite asymmetry: the boundary is strong, but the default template user is an ordinary user, not root. Root is a template choice, not the default.

One worked case

The same job at every provider, from the documented defaults

The build needs Docker and a kernel module

Your agent clones a repository, runs a Docker build, then loads a kernel module for a database test. Three steps, and the boundary decides which of them can finish.

Step 1
git clone and a test run. Every provider in this set can do this.
Step 2
docker build. A container boundary without a Docker daemon fails here, and a gVisor default may fail even with one.
Step 3
modprobe. This needs a real kernel with module loading enabled, which is a different promise from "has its own kernel".

The marketing word is the same — sandbox, microVM, VM — but the third step is where a per-sandbox kernel stops being enough. Check the capability list, not the boundary name.

What each provider does

Agent 37: docker build fails on the default gVisor type; recreating on the vm type works and costs 2.5× the compute rate.
Blaxel: Docker runs, then modprobe is refused for every process, root included.
Boat: Clone, build and load the module without a workaround: own kernel, Docker, root, SSH.
boxd: Everything works, and breaking the OS stays inside the machine rather than reaching a neighbour.
Cloudflare Sandbox: The build runs in the microVM's own kernel with Docker-in-Docker, but every process is root and nothing separates two users inside it.
Daytona: Docker runs on the default container through Docker-in-Docker, but loading a kernel module needs the Linux VM class.
E2B: Docker is documented, but the default template runs as user rather than root and at least one kernel module is missing.
InstaBox: Root, passwordless sudo and Docker are in the default image, so both steps work unchanged.
Lizard: Root is the default, but whether a Docker daemon runs inside a sandbox is not documented either way.
Modal: The default gVisor container runs the build; mounting FUSE or running Docker needs runtime="vm".
Morph: A full VM with Docker-in-Docker, systemd and root; nested virtualisation is documented as experimental.
Runtime: New sandboxes expose /dev/kvm, so the build can start its own nested VM.
Sandboxer: Docker with BuildKit and Compose, systemd and /dev/kvm all work as on a normal host.
Sprites: Docker is reported to work, but systemd does not run; services start through the built-in manager when the Sprite wakes.
Vercel Sandbox: Docker and FUSE work as root; systemd and nested virtualisation are not published, so a systemd unit is a guess.
Tensorlake: A real microVM: a nested QEMU VM boots on /dev/kvm, and Docker runs once you pick the systemd image and install it.

What to watch for

The details that decide the answer in practice

01
Docker on the default type: at Agent 37 it needs the vm type at 2.5× the rate.
02
systemd: Sprites does not run it, and several providers do not document it either way.
03
Kernel modules: Blaxel refuses them by default; E2B's kernel is missing at least one module.
04
Nested virtualisation: Runtime exposes /dev/kvm; Sandboxer and Morph document it, Morph as experimental.
05
Root inside the guest is not root on the host, whatever the provider's marketing implies.

Compare all 16

Docs read 28 October 2026

Every provider says “sandbox”. Underneath, it is a container, a gVisor container, a microVM or a full virtual machine, and that decides what your agent can install, run and break.
Provider	Boundary, and what it allows	Does it?	What that means
Agent 37	gVisorVM at 2.5×	Partly	A gVisor container by default, with no Docker; the vm type gives a real kernel at 2.5× compute, and performance gives dedicated cores at 4×.Agent 37 docs: VM instances — default gVisor container vs full VM with its own kernel ↗ Agent 37's own wordsdocs-confirmed “vm is a whole virtual machine with its own kernel, for Docker, Kubernetes, databases, and Android emulators, at 2.5x the default compute rate” Agent 37docs-confirmed
Blaxel	microVMno modules	Partly	A microVM boundary, root by default, but the default kernel refuses module loading and kernel tracing, and iptables needs enabling at creation.Blaxel docs: Run sandbox workloads as a non-root user ↗ Blaxel's own wordsdocs-confirmed “the microVM boundary remains the isolation guarantee between your sandbox and everything else.” Blaxeldocs-confirmed
Boat	Full VMDocker, root	Yes	A full Ubuntu VM with its own kernel, Docker, SSH and root. The closest thing here to an ordinary server.Boat docs: Security and isolation ↗ Boat's own wordsdocs-confirmed “boat gives you full Ubuntu virtual machines (sandboxes) for AI agents and code, billed per second.” Boatdocs-confirmed
boxd	KVM microVMroot	Yes	A KVM microVM with its own kernel, network stack and disk. Docker, systemd, kernel modules and breaking the OS all stay inside the machine.boxd docs: Sandboxes (hardware isolation) ↗ boxd's own wordsdocs-confirmed “Every boxd machine is a KVM microVM with its own kernel, network stack, and disk.” boxddocs-confirmed
Cloudflare Sandbox	Firecrackerall root	Yes	One Firecracker microVM per container with its own kernel and network; the image runs as a Linux container inside it. Every process has root capabilities, so there is no privilege boundary between users. No memory snapshot, pause or fork.Cloudflare Sandbox docs: Lifecycle of a Container (microVM per container) ↗ Cloudflare Sandbox's own wordsdocs-confirmed “Each container instance runs in a Firecracker microVM with its own kernel and network.” Cloudflare Sandboxdocs-confirmed
Daytona	ContainersVM on request	Partly	Linux containers by default: dedicated namespaces, enforced resource limits and root inside, sharing the runner's kernel. Linux VM and Windows classes have their own kernel. Docker-in-Docker is documented; nested virtualisation is Linux-VM only and must be enabled.Daytona docs: Isolation (container, Linux VM, Windows and GPU classes) ↗ Daytona's own wordsdocs-confirmed “Full virtual machine with its own kernel.” Daytonadocs-confirmed
E2B	Firecrackernon-root user	Yes	A Firecracker microVM with its own kernel. Docker is documented, but the default template user is user, not root, and some kernel modules are missing.E2B docs: How sandboxes are isolated (Firecracker microVMs) ↗ E2B's own wordsdocs-confirmed “not a container. Each one boots its own kernel” E2Bdocs-confirmed
InstaBox	Firecrackerroot + Docker	Yes	A Firecracker microVM running Debian 13 with its own kernel, root, passwordless sudo and Docker.InstaBox docs: Limits — Firecracker microVM, own kernel, Debian 13 ↗ InstaBox's own wordsdocs-confirmed “A whole machine, with its own kernel.” InstaBoxdocs-confirmed
Lizard	Firecrackerroot	Partly	A Firecracker microVM with its own kernel and root by default, but Docker inside a sandbox is not documented either way.Lizard docs: Sandboxes — Firecracker microVM, own kernel, templates ↗ Lizard's own wordsdocs-confirmed “Sandboxes run as Firecracker microVMs, each with its own kernel.” Lizarddocs-confirmed
Modal	gVisorVM on request	Partly	gVisor by default, with a KVM VM runtime opt-in for Docker, FUSE or nested cgroups. Every container runs as root, and GPU sandboxes are gVisor only. Up to 250 sidecars per sandbox give a second boundary.Modal docs: Sandboxes: runtimes (gVisor vs VM) ↗ Modal's own wordsdocs-confirmed “VMs run the Sandbox in a virtual machine with its own Linux kernel.” Modaldocs-confirmed
Morph	Full VMDocker-in-Docker	Yes	Full VMs with Docker-in-Docker, systemd, root and FUSE. Nested virtualisation and other guest operating systems are experimental.Morph docs: Getting started with Morph Devboxes ↗ Morph's own wordsdocs-confirmed “Full virtual machines capable of running any configuration of containers: docker‑in‑docker, a local Kubernetes cluster, self‑hosted Supabase, etc.” Morphdocs-confirmed
Runtime	Firecracker/dev/kvm	Yes	A Firecracker microVM with its own kernel, and new sandboxes expose /dev/kvm, so nested virtualisation works.Runtime docs: Isolation and account boundaries ↗ Runtime's own wordsdocs-confirmed “Runtime Cloud is a cloud for AI agents' code: Linux sandboxes, each a Firecracker microVM” Runtimedocs-confirmed
Sandboxer	Cloud Hypervisor/dev/kvm	Yes	A Cloud Hypervisor microVM with its own kernel, systemd, Docker with BuildKit and Compose, and /dev/kvm.Sandboxer docs: Security ↗ Sandboxer's own wordsdocs-confirmed “Each sandbox is a separate Cloud Hypervisor microVM with its own kernel.” Sandboxerdocs-confirmed
Sprites	microVMno systemd	Partly	A hardware-isolated microVM with root and Docker reported, but it does not run systemd: a built-in service manager starts services on wake.Sprites docs: Sprites Overview ↗ Sprites's own wordsdocs-confirmed “Sprites don't run systemd; the log files and the create/start streams are how you see service output.” Spritesdocs-confirmed
Vercel Sandbox	Firecrackerroot + Docker	Partly	A Firecracker microVM with a dedicated kernel, root, Docker and FUSE. systemd and nested virtualisation are not published.Vercel Sandbox docs: Sandbox concepts: isolation architecture ↗ Vercel Sandbox's own wordsdocs-confirmed “each sandbox runs in its own Firecracker microVM with a dedicated kernel.” Vercel Sandboxdocs-confirmed
Tensorlake	Firecracker/dev/kvm	Yes	A Firecracker microVM with its own kernel, root and /dev/kvm, so KVM-based hypervisors run inside and snapshots still work. Docker needs tensorlake/ubuntu-systemd plus an install step; the default image has no Docker. GPU sandboxes are gVisor instead, without live resize or volume mounts.Tensorlake docs: Sandbox and Orchestration Infrastructure for Agents — microVM by default, gVisor for GPUs ↗ Tensorlake's own wordsdocs-confirmed “Tensorlake provides isolated MicroVM sandboxes that boot in hundreds of milliseconds, with memory and filesystem preserved across suspend/resume.” Tensorlakedocs-confirmed

The specific capabilities

Each one checked for every provider, with the catch where a version falls short. All capabilities

Isolation: capabilities by provider
Capability	Agent 37	Blaxel	Boat	boxd	Cloudflare Sandbox	Daytona	E2B	InstaBox	Lizard	Modal	Morph	Runtime	Sandboxer	Sprites	Tensorlake	Vercel Sandbox
Its own virtual machine	Agent 37: With a catch. gVisor; VM costs 2.5x. The standard machine is a gVisor container, which is not a computer of its own; a true virtual machine with its own kernel is a separate type at 2.5 times the price.	Blaxel: Yes. microVM	Boat: Yes. full VM, own kernel	boxd: Yes. KVM microVM	Cloudflare Sandbox: Yes. Firecracker microVM	Daytona: With a catch. containers by default. By default each sandbox is a container sharing the host's kernel; a real virtual machine is a separate kind you have to choose.	E2B: Yes. Firecracker microVM	InstaBox: Yes. Firecracker microVM	Lizard: Yes. Firecracker microVM	Modal: With a catch. gVisor by default. The default is a gVisor container, which is not a computer of its own; a true virtual machine with its own kernel is a separate runtime you have to ask for.	Morph: Yes. full VM	Runtime: Yes. Firecracker microVM	Sandboxer: Yes. Cloud Hypervisor microVM	Sprites: Yes. microVM	Tensorlake: With a catch. VM, except GPU. The ordinary machines are real virtual machines, but the graphics-card machines you have to ask for are containers instead.	Vercel Sandbox: Yes. Firecracker microVM
Root access	Agent 37: Yes. root on request	Blaxel: Yes. root by default	Boat: Yes. passwordless sudo	boxd: Yes. passwordless sudo	Cloudflare Sandbox: Yes. every process is root	Daytona: Yes. root in the sandbox	E2B: Yes. root via template. The default template runs as an ordinary user called user, not root; root has to be set in the template.	InstaBox: Yes. passwordless sudo	Lizard: Yes. root by default	Modal: Yes. always root	Morph: Yes. root shell	Runtime: Yes. sudo, then root	Sandboxer: Yes. sudo inside	Sprites: Yes. sudo	Tensorlake: Yes. sudo or --user root	Vercel Sandbox: Yes. full root
Docker inside	Agent 37: With a catch. VM type only. Docker only works on the 2.5x VM type; the default machine cannot run a Docker daemon.	Blaxel: Yes. docker-in-sandbox image	Boat: Yes. Docker, Compose, BuildKit	boxd: Yes. Docker preinstalled	Cloudflare Sandbox: With a catch. docker:dind, no iptables. Docker works through a special image, but the firewall tool Docker normally uses is turned off, so container networking is limited.	Daytona: Yes. Docker-in-Docker	E2B: Yes. Docker image documented	InstaBox: Yes. Docker on default image	Lizard: Not published	Modal: With a catch. VM runtime only. Docker needs the VM runtime; the default gVisor sandbox cannot run it.	Morph: Yes. Docker-in-Docker	Runtime: Yes. enable-docker	Sandboxer: Yes. Docker preinstalled	Sprites: With a catch. Docker, with limits. Docker runs, but some containers fail and the usual service manager is missing, so services need the provider's own manager instead.	Tensorlake: Yes. needs ubuntu-systemd image	Vercel Sandbox: Yes. Docker inside
Nested virtualisation	Agent 37: With a catch. VM type only. Starting a virtual machine inside needs hardware virtualisation, which only the 2.5x VM type has.	Blaxel: Not published	Boat: Yes. /dev/kvm, no flag	boxd: Not published	Cloudflare Sandbox: Not published	Daytona: With a catch. Linux VM class only. Nested virtual machines only work on the Linux VM class, and the feature has to be switched on for your organisation.	E2B: Not published	InstaBox: Not published	Lizard: Not published	Modal: With a catch. Enterprise plan only. Nested virtual machines are an Enterprise-plan option that must be switched on when the sandbox is created.	Morph: With a catch. experimental. Running another operating system or a virtual machine inside is described as experimental.	Runtime: Yes. /dev/kvm	Sandboxer: Yes. /dev/kvm	Sprites: Not published	Tensorlake: Yes. /dev/kvm	Vercel Sandbox: Not published
Your own image	Agent 37: Yes. Dockerfile or registry	Blaxel: Yes. Dockerfile images	Boat: No. one image for everyone. There is no way to bring your own image or build recipe; you install what you need and save a copy of the machine instead.	boxd: With a catch. snapshot only. You cannot bring a Docker image; the way to get your own setup is to customise a machine and start new ones from a snapshot of it.	Cloudflare Sandbox: Yes. your own Dockerfile	Daytona: Yes. Dockerfile or OCI image	E2B: Yes. any Docker image	InstaBox: With a catch. operator-built templates. You pick from fixed images or a saved copy; a different starting image needs an operator to build one for you.	Lizard: No. fixed template catalog. You choose from a fixed list of templates and cannot upload your own image.	Modal: Yes. any registry image	Morph: With a catch. templates and snapshots. There is no documented way to import your own image; you start from a template or from a snapshot you saved.	Runtime: Yes. custom images	Sandboxer: With a catch. snapshot templates. You cannot start from your own image; you set a machine up and save its disk as a template.	Sprites: No. fixed base image. There is no documented way to start a Sprite from your own image.	Tensorlake: Yes. Dockerfile builds	Vercel Sandbox: Yes. custom image or snapshot

YesWith a catchNoNot publishedHover or select a mark to see the catch.

Questions to ask before you sign

Each one targets something the documentation does not answer

What boundary does the default instance get, and what does the stronger one cost? Agent 37 charges 2.5× for a real kernel.
Does Docker work on the default type without changing image, size or instance type?
Does the guest run systemd, and if not, what starts services when the machine wakes?
Can the agent load kernel modules or open /dev/kvm, and is either documented as experimental?
Which user does the default template run as, and is root a documented option or a custom image?

Common questions

Answered from the capability checks; each links to the provider-by-provider detail and its sources

Which sandbox providers offer “its own virtual machine”?: Each sandbox is a separate virtual machine (microVM or full VM), not a container sharing a kernel with neighbours. Fully: Blaxel, Boat, Cloudflare Sandbox, E2B, InstaBox, Lizard, Morph, Runtime, Sandboxer, Sprites, Vercel Sandbox and boxd. With a catch: Agent 37, Daytona, Modal and Tensorlake. See each provider's catch
Which sandbox providers offer “root access”?: You (and the agent) can act as the administrator: install anything, change system settings. Fully: Agent 37, Blaxel, Boat, Cloudflare Sandbox, Daytona, E2B, InstaBox, Lizard, Modal, Morph, Runtime, Sandboxer, Sprites, Tensorlake, Vercel Sandbox and boxd. See each provider's catch
Which sandbox providers offer “docker inside”?: You can run Docker containers inside the sandbox. Fully: Blaxel, Boat, Daytona, E2B, InstaBox, Morph, Runtime, Sandboxer, Tensorlake, Vercel Sandbox and boxd. With a catch: Agent 37, Cloudflare Sandbox, Modal and Sprites. See each provider's catch
Which sandbox providers offer “nested virtualisation”?: You can start virtual machines inside the sandbox, for tools that need their own VM. Fully: Boat, Runtime, Sandboxer and Tensorlake. With a catch: Agent 37, Daytona, Modal and Morph. See each provider's catch
Which sandbox providers offer “your own image”?: Start machines from your own Dockerfile or image instead of the provider's default. Fully: Agent 37, Blaxel, Cloudflare Sandbox, Daytona, E2B, Modal, Runtime, Tensorlake and Vercel Sandbox. With a catch: InstaBox, Morph, Sandboxer and boxd. Not at all: Boat, Lizard and Sprites. See each provider's catch

Part of The machine. Next: put two or three providers side by side.