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.

Por Daniel Zoghalchali·Latchkey

Resumo

Um job do Latchkey CI pode definir timeout-minutes até 180 (30 por padrão), um job da CLI roda por até 3 horas, e um job do Latchkey on GH por até 4 horas, ou até 8 se ainda estiver em execução ao completar 4 horas; 40 runners ocupados concorrentes por workspace para começar.
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, ou até 8 se o job ainda estiver em execução ao completar 4 horas
Jobs concorrentes	Definido pelo plano: Developer 20, Launch 40, Scale 80 runners ocupados por workspace, Enterprise por contrato (runners a quente ociosos e runners estacionados não contam); um teste gratuito usa o número do Launch
Limite de gastos	Nenhum por padrão; um owner ou admin define um em dólares americanos na página Billing. No limite, o Latchkey recusa novos jobs, retém os que estão na fila e interrompe os que estão em execução, incluindo jobs do GitHub Actions em runners do Latchkey; ele é redefinido a cada mês do calendário.
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:

durationUm job se aproxima de 4 horasUm job roda por até 4 horas, ou até 8 se ainda estiver em execução ao completar 4 horas, 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.

concurrencyJobs ficam na fila em momentos de picoCada plano define o número de runners ocupados por workspace (Developer 20, Launch 40, Scale 80; um teste gratuito usa o número do Launch; os limites do Enterprise são definidos em contrato), e runners a quente ociosos e runners estacionados 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, o plano seguinte aumenta esse número.

platformVocê precisa de Windows, macOS ou arm64Mantenha 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.

diskJobs enchem o discoO 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 limite de 4 horas por job e o seu teto rígido de 8 horas são o mesmo mecanismo de segurança que impede que as repetições do autorreparo inflem sua conta: juntos, eles garantem 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 suas vagas de concorrência, 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-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, ou até 8 se o job ainda estiver em execução ao completar 4 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?

Cada plano define esse número: Developer 20, Launch 40, Scale 80 runners ocupados simultâneos por workspace, e um teste gratuito usa o número do Launch. Os limites do Enterprise são definidos em contrato. Se você fica na fila com frequência por causa do seu número, o plano seguinte o aumenta.

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.

References

GitHub Actions documentation