What Is Runner Isolation? Keeping Jobs From Affecting Each Other
Runner isolation is the degree to which each CI job is kept separate from others, so one job cannot read another's secrets, see its files, or corrupt its environment.
CI jobs handle secrets and untrusted code, so isolation is a security property, not a nicety. Weak isolation means one job (or a malicious PR) can reach into another. Strong isolation means every job is sealed off.
Why isolation matters
Jobs run with access to secrets, source code, and credentials. Without isolation, a compromised or malicious job on a shared runner could steal the next job's secrets, tamper with its outputs, or persist a backdoor for later.
Levels of isolation
- Process: weak - jobs share the same OS and can see each other.
- Container: better - namespaces separate jobs, but share a kernel.
- VM / fresh machine: strong - each job gets its own machine, destroyed after.
Isolation and ephemerality
Ephemeral runners are the strongest practical isolation: a fresh machine per job, destroyed afterward, means nothing of one job survives to reach the next. Persistent shared runners are the weakest because state and access carry over.
Isolation on managed runners
Latchkey runs each job on its own ephemeral runner that is destroyed afterward, so jobs are isolated by default and secrets never linger for the next job to find.
Isolation and untrusted pull requests
The riskiest CI workload is a pull request from a fork running with access to secrets. Strong isolation - a fresh, single-use machine that is torn down after the job - limits what a malicious PR can reach and ensures nothing it does persists to the next run.
Key takeaways
- Runner isolation keeps each job separate from every other.
- Without it, one job can steal secrets or corrupt another.
- Isolation ranges from weak process-level to strong per-job machines.
- Ephemeral, single-use runners give the strongest practical isolation.