# What Is Ephemeral CI? Why Fresh Runners Matter

> Ephemeral CI means each job runs on a fresh, single-use environment that is destroyed afterward. Learn why it prevents bugs and what it costs.

Source: https://latchkey.dev/learn/ci-cd-concepts/what-is-ephemeral-ci  
Updated: 2026-06-25

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.

## FAQ

### What is What is ephemeral CI? why fresh runners matter?

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.

### 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.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt