# O que é CI efêmero? Por que runners novos importam

> CI efêmero significa que cada job roda em um ambiente novo e de uso único que é destruído depois. Entenda por que isso evita bugs e o que custa.

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

CI efêmero dá a cada job uma máquina limpa e de uso único que é descartada quando o job termina - então nenhuma execução pode contaminar a próxima.

Um runner efêmero é criado para um único job e destruído depois, sem deixar estado para trás. É o oposto de um runner de longa duração que acumula arquivos, caches e efeitos colaterais entre execuções.

## O que "efêmero" significa

Um ambiente novo é provisionado para um único job, executa esse job e é destruído. Nada que ele escreveu - arquivos temporários, ferramentas instaladas, processos vazados - sobrevive para afetar o próximo job. Toda execução começa da mesma linha de base conhecida.

## Por que importa

- Sem vazamento de estado: um job não pode envenenar o ambiente de outro.
- Reprodutibilidade: um build verde significa que passa de um estado limpo, não por causa de estado remanescente.
- Segurança: secrets e dados de checkout não ficam em uma máquina compartilhada.
- Depuração mais fácil: falhas não são "funciona depois que limpei o runner".

## O trade-off

Uma máquina limpa não tem nada em cache, então runners efêmeros pagam um imposto de cold start e de instalação de dependências a cada job. A mitigação padrão é um cache externo (dependências, camadas de Docker) que restaura as partes caras sem compartilhar estado sujo.

## Efêmero vs persistente

Runners persistentes são mais rápidos porque o estado é reaproveitado, mas esse mesmo estado causa flakiness do tipo "só passa no runner #3". A maioria das equipes escolhe efêmero pela corretude e adiciona cache para recuperar a velocidade.

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