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). 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.maxsets a hard memory ceiling. When a group reaches it and cannot reclaim memory, "the OOM killer is invoked in the cgroup".cpu.maxtakes "$MAX $PERIOD": the group may use up to MAX microseconds of CPU in each PERIOD.pids.maxis 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,forkandclonefail withEAGAIN.
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.
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 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). All
of it, like the network rules, is enforced on the host where sudo in the
guest cannot reach (security).
Related: container escape, microVM, Docker vs virtual machine.
Sources
Checked 25 September 2026.
Facts on this page were checked on 25 September 2026.