# Kata Containers vs Firecracker: what is the difference?

Firecracker is a virtual machine monitor; Kata Containers is a container runtime that runs each pod in a VM and can use Firecracker for it.

**Runtime gives you the result without the cluster: every sandbox is its own
Firecracker microVM, created by one API call.** A new sandbox ran its first
Python command 351 ms after the create request at the median, measured over
the public internet on 24 September 2026 ([speed](/docs/speed)).

## Different layers of the same stack

The two are not rivals so much as layers. Firecracker's own README lists Kata
Containers as one of the container runtimes it has been integrated into.

**Firecracker** is the machine. It is a Rust virtual machine monitor that uses
Linux KVM to run microVMs, one process per microVM, with what its site counts
as "only 5 emulated devices". You drive it through a RESTful API: give it a
kernel, a root filesystem and boot arguments, and it starts the guest. It knows
nothing about container images or Kubernetes.

**Kata Containers** is the container runtime. It describes itself as
"lightweight virtual machines that seamlessly plug into the containers
ecosystem." Its shim, containerd-shim-kata-v2, speaks the containerd and CRI-O
interfaces, so Kubernetes schedules pods as usual, selected with a
RuntimeClass. For each pod Kata starts a VM with its own guest kernel, runs a
kata-agent inside it to manage the containers, and shares the container's root
filesystem into the VM with virtio-fs. The VM itself comes from a hypervisor
Kata supports: Cloud Hypervisor, Firecracker, QEMU, Dragonball or StratoVirt.

## Side by side

|                      | Kata Containers                                                    | Firecracker                                                |
| -------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------- |
| What it is           | An OCI container runtime that runs pods in lightweight VMs         | A virtual machine monitor on KVM                           |
| Isolation boundary   | Hardware virtualization, from the hypervisor it is configured with | Hardware virtualization through KVM                        |
| Kernel               | A guest kernel per pod                                             | A guest kernel per microVM                                 |
| Unit                 | A Kubernetes pod or container                                      | A microVM from a kernel and a root filesystem              |
| Interface            | containerd shim v2, CRI-O, Kubernetes RuntimeClass                 | A RESTful API per Firecracker process                      |
| Hypervisors          | Cloud Hypervisor, Firecracker, QEMU, Dragonball, StratoVirt        | Is the hypervisor                                          |
| Start time           | No figure published; depends on the hypervisor                     | Up to 125 ms to guest init, in the project's specification |
| Memory overhead      | No figure published; depends on the hypervisor                     | Up to 5 MiB for the VMM on a 1 vCPU, 128 MiB guest         |
| GPUs                 | Through QEMU, which Kata calls best supported for NVIDIA GPUs      | Not supported, per Kata's hypervisor table                 |
| Architectures        | x86_64, aarch64, ppc64le, s390x                                    | x86_64, aarch64                                            |
| Language and licence | Rust and Go, Apache 2.0                                            | Rust, Apache 2.0                                           |
| Who uses it          | Baidu, for function computing and container instances              | AWS Lambda and Fargate; E2B, Vercel Sandbox, Runtime       |

Firecracker's figures come from its specification, measured on AWS metal hosts
with a minimal guest; they cover the monitor alone. Kata says it delivers
"consistent performance as standard Linux containers" but publishes no single
start or memory figure on its site.

## When each fits

- **Pick Kata Containers** when you already run Kubernetes and want some pods,
  or all of them, in VMs without changing images or manifests beyond a
  RuntimeClass. Choose QEMU under it when you need GPUs or confidential
  computing (Intel TDX, AMD SEV-SNP), which Kata's table lists only for QEMU.
- **Pick Firecracker directly** when you are building a platform whose unit is
  the machine, not the pod: functions, sandboxes, per-user environments. You
  get the smallest device model and a monitor built for many small tenants, and
  you write the orchestration yourself.
- **Pick Kata with Firecracker** for Kubernetes pods on Firecracker's minimal
  device model, if its feature set covers your workloads.

## Why Runtime uses Firecracker directly

A sandbox is a whole machine an agent can install into, pause and fork, not a
pod in a cluster. Runtime runs one Firecracker microVM per sandbox on dedicated
servers it operates:

- **Its own kernel and disk.** Ubuntu 24.04, Python 3.12, Node.js 24, Bun, git
  and gcc; `sudo` works; Docker runs inside after `sudo enable-docker`.
- **Controls outside the guest.** Network rules, CPU, memory and cost are
  enforced on the host, so root in the sandbox cannot change them
  ([security](/docs/security)).
- **Whole-machine state.** A paused sandbox keeps files, memory and running
  processes for 1 to 365 days; a fork makes 1 to 10 running copies with memory
  and processes.
- **Images from your Dockerfile.** Any Dockerfile or container image becomes a
  sandbox image, built in its own Firecracker guest ([images](/docs/images)).

Runtime sandboxes run on CPUs; for GPU work, Kata with QEMU or a GPU provider
fits better.

```ts
import { Sandbox } from "withruntime";

await using sbx = await Sandbox.create();
const run = await sbx.exec("uname -r"); // this sandbox's own kernel
console.log(run.stdout);
```

```python
from withruntime import Sandbox

with Sandbox.create() as sbx:
    run = sbx.exec("uname -r")  # this sandbox's own kernel
    print(run.stdout)
```

New accounts get 50 free sandbox hours, no card:

```bash no-run
npx withruntime sandbox run --trial -- uname -r
```

More: [what is Firecracker?](/glossary/firecracker),
[what is a microVM?](/glossary/microvm),
[Firecracker vs Docker](/compare/firecracker-vs-docker),
[Firecracker vs gVisor](/compare/firecracker-vs-gvisor).

## Sources

Checked 25 September 2026.

- [Kata Containers](https://katacontainers.io/), [repository](https://github.com/kata-containers/kata-containers), [architecture](https://github.com/kata-containers/kata-containers/blob/main/docs/design/architecture/README.md), [hypervisors](https://github.com/kata-containers/kata-containers/blob/main/docs/hypervisors.md)
- [Firecracker](https://firecracker-microvm.github.io/), [README](https://github.com/firecracker-microvm/firecracker), [specification](https://github.com/firecracker-microvm/firecracker/blob/main/SPECIFICATION.md)
- Provider isolation from Runtime's comparisons, checked 23 September 2026: [E2B](/docs/e2b-alternative), [Vercel Sandbox](/docs/vercel-sandbox-alternative)

Facts on this page were checked on 25 September 2026.