Runtime runs each sandbox as a Firecracker microVM instead, with its own
kernel. Docker runs inside it after sudo enable-docker. You keep the
container tools you know. The code in them sits behind a virtual machine
boundary, not the host's kernel (the sandbox environment).
What makes a container
Docker's own introduction describes containers as "isolated processes for each of your app's components": self-contained, isolated, independent and portable. The isolation comes from features of the Linux kernel, not from separate hardware:
- Namespaces give the process its own view of process IDs, mounts, network, users and hostname (Linux namespaces).
- Control groups cap and count its CPU, memory and I/O (cgroups).
- seccomp filters which system calls it may make (seccomp).
- An image supplies its filesystem: an application and everything it needs, in layers.
Container or virtual machine
Docker's page puts the difference in one line each: "a VM is an entire operating system with its own kernel", while "a container is simply an isolated process with all of the files it needs to run". Sharing the kernel makes containers small and quick to start. It is also their weak point. A kernel bug reachable from inside is a way out (container escape).
| Property | Container | MicroVM on Runtime |
|---|---|---|
| Kernel | The host's, shared | Its own |
| Boundary for untrusted code | System-call filtering | Hardware virtualization |
| Start | Milliseconds to seconds | A new microVM per create, from a machine started ahead of time for the common shapes |
| Runs Docker inside | Only with privileges | Yes, as a normal user with sudo |
When a container is enough
For your own trusted code, a container is the right tool. For code an agent wrote, a user pasted or a package installed, a separate kernel is the safer default. That is why agent sandboxes moved to microVMs.
Related
Sources
Checked 25 October 2026.