What Is a Runner Sandbox? Containing What a Job Can Do
A runner sandbox is a confined environment that limits what a CI job can access - its filesystem, network, and system calls - so the job cannot reach beyond its assigned boundary.
Where isolation separates jobs from each other, a sandbox constrains a single job from the inside: what it can touch, where it can connect, what it is allowed to do. Sandboxing matters most when a job runs untrusted or third-party code.
Isolation vs sandbox
Isolation is about keeping jobs apart. A sandbox is about restricting one job's capabilities - limiting its network egress, filesystem access, and privileged operations. They are complementary security layers.
What a sandbox restricts
- Network: limit or deny outbound connections to control exfiltration.
- Filesystem: confine writes to a scratch area; protect the rest.
- Privileges: drop capabilities so the job cannot escalate.
Why it matters
CI runs code from dependencies, forks, and pull requests you do not fully control. A sandbox limits the damage if any of that code is malicious or compromised, turning a potential breach into a contained failure.
Sandboxing in practice
Sandboxing pairs naturally with ephemeral runners: a confined job on a single-use machine has both limited reach and no persistence. Together they keep untrusted CI workloads from becoming a security problem.
The usability trade-off
Too tight a sandbox breaks legitimate jobs - a denied network call or blocked syscall fails a build that should pass. The goal is the least privilege that still lets real work run, which is why sandboxing is tuned to the workload rather than applied as a blanket lockdown.
Key takeaways
- A runner sandbox restricts what a single job can access or do.
- It complements isolation, which separates jobs from each other.
- It limits network, filesystem, and privileged operations.
- Sandboxing plus ephemerality contains untrusted CI code.