# 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, and 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 it.

## 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, and 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, they are 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
neighbours of memory or CPU. They do not hide anything; that is the job of
[namespaces](/glossary/linux-namespaces).

cgroups also sit outside virtual machines. Firecracker's design notes that
each Firecracker process can be placed in its own cgroup to control CPU
affinity and quotas across many microVMs on a host, and its
[jailer](/glossary/jailer) creates those groups before it starts the monitor.

## Why it matters for AI agent sandboxes

Agents spin up many sandboxes at once, and 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 states the result rather than the mechanism. Each sandbox gets a
guaranteed CPU floor and can burst up to its `vcpu` count; memory is what you
ask for; the disk bursts to about 250 MB/s for up to 30 seconds, then runs at
about 40 MB/s and 2,000 operations a second, so one sandbox cannot swamp a
shared drive
([disk, CPU and memory](/docs/sandbox-environment#disk-cpu-and-memory)). All
of it, like the network rules, is enforced on the host where `sudo` in the
guest cannot reach ([security](/docs/security)).

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

## Sources

Checked 25 September 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 September 2026.