Firecracker vs Docker: which one runs untrusted code?

"Firecracker vs Docker" is one of the most-searched infrastructure comparisons, and it's slightly the wrong framing — they operate at different layers. Docker is a toolchain for building and running OCI container images; Firecracker is a Virtual Machine Monitor that runs microVMs. You can even run Firecracker microVMs from container images. But people aren't really asking about layers. They're asking: when I need to run code I don't fully trust, which model is safe? On that question, the two diverge sharply.

The core difference: shared kernel vs separate kernel

A Docker container is a Linux process with a private view of the system, created by kernel features — namespaces (what it can see) and cgroups (what it can use). Crucially, it runs on the host's kernel. Every container on a machine shares that one kernel. That's why containers are so light: there's no second OS to boot.

A Firecracker microVM boots its own guest kernel and is confined by hardware virtualization (KVM). The guest can only interact with the outside world through a tiny set of emulated virtio devices. There is no shared kernel to attack. An exploit would have to escape the hypervisor itself — a vastly smaller and more heavily audited surface than the full Linux syscall interface a container sees.

Side by side

• Isolation — Docker: namespaces + cgroups on the shared host kernel. Firecracker: hardware-virtualized microVM with its own guest kernel.
• Untrusted/AI-generated code — Docker: risky (kernel-sharing). Firecracker: designed for it (AWS Lambda runs every function this way).
• Cold start — Docker: ms to seconds (image pull, runtime init). Firecracker: a few ms to boot; ~180ms in practice when restoring a snapshot.
• Memory overhead — Docker: ~none beyond the process. Firecracker: a few MB per guest for the kernel + device model.
• What it actually is — Docker: build + run OCI images. Firecracker: a VMM that runs microVMs (often from those same images).
• Best fit — Docker: trusted first-party services, dev environments, packaging. Firecracker: multi-tenant, untrusted, or AI-generated workloads.

What about gVisor, Kata, and "secure containers"?

There's a middle ground. gVisor intercepts syscalls in a user-space kernel to shrink the host-kernel surface without a full VM. Kata Containers wrap containers in lightweight VMs (and can use Firecracker as the VMM) to get a container UX with VM isolation. These exist precisely because plain Docker isn't enough for untrusted multi-tenancy. They're real options — but they're acknowledging the same gap: a shared host kernel is not a security boundary you want to bet someone else's code against.

When to use each

Use Docker when you control the code: packaging your services, local development, CI build steps, internal tools. The kernel-sharing risk is yours, and the simplicity and ecosystem are unbeatable.

Reach for Firecracker (or a platform built on it) the moment the code is untrusted, multi-tenant, or generated at runtime: AI agents executing model-written commands, per-user code playgrounds, code interpreters, ephemeral CI runners for arbitrary repos, or per-customer isolated databases. This is exactly the line PandaStack is built on — every sandbox, database, and app is its own Firecracker microVM, created in ~179ms via snapshot-restore so the VM-grade isolation costs you almost nothing in latency.

So the honest answer to "Firecracker vs Docker": they're complementary, not rivals — you'll often build with Docker and run with Firecracker. But if the question behind your question is "can this safely run untrusted code," Docker alone says no and Firecracker says yes.