Especial · TDC São Paulo 2026

Como cortar até 90% do custo de CI/CD trocando GitHub Actions hospedado por runners self-hosted no Kubernetes

No palco Stadium do TDC São Paulo, uma palestra mostrou como combinar Actions Runner Controller (ARC) e Karpenter para escalar runners de zero a N e voltar a zero, pagando centavos por minuto de build em vez de dólares.

Stadium23 de setembro de 2026 às 11:44cobertura assistida por IA, revisada pela redação
Reprodução/YouTube · TDC São Paulo 2026

Para times que gastam milhares de dólares por mês em minutos de GitHub Actions hospedado, uma apresentação no palco Stadium detalhou uma arquitetura self-hosted que promete reduzir drasticamente esse custo sem abrir mão de escalabilidade automática.

A base da solução é o Actions Runner Controller (ARC), um Helm Chart oferecido pela própria Microsoft. Segundo o palestrante, "ele cria um controlador no seu cluster Kubernetes, e esse controlador controla a criação de runners usando pods". O ARC é combinado com o Karpenter, autoscaler que escolhe o tipo de máquina conforme o workload — "se meu pod usa pouca recurso, ele pega maquininhas menores, se ele usa mais, ele vai alocando as máquinas de acordo com o tipo de workload".

Zero to scale, scale to zero

A arquitetura roda sobre um cluster EKS enxuto, com apenas dois nós pequenos (t4g.small, ARM) mantendo ARC e Karpenter em alta disponibilidade — custo fixo de cerca de US$ 135/mês parado. Quando um pull request dispara um job, o ARC cria um pod pending, o Karpenter provisiona a máquina necessária (cold start de 1 a 2 minutos), o job roda e, cerca de 30 segundos após ficar ocioso, o nó é destruído.

Os slides mostraram o NodePool usado, priorizando instâncias Spot e caindo para on-demand só quando necessário, com teto de 100 cores e categorias de instância restritas a c e m de 8 ou 16 vCPUs. O trade-off das Spot é o risco de a AWS reivindicar a máquina de volta com apenas dois minutos de teardown — "se seu job não consegue executar em dois minutos, você corre o risco dele ser cortado no meio", o que torna a abordagem ideal para builds efêmeros, mas arriscada para jobs com estado, como um terraform apply que trava um lock.

Segurança das credenciais

A integração usa um GitHub App em vez de tokens de longa duração — "os tokens são short-lived (...) caso vazar esse token, a pessoa não vai ter muito tempo de ação". As credenciais passam por AWS Secrets Manager e External Secrets Operator (ESO), evitando que a chave privada fique em texto puro no Secret nativo do Kubernetes (que é apenas Base64) ou no state do Terraform — conforme o slide, "a chave privada nunca aparece em texto aberto no estado do Terraform".

Os números

Os slides trouxeram uma tabela comparando on-demand e Spot para instâncias de 8 vCPUs: uma c6a.2xlarge on-demand sai a cerca de US$ 0,0051/minuto, contra US$ 0,0017–0,0023/minuto em Spot. Na conta final apresentada, 200 mil minutos mensais que custariam US$ 4.000 no GitHub Actions hospedado caíram para aproximadamente US$ 530 na infraestrutura self-hosted — e, no caso real do palestrante, o custo total mensal caiu de cerca de US$ 40 mil para US$ 4 mil, uma economia relatada de 90%.

O palestrante também mostrou que a mesma infraestrutura pode rodar agentes do GitHub Copilot, bastando um arquivo copilot-setup-steps apontando para o runs-on do ARC — recurso que, segundo ele, só funciona nesse modo, não em runners locais ou Docker. O projeto completo, em Terraform, foi liberado como open source pela empresa do palestrante e está em produção hoje.

← Voltar para a cobertura ao vivo