Visão geral dos runners gerenciados

O que são os runners do Latchkey, os quatro tamanhos e seus preços, o que os torna diferentes dos runners hospedados pelo GitHub e o que você precisa antes do seu primeiro job.

Os runners gerenciados do Latchkey são máquinas virtuais efêmeras que executam seus jobs do GitHub Actions. Cada runner executa exatamente um job e é destruído em seguida, então todo job começa em uma máquina limpa e isolada. Todo runner também vem com autorreparo integrado.

Tamanhos e preços#

Todos os runners são Ubuntu 24.04 LTS em x86_64 (hardware da classe m6a da AWS) com uma cadeia de ferramentas pré-instalada e abrangente. A cobrança é por minuto, arredondada para cima por job, e todo plano inclui minutos gratuitos por mês (2.000 no Developer, 4.000 no Launch, 6.000 no Scale; ou seja, 4.000 por mês no nível intermediário, contra 3.000 no GitHub); veja Uso de runners e minutos gratuitos.

Qual tamanho você deve escolher?#

Trate o que segue como orientação, não como regra: os tempos de execução dos seus próprios jobs são o verdadeiro parâmetro. O padrão que atende à maioria das equipes é definir tudo como latchkey-small por padrão e depois promover os jobs específicos que comprovarem precisar de mais.

Duas propriedades da linha facilitam raciocinar sobre o dimensionamento correto. Cada degrau acima dobra vCPU, memória e a tarifa por minuto, então promover um job de tamanho vale a pena quando ele pelo menos reduz pela metade a duração daquele job: mesmo custo ou menos, e feedback mais rápido. E o runs-on é escolhido por job, não por workflow, então um único job de build pesado no latchkey-large nunca força seu job de lint a sair do latchkey-small.

Por que as equipes mudam#

• Preço: até 70% mais barato por minuto de runner do que os hospedados pelo GitHub, com mais minutos gratuitos do que o GitHub inclui (4.000 contra 3.000 no nível intermediário).
• Velocidade: inícios a frio em cerca de 10 segundos (os hospedados pelo GitHub costumam levar 30-60 segundos) sem tempo de fila; captações a quente ocorrem em segundos.
• Autorreparo: falhas transitórias (timeouts de registry, kills por OOM, discos cheios, ferramentas ausentes) são detectadas e corrigidas durante a execução.
• Isolamento: um job por runner, em uma rede privada sem acesso de entrada, destruído após o job.
• Zero infraestrutura para gerenciar: nenhuma imagem de runner para construir, nenhum autoscaling para ajustar, nenhum agente de runner para atualizar.

Efêmero por design#

Todo runner é criado para um job e destruído no momento em que esse job termina. Nada persiste entre jobs: nenhum processo remanescente, nenhum cache obsoleto, nenhum arquivo que um job anterior tenha escrito em disco. Essa garantia de máquina limpa é o que torna as execuções reproduzíveis; se um job passa hoje e falha amanhã, a diferença está na sua alteração ou em uma dependência, não em estado acumulado em uma máquina de vida longa.

A mesma propriedade sustenta a história de segurança. Um runner se registra just-in-time com credenciais de uso único, roda em uma rede privada sem acesso de entrada, recebe exatamente um job e é destruído: não há janela para um job observar outro, e nenhuma máquina de vida longa para atualizar e blindar. Veja Segurança e permissões para o quadro completo.

Planeje-se em torno disso também: tudo que for escrito no disco local do runner some quando o job termina. Persista saídas de build como artefatos e acelere instalações com caches, exatamente como você faria em runners hospedados pelo GitHub.

Pré-requisitos#

• O GitHub App do Latchkey está instalado na sua organização.
• O repositório é monitorado no Latchkey.
• Os runners gerenciados estão habilitados para seu workspace (eles são configurados automaticamente quando o app é instalado; a página Runners no dashboard mostra sua prontidão e configurações).
• Sua assinatura ou trial está ativo. Lançamentos de runner são bloqueados para trials expirados e assinaturas vencidas; veja Uso de runners e minutos gratuitos.

Como funciona o provisionamento#

Quando o GitHub enfileira um job com um rótulo latchkey-*, o Latchkey ou o entrega a um runner já aquecido ou lança um novo:

De qualquer forma, o runner é destruído após seu job. O ciclo de vida completo, os pools a quente, a concorrência e por que um job pode esperar estão em Como funciona o provisionamento. Além dos quatro presets, você pode criar configurações de runner personalizadas com seus próprios rótulos, e a página de Runners no dashboard é onde você gerencia tudo isso.

Uma estratégia de migração que funciona#

Você não precisa de uma migração de uma só vez, e sugerimos evitá-la. Os rótulos hospedados pelo GitHub continuam funcionando lado a lado com os rótulos latchkey-*, então você pode mover um job de cada vez e comparar os dois diretamente nas suas próprias cargas de trabalho.

Um workflow instável ou lento é o melhor piloto porque minutos mais baratos, captação mais rápida e autorreparo aparecem todos onde a dor já está. Após uma semana, a página de Runners lhe dá custo, economia e atividade de reparos para julgar; quando você estiver convencido, a ferramenta Migrate Runners na página de Runners (owners e admins) abre pull requests prontos para merge que trocam até 20 repositórios de uma vez; o passo a passo completo está em Migre dos runners hospedados pelo GitHub. Jobs que precisam de GPU, Windows, macOS ou hosts arm64 permanecem nos hospedados pelo GitHub ou outros runners, e misturar dentro de um único workflow é normal.

Decidindo entre provedores? A biblioteca Learn tem um hub de comparação de runners independente cobrindo hospedados pelo GitHub, Blacksmith, BuildJet e mais, além de uma calculadora de custos do GitHub Actions para estimar gastos com seus próprios números antes de trocar qualquer coisa.