What Is Ephemeral CI? Why Fresh Runners Matter
Ephemeral CI gives every job a clean, single-use machine that is thrown away when the job ends - so no run can contaminate the next.
An ephemeral runner is created for one job and destroyed afterward, leaving no state behind. It is the opposite of a long-lived runner that accumulates files, caches, and side effects across runs.
What "ephemeral" means
A fresh environment is provisioned for a single job, runs that job, and is torn down. Nothing it wrote - temp files, installed tools, leaked processes - survives to affect the next job. Every run starts from the same known baseline.
Why it matters
- No state leakage: one job cannot poison another’s environment.
- Reproducibility: a green build means it passes from a clean slate, not because of leftover state.
- Security: secrets and checkout data do not linger on a shared machine.
- Easier debugging: failures are not "works after I cleared the runner".
The trade-off
A clean machine has nothing cached, so ephemeral runners pay a cold-start and a dependency-install tax on every job. The standard mitigation is an external cache (dependencies, Docker layers) that restores the expensive bits without sharing dirty state.
Ephemeral vs persistent
Persistent runners are faster because state carries over, but that same state causes "passes only on runner #3" flakiness. Most teams choose ephemeral for correctness and add caching to claw back the speed.
Key takeaways
- Ephemeral = a fresh, single-use machine per job, destroyed afterward.
- It eliminates cross-run state leakage and improves reproducibility and security.
- The cost is cold starts and repeated dependency installs.
- Caching restores speed without reintroducing dirty shared state.