# What are cgroups?

Control groups (cgroups) are a Linux kernel feature that groups processes so their resource use can be limited and measured.

**On Runtime, a sandbox's CPU, memory and disk limits are enforced on the host,
outside the guest. You pay for the CPU the sandbox actually uses:** $0.025
per active vCPU-hour, measured, with a floor of 50 thousandths of a vCPU
([pricing](/docs/pricing)). Root inside the sandbox cannot raise any of these limits.

## How do cgroups work?

The kernel documentation calls a cgroup "a mechanism to organize processes
hierarchically and distribute system resources along the hierarchy in a
controlled and configurable manner." Groups are directories in a filesystem,
usually mounted under `/sys/fs/cgroup`. A process joins a group when its PID
is written to the group's `cgroup.procs` file. Limits are files too:

- `memory.max` sets a hard memory ceiling. When a group reaches it and cannot
  reclaim memory, "the OOM killer is invoked in the cgroup".
- `cpu.max` takes "$MAX $PERIOD": the group may use up to MAX microseconds of
  CPU in each PERIOD.
- `pids.max` is a "hard limit of number of processes". The kernel docs name
  the reason: "a fork bomb is likely to exhaust the number of tasks before
  hitting memory restrictions". Past the limit, `fork` and `clone` fail with
  `EAGAIN`.

Version 2 replaced the several hierarchies of version 1 with one. The kernel
docs say "cgroup v2 has only single hierarchy".

## Facts

| Property       | cgroups, as the man page and kernel docs state it                 |
| -------------- | ----------------------------------------------------------------- |
| Version 1      | Introduced in Linux 2.6.24                                        |
| Version 2      | Developed from Linux 3.10, released in Linux 4.5                  |
| Interface      | A filesystem, usually under `/sys/fs/cgroup`                      |
| v2 controllers | cpu, cpuset, freezer, hugetlb, io, memory, perf_event, pids, rdma |
| Hierarchies    | Many in v1; one unified tree in v2                                |

## Are cgroups isolation?

No. Cgroups provide accounting and limits. Docker's security page says cgroups
"implement resource accounting and limiting" and are "essential to fend off
some denial-of-service attacks". They stop one container from starving its
neighbors of memory or CPU. They do not hide anything. [Namespaces](/glossary/linux-namespaces)
do that.

Cgroups also work around virtual machines, on the host. Firecracker's design
notes say that each Firecracker process can be placed in its own cgroup. This
controls CPU affinity and quotas across many microVMs on a host. Its
[jailer](/glossary/jailer) creates those groups before it starts the monitor.

## Why it matters for AI agent sandboxes

Agents start many sandboxes at the same time. A runaway build or a fork bomb in one must
not slow the rest. Resource limits are also what a bill is computed from. A
sandbox that can raise its own limits can raise its own cost.

## How Runtime relates to it

Runtime describes the result, not the mechanism. Each sandbox gets a guaranteed
CPU floor and can burst up to its `vcpu` count. Memory is the amount you request.
The disk is shared by weight among the sandboxes on a server. Each sandbox gets
at least about 40 MB/s, and up to about 1 GB/s when the others are
idle. This stops one sandbox from swamping a shared drive
([disk, CPU and memory](/docs/sandbox-environment#disk-cpu-and-memory)). The
host enforces all of this, along with the network rules. `sudo` in the guest
cannot reach it ([security](/docs/security)).

Related: [container escape](/glossary/container-escape),
[microVM](/glossary/microvm),
[Docker vs virtual machine](/compare/docker-vs-virtual-machine).

## Sources

Checked 25 October 2026.

- [cgroups(7), man7.org](https://man7.org/linux/man-pages/man7/cgroups.7.html)
- [Control Group v2, kernel.org](https://docs.kernel.org/admin-guide/cgroup-v2.html)
- [Docker Engine security](https://docs.docker.com/engine/security/)
- [Firecracker design](https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md)

Facts on this page were checked on 25 October 2026.