Which should you use, Firecracker or Docker?
It depends on whether you trust the code. For agents that run code a model wrote, Runtime builds your Dockerfile into a Firecracker microVM per sandbox, so you keep Docker's workflow and get a kernel of your own. Pick Docker for your own code: local development, CI and services where one shared kernel is what you want. Pick Firecracker on your own hosts if you want to run the VMs yourself.
They solve different problems
Docker builds and runs containers. A container is, in Docker's words, "simply an isolated process with all of the files it needs to run." The Docker daemon starts it on the host's kernel and fences it with namespaces, control groups, a reduced set of capabilities and a default seccomp profile that "disables around 44 system calls out of 300+."
Firecracker is a virtual machine monitor: one process per microVM that uses Linux KVM to create a virtual machine and boot a guest kernel. Over its RESTful API it starts a microVM from "a given kernel image, root file system, and boot arguments". The guest sees what Firecracker's site counts as "only 5 emulated devices".
So the real comparison is the isolation boundary for a workload: the shared host kernel of a container, or a guest kernel behind hardware virtualization.
Side by side
| Docker (default runtime) | Firecracker | |
|---|---|---|
| What it is | A container platform: build, registry, daemon, runtime | A virtual machine monitor on KVM |
| Isolation boundary | Namespaces, cgroups, capabilities, seccomp | Hardware virtualization, then seccomp and a jailer on the VMM |
| Kernel | The host's, shared by every container | A guest kernel per microVM |
| Attack surface to host | Host system calls, minus about 44 blocked by default | 5 emulated devices, in the project's count, and the VMM's filtered calls |
| Input | An OCI image | A kernel image and a root filesystem |
| Start time | No figure published | Up to 125 ms to guest init, in the project's specification |
| Memory overhead | No figure published | Up to 5 MiB for the VMM on a 1 vCPU, 128 MiB guest |
| Privileges | The daemon runs as root by default; rootless mode exists | The jailer drops privileges before the VMM starts |
| Who uses it | Container workloads; Daytona's sandboxes by default | AWS Lambda and Fargate; E2B, Vercel Sandbox, Runtime |
Firecracker's figures are from its specification, measured on AWS metal hosts with a minimal guest. They cover the monitor, not a full sandbox with a toolchain. Docker warns that "only trusted users should be allowed to control your Docker daemon."
Can Firecracker run Docker images?
Not directly: Firecracker boots a kernel and a root filesystem, not an OCI image. Two common routes bridge the gap:
- Kata Containers is an OCI runtime that can boot each pod in a Firecracker microVM, so Docker-style images run behind a VM boundary. See Kata Containers vs Firecracker.
- A platform that converts the image. Runtime builds a sandbox image from any Dockerfile or public or private container image, and each build runs in its own Firecracker virtual machine (images).
Can Docker run inside Firecracker?
Yes. In a Runtime sandbox, sudo enable-docker installs Docker Engine, Buildx and Compose, and the first
docker command starts it (Docker). The
containers share the sandbox's kernel, not the host's.
TypeScriptimport { Sandbox } from "withruntime";await using sbx = await Sandbox.create({ diskMiB: 8192 });await sbx.exec("sudo enable-docker", { check: true, timeoutMs: 300_000 });const run = await sbx.exec("docker run --rm hello-world", { timeoutMs: 300_000 });console.log(run.stdout);Pythonfrom withruntime import Sandboxwith Sandbox.create(disk_mib=8192) as sbx: sbx.exec("sudo enable-docker", check=True, timeout_ms=300_000) run = sbx.exec("docker run --rm hello-world", timeout_ms=300_000) print(run.stdout)Images and containers live on the sandbox's disk, so give a sandbox that runs containers more than the default 4 GiB.
When each fits
- Pick Docker for your own code: local development, CI and services you trust, where one kernel for everything is what you want.
- Pick Firecracker when the code is untrusted or belongs to someone else: model-written code, user submissions, multi-tenant jobs. A kernel bug then reaches one throwaway guest.
- Pick both when untrusted code needs containers: Docker inside a microVM.
Runtime Cloud
Runtime puts your Dockerfile in a Firecracker microVM, so you keep Docker's workflow and get a kernel per sandbox. A Runtime image builds from any Dockerfile or container image, and every sandbox is a Firecracker microVM.
Build your Dockerfile into a sandbox on the free usage after npx withruntime login. If your agent runs on another sandbox provider now, see the migration
guide.
Why Runtime chose Firecracker
Agents run code nobody reviewed. A kernel per sandbox keeps that code off the
host's kernel, and the host enforces network rules, CPU, memory and cost from
outside the guest, so sudo inside changes none of them
(security). Every sandbox runs Ubuntu 24.04 with Python
3.12, Node.js 24, Bun, git and gcc, and a paused sandbox keeps its memory and
running processes while you have credit.
Try it free: 100 free hours of a 1 GB machine in the first 30 days, no card:
Terminalnpx withruntime sandboxes run -- uname -aMore: microVM vs container, what is Firecracker?, run Docker in a sandbox, custom images.
Sources
Checked 26 October 2026.
- Docker: what is a container?, Docker Engine security, seccomp profiles
- Firecracker, README, specification, design
- Kata Containers
- Provider isolation from Runtime's comparisons, checked 25 October 2026: E2B, Vercel Sandbox, Daytona
Facts on this page were checked on 26 October 2026.