GitHub-Hosted vs Self-Hosted vs Managed Runners (2026)
Há três formas de executar jobs do GitHub Actions. Elas trocam custo, velocidade e o quanto de infraestrutura você mantém.
Todo job do GitHub Actions roda em um runner. A sua escolha de modelo de runner é a maior alavanca sobre custo, velocidade e confiabilidade de CI. Veja como as três opções se comparam.
Os três modelos
| GitHub-hosted | Self-hosted | Managed (ex.: Latchkey) | |
|---|---|---|---|
| Custo por minuto | Mais alto | Mais baixo (computação bruta) + tempo de operação | Baixo (~70% abaixo do hosted) |
| Você mantém a infra | Não | Sim - escalabilidade, patches, limpeza | Não |
| Cold start / velocidade | OK | Rápido (se mantido aquecido) | Rápido (warm pools) |
| Cache | Básico | Faça você mesmo | Embutido |
| Autocorreção de falhas | Não | Não | Sim (Latchkey) |
| Ideal para | CI pequeno/ocasional | Controle total, larga escala | Baixo custo + baixa operação |
GitHub-hosted
Zero configuração, cobrado por minuto a preço premium. Ótimo para baixo volume; caro e inflexível em escala.
Self-hosted
Você roda o agente do runner nas suas próprias máquinas: computação mais barata, controle total - mas você cuida da escalabilidade, patches, limpeza, problemas de disco cheio e runners obsoletos, e das dores de confiabilidade que vêm com infraestrutura de vida longa.
Managed runners
Um provedor opera a frota por você: economia no estilo self-hosted sem a operação. Os melhores adicionam recursos de confiabilidade - o Latchkey adiciona autocorreção para que falhas transitórias se recuperem automaticamente.
O veredito
Use o GitHub-hosted para pipelines pequenos ou ocasionais. Escolha self-hosted apenas se você quer controle total e tem o time para operá-lo. Para a maioria dos times que quer menor custo sem o fardo operacional - e pipelines que se recuperam sozinhos de falhas instáveis - os managed runners como o Latchkey são o ponto ideal.