Runtime

Firecracker vs Docker: what is the difference?

Docker runs containers that share the host's Linux kernel; Firecracker runs microVMs that each boot a Linux kernel of their own on KVM.

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, every sandbox is a Firecracker microVM, and a new sandbox ran its first Python command 351 ms after the create request at the median, measured on 24 September 2026 (speed).

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 under 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 them:

  • 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 the point.
  • 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.

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 for 1 to 365 days.

Try it on the free trial, 50 sandbox hours with no card:

Terminalnpx withruntime sandbox run --trial -- uname -a

More: microVM vs container, what is Firecracker?, run Docker in a sandbox, custom images.

Sources

Checked 25 September 2026.

Facts on this page were checked on 25 September 2026.

Claim 50 hours free