Migrando do Namespace para a Latchkey: comparação honesta + passos
Namespace e Latchkey ambos oferecem runners drop-in do GitHub Actions acessados por uma troca de runs-on. A diferença honesta é de ênfase: o Namespace otimiza para velocidade bruta de build e uma plataforma ampla de cache/build; a Latchkey otimiza para confiabilidade com autocorreção e custo por minuto.
Segundo a documentação do Namespace, o Namespace fornece runners drop-in do GitHub Actions que você adota alterando o label runs-on (por exemplo nscloud-ubuntu-22.04-amd64-8x16 ou um namespace-profile-<name>), com Cache Volumes e cache amplo de toolchains para acelerar builds. A Latchkey também conecta managed runners com uma troca de runs-on em uma linha, mas seu foco é CI com autocorreção: falhas transitórias e mecânicas (kills por falta de memória, erros de disco cheio, timeouts de registry) são detectadas, corrigidas e reexecutadas automaticamente. Esta página é uma comparação justa e um caminho prático de migração se confiabilidade e custo forem a sua prioridade.
Namespace vs Latchkey em resumo
| Capacidade | Namespace | Latchkey |
|---|---|---|
| Drop-in via troca de runs-on | Sim (nscloud-* ou namespace-profile-*) | Sim (troca de runs-on em uma linha) |
| Mais barato que os hospedados pelo GitHub | Sim (segundo os preços do Namespace) | Sim (até 70% menor por minuto) |
| Cache embutido | Sim (Cache Volumes, caches amplos de toolchains) | Sim (dependência + camada Docker) |
| Runners macOS / arm64 | Sim (segundo a documentação do Namespace) | Verifique a documentação atual da Latchkey |
| CI com autocorreção (auto-correção + retry de falhas transitórias) | Não | Sim |
| Mais conhecido por | Runners rápidos + plataforma ampla de build/cache | Confiabilidade com autocorreção + baixo custo |
No que o Namespace é realmente bom
Segundo as próprias páginas do Namespace, o Namespace divulga runners drop-in que tornam os workflows "2x-10x mais rápidos", apoiados por Cache Volumes (cache NVMe de alto throughput com localidade garantida) e cache embutido para toolchains populares como Bazel, Nix, Turbo, Gradle, Pants e sccache. A documentação também lista formatos de runner Linux amd64/arm64, Windows e macOS. Se a sua prioridade é aceleração bruta de build e uma plataforma ampla de cache/build, isso é uma força real.
O que a Latchkey enfatiza em vez disso
A Latchkey é construída em torno de CI com autocorreção. Em seus managed runners, falhas transitórias e mecânicas são detectadas, diagnosticadas e reexecutadas automaticamente, então builds instáveis param de falhar o seu pipeline e você para de pagar por re-execuções manuais. Ela combina isso com otimização de build por IA, zero tempo de fila e custo por minuto até 70% menor que os hospedados pelo GitHub. A diferenciação é confiabilidade e custo, não a alegação de ser o runner mais rápido em velocidade bruta.
Passos de migração (Namespace para Latchkey)
- Inventarie onde você usa labels do Namespace hoje: procure nos seus workflows por valores de runs-on que comecem com nscloud- ou namespace-profile-.
- Conecte a Latchkey à sua org do GitHub e escolha um tamanho de runner que corresponda ao formato do Namespace que você usava (por exemplo um formato de 8 vCPU / 16 GB).
- Troque o label runs-on em um workflow não crítico para o label da Latchkey, deixando o restante no Namespace.
- Se você dependia dos Namespace Cache Volumes ou do nscloud-cache-action, mapeie-os para o cache embutido da Latchkey, ou mantenha o GitHub Actions Cache, que não precisa de alterações.
- Rode o pipeline algumas vezes, compare o tempo total, o custo por minuto e como os passos instáveis se comportam, depois faça o rollout gradualmente.
O que manter no Namespace
Se um workflow específico depende de um recurso próprio do Namespace (por exemplo um Cache Volume Bazel ou Nix ajustado, formatos macOS Apple-Silicon ou Devboxes), não há necessidade de movê-lo só por mover. Ambos usam labels runs-on padrão, então você pode rodá-los lado a lado e migrar apenas os workflows em que autocorreção e custo mais importam.
O veredito
Se você quer os runners mais rápidos em velocidade bruta mais uma plataforma ampla de cache/build, o Namespace é uma escolha forte e vale a pena mantê-lo para essas cargas de trabalho. Se a sua dor real é re-execuções instáveis e custo por minuto, a Latchkey adiciona autocorreção em managed runners a um custo até 70% menor que os hospedados pelo GitHub, com a mesma troca de runs-on em uma linha. Verifique os preços atuais do Namespace em namespace.so/pricing, depois pilote a Latchkey em um workflow e compare contra os seus builds reais.