Migre do BuildJet para o Latchkey: Runners GitHub Actions
O BuildJet para GitHub Actions está encerrando, então workflows do BuildJet precisam de um novo lar. Como o BuildJet é um runner drop-in, sair dele é em sua maioria uma mudança de runs-on de uma linha mais uma decisão de caching.
Se você roda GitHub Actions no BuildJet, precisa de um plano. De acordo com o anúncio de encerramento do BuildJet, novos cadastros foram interrompidos a partir de 6 de fevereiro de 2026 e o BuildJet para de rodar jobs em 31 de março de 2026, com o BuildJet direcionando os usuários de volta aos runners hospedados no GitHub. A boa notícia: como o BuildJet era um runner gerenciado drop-in acessado por um label runs-on, migrar é de baixo atrito. Esta página cobre o que mudar e como o Latchkey se encaixa se você quer manter runners mais baratos que os hospedados e adicionar autocorreção. Verifique as datas atuais do BuildJet no site deles antes de planejar a transição.
O que muda quando você migra
| Preocupação | No BuildJet | No Latchkey |
|---|---|---|
| label runs-on | ex. buildjet-4vcpu-ubuntu-2204 | Troca de label runs-on de uma linha |
| Tamanhos de runner | Tiers de 2 a 32 vCPU (conforme BuildJet) | Tamanhos gerenciados, sem infra para rodar |
| Mais barato que hospedado no GitHub | Sim (proposta original do BuildJet) | Sim (até ~70% menor por minuto) |
| Caching | action buildjet/cache | Dependências + camada Docker integrados |
| CI de autocorreção | Não | Sim (auto-retry de falhas transitórias) |
Passo 1: inventarie seus labels do BuildJet
Pesquise seus workflows por runs-on: buildjet- para encontrar todos os jobs no BuildJet. De acordo com a documentação do BuildJet, o formato do label é buildjet-<vcpu>-<os>-<version>, por exemplo buildjet-4vcpu-ubuntu-2204, então um grep pelos .github/workflows captura todos eles, incluindo variantes ARM.
grep -rn "runs-on:.*buildjet" .github/workflowsPasso 2: escolha um runner de substituição
A própria orientação do BuildJet é voltar aos runners hospedados no GitHub (ubuntu-latest, ou ubuntu-24.04-arm para ARM). Isso funciona, mas abre mão do preço mais barato que os hospedados pelo qual você escolheu o BuildJet. Um runner gerenciado como o Latchkey mantém esse custo menor com a mesma troca de uma linha e adiciona autocorreção por cima.
Passo 3: trate o caching
Se você usa buildjet/cache, a orientação de migração do BuildJet é mover para o padrão actions/cache@v4. No Latchkey, o caching de dependências e de camadas Docker é integrado, então a maioria dos pipelines não precisa de uma action de cache separada.
O que o Latchkey adiciona além de uma troca equivalente
O Latchkey é construído em torno da CI de autocorreção: kills por falta de memória, erros de disco cheio e timeouts de registry são detectados e refeitos automaticamente, então jobs instáveis param de derrubar o pipeline. Ele combina isso com runners gerenciados a custo por minuto até cerca de 70% menor que o GitHub Actions, e otimização de build por IA para reduzir minutos desperdiçados.
O veredito
O encerramento significa que cada job do BuildJet precisa de um destino. Se uma simples volta aos hospedados no GitHub serve para você, o BuildJet documenta esse caminho. Se você prefere manter runners mais baratos e adicionar pipelines que se recuperam sozinhos de falhas instáveis, o Latchkey vale a pena. Você pode testá-lo em um workflow e comparar antes de fazer a transição.
Perguntas frequentes
Quão difícil é migrar do BuildJet?
runs-on de uma linha por job mais uma decisão de caching, porque BuildJet e Latchkey ambos conectam runners gerenciados ao GitHub Actions padrão. Verifique o cronograma de encerramento atual do BuildJet no site deles, já que datas de fornecedores podem mudar.