# 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.

Source: https://latchkey.dev/pt/documentation/runners-overview

## Summary

- Quatro tamanhos: `latchkey-small` (2 vCPU, $0.0025/min) até `latchkey-xlarge` (16 vCPU, $0.0200/min), Ubuntu 24.04 x64.
- Um job por runner, destruído em seguida; captação a quente em segundos (Launch em diante), inicializações a frio em cerca de 10 segundos.
- Todo plano inclui de 2.000 a 6.000 minutos gratuitos de runner por mês.

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](/documentation/self-healing) integrado.

## Tamanhos e preços

| Rótulo | vCPU | Memória | Disco | Preço |
| --- | --- | --- | --- | --- |
| `latchkey-small` | 2 | 8 GB | 100 GB | $0.0025/min |
| `latchkey-medium` | 4 | 16 GB | 100 GB | $0.0050/min |
| `latchkey-large` | 8 | 32 GB | 100 GB | $0.0100/min |
| `latchkey-xlarge` | 16 | 64 GB | 200 GB | $0.0200/min |

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](/documentation/runner-image-software). 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](/documentation/runner-usage-and-free-minutes).

## 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.

| Tamanho | Um bom primeiro encaixe para | Por quê |
| --- | --- | --- |
| `latchkey-small` | Lint, testes unitários, scripts, builds pequenos | A maioria dos jobs de CI é limitada por I/O ou por um único núcleo; 2 vCPU / 8 GB dão conta deles pela menor tarifa |
| `latchkey-medium` | Suítes de teste típicas de aplicativos, builds de imagens Docker | Duas vezes a CPU e a memória do small, para runners de teste paralelos e builds de imagens multiestágio |
| `latchkey-large` | Builds pesados de compilação, suítes de integração paralelas | 8 vCPU / 32 GB servem bem para trabalhos que escalam com núcleos: grandes builds em TypeScript, Rust, Java ou C++ |
| `latchkey-xlarge` | Builds de monorepo, suítes end-to-end famintas por memória | 16 vCPU / 64 GB mais o disco de 200 GB, para os jobs mais pesados que, de outra forma, precisariam ser divididos |

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`.

> ****
> Se nenhuma proporção predefinida encaixar (muita memória com CPU modesta, por exemplo, ou mais disco do que os presets oferecem), crie uma [configuração de runner personalizada](/documentation/custom-runners). Observe que runners personalizados são cobrados pela tarifa do xlarge.

## Por que as equipes mudam

- **Preço:** até 60% 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](/documentation/security-and-permissions) 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](/documentation/install-the-github-app) na sua organização.
- O repositório é [monitorado](/documentation/managing-repositories) 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](/documentation/runner-usage-and-free-minutes).

## 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](/documentation/runner-provisioning). Além dos quatro presets, você pode criar [configurações de runner personalizadas](/documentation/custom-runners) com seus próprios rótulos, e a [página de Runners](/documentation/runners-dashboard) 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](/documentation/self-healing) aparecem todos onde a dor já está. Após uma semana, a [página de Runners](/documentation/runners-dashboard) lhe dá custo, economia e atividade de reparos para julgar; quando você estiver convencido, a ferramenta **Migrate Runners** na [página de Runners](/documentation/runners-dashboard) (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](/documentation/migrate-from-github-hosted). 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](/learn/compare-runners) independente cobrindo hospedados pelo GitHub, Blacksmith, BuildJet e mais, além de uma [calculadora de custos do GitHub Actions](/learn/ci-cost/github-actions-cost-calculator) para estimar gastos com seus próprios números antes de trocar qualquer coisa.

### Quais tamanhos de runner o Latchkey oferece?

Quatro, todos Ubuntu 24.04 x64: `latchkey-small` com 2 vCPU a US$ 0,0025 por minuto, até `latchkey-xlarge` com 16 vCPU a US$ 0,0200 por minuto. Todos os planos incluem de 2.000 a 6.000 minutos de runner gratuitos por mês, conforme o plano.

### Quão rápido um runner Latchkey inicia?

Um pickup quente leva segundos nos planos Launch e superiores. Um cold start leva cerca de dez segundos. Em ambos os casos o runner é uma máquina nova: um job por runner, destruída em seguida.

### Como os runners Latchkey diferem dos hospedados no GitHub?

De duas formas que importam. A tarifa publicada é de US$ 0,0025 por minuto para 2 vCPU contra US$ 0,006 do equivalente hospedado no GitHub, e um agente de autorreparo na máquina corrige falhas transitórias como timeouts de registry e OOM durante a execução, em vez de falhar o job.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt