# What is the Firecracker jailer?

The jailer is a Firecracker program that chroots, namespaces and cgroups a Firecracker process, drops its privileges, then starts it.

**Runtime runs the Firecracker hosts for you, so a sandbox is one API call
rather than a host you harden yourself.** Each sandbox is a Firecracker
microVM with its own Linux kernel, on dedicated servers Runtime operates, and
the first Python command answered 351 ms after the create request at the
median on 24 September 2026 ([speed](/docs/speed)).

## Why Firecracker has a jailer

Firecracker's first barrier is the virtual machine: guest code runs on KVM
behind the processor's virtualization extensions. The jailer is the barrier
behind it, on the host. Its documentation calls it "a program designed to
isolate the Firecracker process in order to enhance Firecracker's security
posture", and the Firecracker site calls it "a second line of defense in case
the virtualization barrier is ever compromised."

The project's production guide is direct: "Firecracker should be started using
the `jailer` binary that's part of each Firecracker release, or executed under
process constraints equal or more restrictive than those in the jailer."

## What the jailer does, in order

1. **Cleans its inputs.** It validates the paths and VM ID, closes every open
   file descriptor except standard I/O and clears the environment it inherited.
2. **Builds the jail directory** at `<chroot_base>/<exec_file_name>/<id>/root`
   and copies the Firecracker binary into it.
3. **Sets limits**: resource limits from `--resource-limit`, then cgroup
   sub-folders holding the process, with values such as `cpuset.cpus=0` passed
   through `--cgroup` ([cgroups](/glossary/cgroups)).
4. **Changes root.** It calls `unshare()` into a new mount namespace, swaps the
   root with `pivot_root()`, unmounts the old one and calls `chroot`.
5. **Adds only two devices** inside the jail with `mknod`: `/dev/net/tun` and
   `/dev/kvm`.
6. **Joins namespaces** it is given: a network namespace with `--netns`, and a
   new PID namespace with `--new-pid-ns`
   ([Linux namespaces](/glossary/linux-namespaces)).
7. **Drops privileges** to the `--uid` and `--gid` it was given, and execs
   Firecracker, which applies its own [seccomp](/glossary/seccomp) filters by
   default before guest code runs.

## Facts

| Option             | What it does, per the jailer documentation                         |
| ------------------ | ------------------------------------------------------------------ |
| `--id`             | The microVM's ID: letters, digits and hyphens, up to 64 characters |
| `--exec-file`      | Path to the Firecracker binary                                     |
| `--uid`, `--gid`   | The unprivileged user and group Firecracker runs as                |
| `--cgroup-version` | Chooses cgroup v1 or v2                                            |
| `--netns`          | Joins an existing network namespace                                |
| `--new-pid-ns`     | Starts Firecracker in a new PID namespace with `CLONE_NEWPID`      |
| `--daemonize`      | Calls `setsid()` and sends standard I/O to `/dev/null`             |

## Why it matters for AI agent sandboxes

A sandbox service runs many tenants' microVMs on one server. If a guest ever
found a flaw in the monitor, the jailer decides what that compromised process
could then touch: one chroot, one set of cgroup limits, no root. Firecracker
also advises that "each Firecracker process corresponds to a workload of a
single tenant", which is what one microVM per sandbox gives.

## How Runtime relates to it

Runtime's guides describe the boundary a customer relies on: each sandbox has
its own kernel, disk and guest environment; CPU, memory, disk, network rules,
leases and billing are enforced on the host; and host credentials, control
sockets and provider credentials never reach customers
([security](/docs/security)). You get that without installing Firecracker,
configuring KVM access or building a jail.

Related: [Firecracker](/glossary/firecracker),
[virtual machine monitor](/glossary/virtual-machine-monitor),
[nsjail vs Firecracker](/compare/nsjail-vs-firecracker),
[self-hosted vs managed sandbox](/compare/self-hosted-vs-managed-sandbox).

## Sources

Checked 25 September 2026.

- [Firecracker jailer](https://github.com/firecracker-microvm/firecracker/blob/main/docs/jailer.md)
- [Firecracker production host setup](https://github.com/firecracker-microvm/firecracker/blob/main/docs/prod-host-setup.md)
- [Firecracker design](https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md)
- [Firecracker](https://firecracker-microvm.github.io/)

Facts on this page were checked on 25 September 2026.