Como Migrar do Blacksmith para o Latchkey (Guia 2026)
Blacksmith e Latchkey são ambos runners do GitHub Actions rápidos, drop-in e mais baratos. A razão pela qual os times avaliam uma mudança geralmente é confiabilidade: o Latchkey adiciona autocorreção para que falhas transitórias se recuperem automaticamente em vez de virar re-execuções.
O Blacksmith é um produto forte. Segundo o Blacksmith, é um substituto drop-in 2x mais rápido dos runners hospedados pelo GitHub: você o adota mudando a tag runs-on, os jobs rodam em microVMs Firecracker efêmeras que iniciam em menos de 3 segundos, e ele persiste caches de camadas Docker entre execuções. Se seu CI é limitado por CPU, o Blacksmith é um encaixe genuinamente bom. Os times olham para o Latchkey quando sua dor real não é a velocidade bruta, mas falhas instáveis, transitórias e custo. O Latchkey também é uma troca de runs-on de uma linha, adiciona CI com autocorreção para que kills por falta de memória, timeouts de registry e outras falhas transitórias/mecânicas sejam detectadas e retentadas automaticamente, e roda com até 70% menor custo por minuto do que o GitHub Actions. Como ambos são runners gerenciados padrão, mover-se entre eles é uma mudança de label, não um projeto de migração.
Blacksmith vs Latchkey - visão geral
| Capacidade | Blacksmith | Latchkey |
|---|---|---|
| Adoção | Mudar a tag runs-on | Mudar a tag runs-on |
| Mais barato que hospedado pelo GitHub | Sim (o Blacksmith afirma ~50% menor por minuto) | Sim (até 70% menor por minuto) |
| Isolamento / boot | MicroVMs Firecracker efêmeras, boot < 3s | Gerenciado, isolado por job |
| Cache de camadas Docker entre execuções | Sim (cache co-localizado, segundo Blacksmith) | Caching embutido (deps + camada Docker) |
| Velocidade bruta de CPU de core único | Uma força genuína (segundo Blacksmith, 50%+ maior single-core vs hospedado pelo GitHub) | Runners gerenciados rápidos |
| CI com autocorreção (retentativa automática de falhas transitórias) | Não | Sim |
| Otimização de build por IA | Não | Sim |
| Mais conhecido por | Velocidade bruta + cache de camadas Docker | Confiabilidade com autocorreção + baixo custo |
O que o Blacksmith é e faz bem
Segundo o Blacksmith, é a forma mais rápida de rodar GitHub Actions: um substituto drop-in dos runners hospedados pelo GitHub que sua documentação descreve como cerca de 2x mais rápido. Os runners iniciam a partir das mesmas imagens do GitHub com as mesmas dependências pré-instaladas, então a maioria dos workflows roda sem mudanças. Suas forças documentadas são reais: CPUs com performance de core único 50%+ maior do que os runners hospedados pelo GitHub, microVMs Firecracker efêmeras que iniciam em menos de 3 segundos e caches de camadas Docker persistidos com throughput de cache co-localizado em torno de 400 MB/s. Se seus builds são dominados por compilação de thread única ou builds Docker pesados, essa combinação é difícil de bater.
Por que alguns times migram para o Latchkey
Velocidade não conserta instabilidade. Se seu pipeline ainda fica vermelho em falhas transitórias - um kill por falta de memória, um erro de disco cheio, um timeout de registry ou rede - um runner mais rápido apenas falha mais rápido, e você paga para re-executar. O Latchkey é construído em torno de CI com autocorreção: ele detecta, diagnostica e corrige essas falhas transitórias e mecânicas automaticamente e retenta o job, então builds instáveis param de falhar seu pipeline. Ele combina isso com até 70% menor custo por minuto do que o GitHub Actions e otimização de build por IA. Esse é um eixo diferente do Blacksmith: confiabilidade e custo em vez de velocidade bruta por core.
Migração passo a passo
- Escolha um workflow barulhento ou caro para pilotar em vez de trocar tudo de uma vez.
- Nesse workflow, mude o label runs-on da sua tag de runner Blacksmith para o label de runner Latchkey. Essa é o mesmo tipo de mudança de uma linha que você fez para adotar o Blacksmith.
- Instale e conceda ao Latchkey GitHub App acesso ao repo ou org para que os jobs sejam capturados (o mesmo modelo de acesso de qualquer runner gerenciado).
- Rode o pipeline e compare com sua baseline do Blacksmith: custo por minuto, tempo de relógio e com que frequência falhas transitórias se autocorrigem em vez de precisar de re-execução manual.
- Faça o rollout para mais workflows repetindo a troca de runs-on. Como nada mais no seu YAML muda, você pode reverter instantaneamente apontando o runs-on de volta para o Blacksmith.
Quando permanecer no Blacksmith
Seja honesto consigo mesmo sobre o gargalo. Se seu CI é genuinamente limitado por CPU e pesado em cache de camadas Docker, e a confiabilidade já está boa, o Blacksmith pode já ser a melhor ferramenta para o trabalho e não há razão para trocar. O Latchkey é o encaixe mais forte quando re-execuções por falhas instáveis e custo por minuto são o que realmente dói.
O veredito
O Blacksmith é um runner drop-in rápido e bem construído, e a escolha certa para pipelines limitados por CPU e pesados em Docker. Se sua dor são re-execuções instáveis e custo em vez de velocidade bruta, o Latchkey também é uma troca de runs-on de uma linha - experimente runners gerenciados com autocorreção em um workflow, mantenha o Blacksmith como fallback e compare com seus builds reais antes de fazer o rollout.