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

concurrencyJobs ficam na fila em momentos de picoO 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.

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