Larger GitHub Runners vs Managed Runners: Custo
Os larger GitHub runners resolvem o problema de "preciso de mais núcleos", mas cobram desde o primeiro minuto a uma tarifa 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. Veja a comparação.
| Larger GitHub runners | Managed (Latchkey) | |
|---|---|---|
| Minutos gratuitos | Nenhum - cobra desde o minuto 1 | Camada gratuita inclusa |
| Tarifa por minuto | Premium (escala com os núcleos) | ~70% menor |
| Fila sob carga | Possível | Warm pools (sem fila) |
| Cache | Básico | Embutido |
| Recuperação de falhas instáveis | Não | Auto-retry com autocorreção |
| 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 e sem franquia gratuita.
Quando o managed vence
Para builds pesados sustentados ou de alto volume, os managed runners entregam a mesma vCPU por cerca de 70% menos, com warm pools para que jobs grandes não fiquem na fila e cache embutido para encurtá-los.
Bônus de confiabilidade
Jobs grandes são exatamente onde erros de OOM e de disco cheio atacam. O Latchkey se autocorrige nesses casos automaticamente, então um build pesado instável não te custa uma reexecução completa e cara.
O veredito
Builds grandes ocasionais: os larger GitHub runners são adequados. Builds pesados frequentes: os managed runners são drasticamente mais baratos pela mesma computação, sem filas e com autocorreção - comece de graça e compare.