# Limites e concorrência

> Limites de duração de job, concorrência, suporte de arquitetura, tamanhos de disco e limites de configuração de runner personalizado por plano.

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

## Summary

- Duração máxima de job de 4 horas; 20 runners ocupados concorrentes por workspace por padrão.
- Somente Linux x86_64: sem Windows, macOS, arm64 ou runners host com GPU hoje.
- Runners são de uso único; persista saídas com artefatos e caches.

## Os números

| Limite | Valor |
| --- | --- |
| Duração máxima de job | 4 horas por runner; a máquina é encerrada às 4 horas mesmo que o job ainda esteja rodando |
| Jobs concorrentes | 20 runners ocupados por workspace por padrão (runners a quente ociosos não contam); limites maiores disponíveis |
| Sistema operacional | Somente Ubuntu 24.04 LTS (sem runners Windows ou macOS) |
| Arquitetura | Somente x86_64 (amd64); sem runners host arm64 (imagens arm podem ser cross-built com docker buildx) |
| Disco | 100 GB (small, medium, large), 200 GB (xlarge), 100 a 500 GB para configurações personalizadas |
| Configurações de runner personalizadas | Developer e Launch: 2, Scale: 10, Enterprise: ilimitado |
| Região | Runners rodam em AWS us-east-1 |

## O que fazer quando você atinge um

Os números só importam no dia em que um deles morde. O que mudar do seu lado quando isso acontece:

- **Um job se aproxima de 4 horas** A máquina é encerrada às 4 horas mesmo no meio do job, então trate o teto como um limite rígido, não um orçamento. Divida o trabalho em jobs paralelos (cada um recebe seu próprio runner), ou mova-o para um tamanho maior para que o mesmo trabalho termine mais cedo.
- **Jobs ficam na fila em momentos de pico** O padrão é 20 runners ocupados por workspace, e runners a quente ociosos nunca contam contra isso. Jobs além do limite esperam na fila até um runner ocupado terminar; se seus picos ficam na fila com regularidade, limites maiores estão disponíveis.
- **Você precisa de Windows, macOS ou arm64** Mantenha esses jobs específicos nos hospedados pelo GitHub ou outros runners e misture livremente dentro do mesmo workflow. Para imagens de container arm64, cross-build com docker buildx; o QEMU vem pré-configurado na imagem.
- **Jobs enchem o disco** O autorreparo poda caches quando um disco enche no meio do job, mas se um job precisa rotineiramente de mais espaço do que seu tamanho oferece, a correção duradoura é uma configuração personalizada com até 500 GB.

Dois desses merecem um porquê. O teto de 4 horas é o mesmo mecanismo de segurança que impede que as repetições do [autorreparo](/documentation/self-healing) inflem sua conta: ele garante que um job travado não possa segurar uma máquina, ou sua fatura, indefinidamente. E o limite de concorrência conta apenas runners **ocupados**, o que é fácil de interpretar errado: um pool a quente parado ocioso não custa nenhuma das 20 vagas, então a capacidade a quente nunca compete com seus jobs reais.

## Configurações de runner personalizadas

A partir da página **Runners**, você pode criar configurações personalizadas com seus próprios rótulos `latchkey-<name>`, escolhendo o formato de CPU/memória e o tamanho de disco. O fluxo **AI Scan** analisa seus workflows e propõe a configuração certa; sua imagem é então construída automaticamente e você é notificado quando o runner está pronto para uso. Até o build da imagem terminar, jobs que apontam para aquele rótulo esperam na fila.

O guia de decisão completo, incluindo quando um formato personalizado supera um preset e quanto ele custa, está em [Runners personalizados com AI Scan](/documentation/custom-runners).

## Bom saber

- Runners são de uso único: um job por máquina, destruída em seguida. Qualquer coisa que você escreva no disco local some quando o job termina; use artefatos ou caches para persistência.
- Rótulos de runner hospedado pelo GitHub (`ubuntu-latest` e afins) continuam funcionando lado a lado; você pode migrar um job de cada vez.
- Se você precisa de GPU, Windows, macOS ou hosts arm64, mantenha esses jobs específicos nos hospedados pelo GitHub ou outros runners por enquanto e misture livremente dentro do mesmo workflow.

### Qual a duração máxima de um job em um runner Latchkey?

Quatro horas. Um job que precise de mais tempo deve ser dividido em jobs que passam trabalho entre si por artefatos, porque um job único perto do limite normalmente faz trabalho que poderia rodar em paralelo.

### Quantos jobs posso executar ao mesmo tempo?

Vinte runners ocupados simultâneos por workspace, por padrão. Se você fica na fila com frequência por causa desse teto, o limite pode ser aumentado; o painel mostra o uso simultâneo para distinguir fila de lentidão.

### Os runners Latchkey suportam Windows, macOS ou ARM?

Hoje não. Os runners Latchkey são apenas Linux x86_64, sem hosts Windows, macOS, arm64 ou GPU. Esses jobs podem continuar em runners hospedados no GitHub ou outros e conviver no mesmo workflow, então isso não impede a adoção no restante do seu pipeline.

---

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