# Como funciona o provisionamento

> O que acontece entre um job entrar na fila do GitHub e um runner o pegar: pools a quente, inícios a frio com registro just-in-time, o teto de concorrência e por que um job pode esperar.

Source: https://latchkey.dev/pt/documentation/runner-provisioning

## Summary

- Um job na fila é pego por um runner a quente em poucos segundos, ou uma máquina nova faz um início a frio com registro just-in-time em cerca de 10 segundos.
- Todo runner é efêmero: um job por VM, credenciais de uso único, máquina encerrada após o job.
- Hoje todo plano recebe a mesma linha de base a quente: um runner a quente sempre ligado mais capacidade estacionada em `latchkey-small`. A demanda além disso faz início a frio.
- 20 runners ocupados simultaneamente por workspace por padrão; runners a quente ociosos nunca contam contra o limite.

Quando o GitHub enfileira um job com um rótulo `latchkey-*`, um webhook avisa o Latchkey imediatamente, e o Latchkey toma uma decisão: entregar o job a um runner que já está aquecido ou lançar uma máquina nova para ele. Você nunca vê essa decisão, mas ela é a diferença entre uma captação em poucos segundos e uma em cerca de dez, e ela explica a maior parte do que esta página cobre.

## Captação a quente vs início a frio

Uma **captação a quente** significa que um runner pré-provisionado já estava online para o seu workspace: o job é entregue direto a ele e começa em poucos segundos. Um **início a frio** significa que nenhum runner a quente servia, então uma máquina nova inicializa só para aquele job, registra-se no GitHub usando uma configuração just-in-time de uso único e está executando seus passos em cerca de 10 segundos. Os dois caminhos terminam de forma idêntica: o runner pega exatamente um job e a máquina é encerrada quando o job termina.

## Pools a quente

| Plano | Pool a quente |
| --- | --- |
| Developer | Um runner `latchkey-small` a quente mais capacidade estacionada |
| Launch | A mesma linha de base: um runner a quente mais capacidade estacionada |
| Scale | A mesma linha de base: um runner a quente mais capacidade estacionada |

Hoje todo plano recebe a mesma linha de base a quente, e ela cobre apenas `latchkey-small`: um runner a quente sempre ligado, apoiado por máquinas estacionadas que retomam em segundos. Qualquer coisa além disso, e qualquer job que peça um tamanho maior, faz início a frio em cerca de 10 segundos. A capacidade a quente não custa nada enquanto está ociosa; a cobrança é por minuto de job, e um runner a quente ocioso não está executando um job.

## Efêmero, sempre

O provisionamento nunca reutiliza uma máquina. A quente ou a frio, um runner pega exatamente um job e é encerrado em seguida, junto com seu disco, e é por isso que os nomes de runner na visualização de execução do GitHub mudam a cada execução e por isso que qualquer coisa que um job escreva no disco local some quando o job termina. O lado de segurança desse design, credenciais just-in-time, rede privada e discos criptografados de uso único, é coberto em [Arquitetura de segurança](/documentation/security-architecture).

## Concorrência

Um workspace executa até **20 runners ocupados simultaneamente** por padrão, e só runners ocupados contam: runners a quente ociosos nunca consomem uma vaga, então a capacidade a quente não compete com seus jobs reais. Quando um pico precisa de mais de 20 de uma vez, os jobs excedentes ficam na fila até uma vaga liberar e então começam sozinhos; nada dá erro e nada se perde. Se seus picos entram na fila com frequência, limites maiores estão disponíveis, [contate o suporte](/support).

## Limites rígidos

- Jobs têm teto de **4 horas**; a máquina é encerrada às 4 horas mesmo que o job ainda esteja rodando.
- Os runners são apenas **Ubuntu 24.04 LTS em x86_64**: sem hosts Windows, macOS, arm64 ou GPU.
- Os runners rodam em **AWS us-east-1**.

A tabela completa, incluindo tamanhos de disco e contagens de configurações personalizadas por plano, está em [Limites e concorrência](/documentation/runner-limits).

## Por que um job pode ficar parado na fila

Quando o provisionamento não pode ou não vai lançar um runner, não há erro do lado do GitHub; o job simplesmente espera. Isso é por design: jobs direcionados a rótulos `latchkey-*` permanecem na fila do GitHub em vez de dar erro. As causas usuais:

- Um **erro de digitação no rótulo**: nenhuma configuração corresponde ao rótulo, então nada nunca pega o job.
- O **repositório não está monitorado**, ou a **configuração do runner está desabilitada**.
- Um **bloqueio de cobrança ou trial**: um trial expirado, uma assinatura vencida ou um nível gratuito esgotado em um trial sem cartão. Uma notificação "Managed runner blocked" dispara quando isso acontece, no máximo uma vez por dia.
- A **imagem de um runner personalizado ainda está sendo construída**; jobs direcionados ao rótulo dele esperam até o build terminar.
- O workspace está no seu **teto de 20 runners ocupados**; o job começa assim que uma vaga libera.

O passo a passo sintoma por sintoma, com como confirmar cada causa, está em [Solução de problemas](/documentation/troubleshooting).

### Por que meu job fica em queued?

Ou ele espera capacidade além da base quente, e nesse caso uma máquina nova faz cold start em cerca de dez segundos, ou algo o está bloqueando: o label, o monitoramento, a configuração, a cobrança, um build de imagem em andamento ou o teto de concorrência. Verifique nessa ordem.

### Qual a diferença entre pickup quente e cold start?

Um pickup quente entrega o job a uma máquina que já está rodando, em poucos segundos. Um cold start provisiona uma máquina nova com registro just-in-time e leva cerca de dez segundos. Hoje todos os planos têm a mesma base quente: um runner sempre ligado mais capacidade estacionada em `latchkey-small`.

### Runners quentes ociosos contam para o meu limite de concorrência?

Não. O padrão de 20 runners simultâneos por workspace conta apenas runners ocupados, então capacidade quente à espera de trabalho nunca consome o limite que você está acompanhando.

---

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