GitHub Larger Runners vs Managed Runners: Custo e Velocidade
Os GitHub larger runners resolvem o problema de "meu build precisa de mais núcleos" - mas cobram desde o primeiro minuto e a preço premium.
Quando os runners padrão são pequenos demais, a GitHub oferece runners maiores (4-64 vCPU). Eles funcionam, mas cobram desde o primeiro minuto, sem franquia gratuita e a uma tarifa alta. Os managed runners atingem os mesmos tamanhos por muito menos.
| GitHub larger runners | Managed (Latchkey) | |
|---|---|---|
| Minutos gratuitos | Nenhum - cobra desde o minuto 1 | Camada gratuita inclusa |
| 4 vCPU por minuto | ~$0.016 | ~$0.005 |
| 8 vCPU por minuto | ~$0.032 | ~$0.01 |
| Autocorreção | Não | Sim |
| Configuração | Config do runner group | Troca de label |
Quando os larger GitHub runners fazem sentido
Se você precisa de mais núcleos apenas ocasionalmente e quer zero configuração de terceiros, os larger GitHub runners são o caminho mais simples - só espere uma tarifa por minuto elevada.
Quando o managed vence
Para builds pesados sustentados ou de alto volume, os managed runners entregam a mesma vCPU por cerca de um terço do preço, com cache e autocorreção por cima.
How to evaluate a managed runner honestly
- Compare at equal machine shape. A lower rate on fewer vCPUs is not cheaper per unit of work.
- Check billing granularity: per-minute rounding costs real money across a wide matrix of short jobs.
- Include queue and boot time. Cheaper per minute but slower to start can cost more per merge.
- Count your re-runs. Paying twice for the same work is invisible on every rate card.
- Switching is a one-line
runs-onchange in both directions, so a two-week trial beats modelling.
O veredito
Builds grandes ocasionais: os larger GitHub runners são adequados. Builds pesados frequentes: os managed runners como o Latchkey são drasticamente mais baratos pela mesma computação.