Como migrar do RunsOn para o Latchkey (self-hosted para gerenciado)
O RunsOn roda runners do GitHub Actions na sua própria conta AWS; o Latchkey os roda para você como um serviço totalmente gerenciado. Migrar significa entregar a operação, não aprender um novo sistema de CI.
Segundo a documentação do RunsOn, o RunsOn é um control plane que você hospeda por conta própria sob uma licença: runners EC2 efêmeros são iniciados na sua própria conta AWS, uma máquina por job, spot por padrão, com as contas de EC2/S3 indo diretamente para você sem markup (runs-on.com). Isso lhe dá o máximo de controle e baixo custo bruto de computação, mas você fica responsável pelo stack de CloudFormation, roles de IAM, capacidade spot e cotas da AWS. O Latchkey é totalmente gerenciado: não há conta ou stack AWS para operar, e ele acrescenta autocorreção, de modo que falhas transitórias e mecânicas são detectadas, corrigidas e reexecutadas automaticamente. Como ambos anexam runners padrão do GitHub Actions por label, a migração em si é uma troca de runs-on em uma linha. Verifique o preço e os recursos atuais do RunsOn em runs-on.com antes de planejar a mudança.
RunsOn vs Latchkey num relance
| Recurso | RunsOn | Latchkey |
|---|---|---|
| Modelo de hospedagem | Self-hosted na sua conta AWS | Totalmente gerenciado (sem conta AWS necessária) |
| Infra que você opera | Stack de CloudFormation, IAM, VPC, spot, cotas | Nenhuma |
| Cobrança de computação | A AWS cobra você diretamente, sem markup (docs do RunsOn) | Por minuto, gerenciado |
| Falhas com autocorreção | Não (retry automático de spot para on-demand uma vez, segundo a documentação) | Sim (detecta, corrige, reexecuta) |
| Mudança no workflow para trocar | Label runs-on em uma linha (docs do RunsOn) | Label runs-on em uma linha |
| Melhor para | Máximo controle + menor custo bruto de spot | Zero-ops + autocorreção |
O que você mantém e o que você entrega
Seus workflows, actions e YAML permanecem os mesmos porque ambos usam runners padrão do GitHub Actions. O que você entrega com o Latchkey é a superfície operacional que o RunsOn pede para você rodar na sua própria AWS: o stack de CloudFormation, VPC e subnets, roles de IAM e permission boundaries, gerenciamento de capacidade spot e cotas de serviço da AWS (tudo documentado em runs-on.com/quickstart e runs-on.com/docs). Com o Latchkey não há stack nem conta AWS para gerenciar.
Passos da migração
- Faça o inventário dos labels de runner que seus workflows usam hoje (labels do RunsOn são consultas de restrição como
runner=16cpu-linux-arm64oucpu=4/ram=16/family=c7a+m7a, segundo runs-on.com/runners). - Mapeie cada label para um tamanho equivalente de runner gerenciado do Latchkey.
- Troque o label runs-on em um workflow piloto e compare o tempo de parede e a confiabilidade.
- Faça o rollout dos workflows restantes e, em seguida, desative o stack de CloudFormation do RunsOn na sua conta AWS quando o tráfego estiver totalmente migrado.
O que o Latchkey acrescenta
O Latchkey é construído em torno de CI com autocorreção: kills por falta de memória, erros de disco cheio, timeouts de registry e outras falhas transitórias são detectados e reexecutados automaticamente, para que você pare de pagar por re-runs. Ele também remove as operações de AWS que o RunsOn deixa com você, já que não há stack, IAM nem capacidade spot para gerenciar.
O veredito
Fique no RunsOn se rodar runners dentro da sua própria conta AWS por residência de dados e o menor custo bruto de spot valer o trabalho de operar o stack por conta própria. Se você preferir entregar o trabalho de CloudFormation, IAM, spot e cotas e obter autocorreção em cada job, o Latchkey é o destino gerenciado. Comece grátis e faça um piloto de um workflow antes de fazer a virada.