Runtime

What is a container?

A container is a process the Linux kernel isolates with its own filesystem, network and process view, sharing the host's kernel.

Runtime runs each sandbox as a Firecracker microVM instead, with its own kernel, and Docker runs inside it after sudo enable-docker. You keep the container tools you know, and the code in them sits behind a virtual machine boundary rather than 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 is what makes containers small and quick to start, and 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 221 ms server-side to a first Python result, median
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, which is why agent sandboxes moved to microVMs.

Sources

Checked 27 September 2026.