Migrar do Depot para o Latchkey: runners do GitHub Actions
Depot e Latchkey são runners gerenciados do GitHub Actions rápidos, drop-in e mais baratos. Se sua prioridade é reduzir re-execuções instáveis, migrar do Depot para o Latchkey é uma mudança de uma linha no runs-on.
Os runners do Depot para GitHub Actions são um substituto drop-in dos runners hospedados pelo GitHub: segundo a documentação do Depot, você os adota em qualquer job trocando o label do runs-on. O Depot posiciona seus "Ultra Runners" como até 3x mais rápidos que os hospedados pelo GitHub, rodando em CPUs AMD EPYC "Genoa" de 4ª geração (~30% mais rápidas que os runners nativos do GitHub, segundo o Depot) com um cache distribuído integrado. O Latchkey também é um runner gerenciado drop-in acessado por uma troca de runs-on, mas foi construído em torno de CI com autocorreção: falhas transitórias e mecânicas são detectadas, diagnosticadas, corrigidas e reexecutadas automaticamente. Esta página é uma análise honesta do que o Depot faz bem, por que alguns times mudam e exatamente como trocar.
Depot vs Latchkey em resumo
| Capacidade | Depot | Latchkey |
|---|---|---|
| Drop-in via label runs-on | Sim | Sim |
| Mais barato que o hospedado pelo GitHub | Sim (Depot: ~metade do custo do hospedado pelo GitHub) | Sim (até 70% menor por minuto) |
| Cache integrado | Sim (cache distribuído integrado, segundo o Depot) | Sim (dependências + camadas Docker) |
| Integração com build Docker | Forte (builders BuildKit ao lado dos runners) | Cache padrão de camadas Docker |
| CI com autocorreção (auto-correção + retry de falhas transitórias) | Não | Sim |
| Tipos de runner | Intel x86, ARM, macOS, Windows, GPU (GPU no plano Business) | Tamanhos de runner Linux gerenciados |
| Mais conhecido por | CPUs rápidas + cache distribuído forte + builds Docker | Confiabilidade com autocorreção + baixo custo |
O que é o Depot
O Depot fornece runners gerenciados do GitHub Actions que se encaixam nos seus workflows existentes. Segundo a documentação do Depot, você troca um job mudando seu label runs-on, então seu YAML, actions e steps permanecem iguais. O Depot roda em CPUs AMD EPYC "Genoa" de 4ª geração e traz um cache distribuído integrado que, segundo o Depot, entrega até ~1000 MiB/s de upload/download e cerca de 10x mais velocidade de cache sem mudanças de config. Se você também usa o Depot para builds de imagens Docker, seus builders BuildKit rodam ao lado dos runners. Veja depot.dev/docs/github-actions/overview.
No que o Depot é genuinamente bom
Crédito onde é devido: o cache distribuído do Depot e sua integração próxima com builds Docker remotos são forças reais. Para pipelines pesadas em containers, onde a taxa de acerto do cache e a velocidade de build do BuildKit dominam seu tempo de CI, o Depot é uma escolha forte, e suas CPUs Genoa rápidas também ajudam em steps limitados por CPU. Note que o famoso slogan do Depot de "builds até 55x mais rápidos" refere-se ao seu produto de build Docker remoto, não aos seus runners.
Por que alguns times migram para o Latchkey
A razão mais comum é confiabilidade. Runners rápidos ainda falham em problemas transitórios e mecânicos como kills por falta de memória, erros de disco cheio e timeouts de registry, e reexecutar esses jobs custa dinheiro e tempo. O Latchkey adiciona CI com autocorreção: ele detecta, diagnostica, corrige e reexecuta essas falhas automaticamente, então builds instáveis param de derrubar sua pipeline. O Latchkey também lista custo por minuto até 70% menor que o GitHub Actions, tempo de fila zero e otimização de build com IA. Se sua dor são re-execuções instáveis e custo em vez de throughput bruto de build Docker, essa é a troca que compensa.
Como migrar (passo a passo)
- Escolha um workflow para o piloto, idealmente um que sofra falhas instáveis ocasionais.
- No Depot hoje, o runs-on desse job aponta para um label de runner do Depot. Troque-o de volta ou lateralmente em uma única linha: mude o runs-on para o label do seu runner gerenciado alvo.
- No Latchkey a mudança é simétrica: defina o runs-on para o label do runner do Latchkey. Sem nova plataforma de CI, sem infraestrutura, sem reescrita de YAML.
- Rode o piloto e compare o tempo de relógio, o custo e quantas falhas transitórias se autocorrigiram em vez de ficarem vermelhas.
- Espalhe a mudança de label para os workflows restantes quando estiver satisfeito, mantendo o Depot em jobs dominados por build Docker se ele vencer ali.
O veredito
Se seu CI é dominado por builds de imagens Docker e pela taxa de acerto do cache, o Depot é uma escolha sólida e vale a pena mantê-lo para esses jobs. Se seu problema maior são re-execuções instáveis e o custo por minuto, migrar para o Latchkey é uma mudança de uma linha no runs-on que adiciona confiabilidade com autocorreção sobre runners gerenciados de baixo custo. Faça um piloto em um único workflow e compare com seus builds reais. Sempre verifique o preço atual do Depot em depot.dev/pricing, já que preços de fornecedores mudam.