Actions Runner Controller (ARC) vs Managed Runners
O ARC executa runners self-hosted no seu cluster Kubernetes - poderoso, mas você opera o cluster, a escalabilidade e as atualizações.
O Actions Runner Controller (ARC) é uma ferramenta mantida pela GitHub para executar runners self-hosted como pods no Kubernetes com autoscaling. É ótimo se você já roda K8s - mas ainda é self-hosting. Veja como ele se compara aos managed runners.
| ARC (self-hosted no K8s) | Managed (Latchkey) | |
|---|---|---|
| Custo de computação | Custo bruto do cluster | Baixo (~70% abaixo do hosted) |
| Exige Kubernetes | Sim (você o opera) | Não |
| Escalabilidade | Você configura o autoscaling | Warm pools (embutidos) |
| Patches / atualizações | Você cuida do controller + nodes | Feito para você |
| Recuperação de falhas instáveis | Não | Auto-retry com autocorreção |
| Esforço de configuração | Alto (Helm, controller, escalabilidade) | Troca de label |
Quando o ARC faz sentido
O ARC é uma escolha forte se você já roda Kubernetes, quer runners co-localizados com o seu cluster e tem um time de plataforma para operar o controller, os node pools e o autoscaling.
A realidade operacional
O ARC ainda é self-hosting: você cuida das atualizações do controller, da manutenção das imagens dos runners, do ajuste de escalabilidade e da confiabilidade dos nodes subjacentes. Isso é trabalho de plataforma real e contínuo.
Alternativa gerenciada
Managed runners como o Latchkey oferecem economia de computação semelhante (~70% abaixo do GitHub-hosted) sem nenhum Kubernetes para operar, com warm pools para captação instantânea e autocorreção que faz auto-retry de falhas transitórias.
O veredito
Use o ARC se você tem um time de plataforma Kubernetes e quer runners no seu próprio cluster. Se você quer a economia de custo sem operar K8s, os managed runners são o caminho de menor esforço e com autocorreção - comece de graça.