Menu da documentação
Primeiros passos
Painel e análises
- Painel em resumo
- Análise de custo
- Desempenho de pipeline
- Insights de otimização
- Knowledge Base
- Conecte seu agente de IA
Runners gerenciados
- Visão geral dos runners
- Execute seu primeiro job
- Migre dos hospedados pelo GitHub
- Latchkey CLI
- A página de Runners
- Runners personalizados (AI Scan)
- Autorreparo
- Imagem e software do runner
- Provisionamento e pools a quente
- Limites e concorrência
Cache
Equipe e notificações
Faturamento e planos
Ajuda
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.
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:
Dois desses merecem um porquê. O teto de 4 horas é o mesmo mecanismo de segurança que impede que as repetições do autorreparo 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.
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-lateste 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.