# What is the Firecracker jailer?

The jailer is a program from the Firecracker project. It sets up a chroot, namespaces
and cgroups for a Firecracker process, drops the process's privileges, then starts it.

**Runtime runs the Firecracker hosts for you. A sandbox is one API call, not a
host that you harden yourself.** Each sandbox is a Firecracker microVM with its
own Linux kernel, on dedicated servers that Runtime operates.

## 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 a second 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". 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.** It applies resource limits from `--resource-limit`. It then
   creates cgroup sub-folders that hold 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 root and calls `chroot`.
5. **Adds only two devices** inside the jail, with `mknod`: `/dev/net/tun` and
   `/dev/kvm`.
6. **Joins the namespaces it is given.** It joins a network namespace with
   `--netns`, and it starts a new PID namespace with `--new-pid-ns`
   ([Linux namespaces](/glossary/linux-namespaces)).
7. **Drops privileges** to the `--uid` and `--gid` it was given. It then 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. Suppose a guest
found a flaw in the monitor. The jailer then decides what the compromised process
can reach: one chroot, one set of cgroup limits, and no root. Firecracker also
advises that "each Firecracker process corresponds to a workload of a single
tenant". One microVM per sandbox follows this advice.

## How Runtime relates to it

Runtime's guides describe the boundary that customers rely on. Each sandbox has
its own kernel, disk and guest environment. CPU, memory, disk, network rules,
leases and billing are enforced on the host. Host credentials, control sockets
and provider credentials never reach customers ([security](/docs/security)). You
get this boundary 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 October 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 October 2026.