GitHub Actions bloqueia runners auto-hospedados anteriores à 2.329.0

O GitHub começou a aplicar integralmente sua regra de versão mínima para runners auto-hospedados do Actions em 29 de setembro de 2026. Um post no changelog do GitHub mudou a data, que antes era 25 de setembro. Runners anteriores à versão 2.329.0 não conseguem mais se registrar no GitHub Enterprise Cloud. Runners desatualizados que já estão registrados deixam de pegar jobs.

Um runner auto-hospedado é o pequeno programa que uma equipe instala na própria máquina para executar workflows do GitHub Actions, em vez de usar as máquinas hospedadas do GitHub. As equipes os usam para hardware especial, redes privadas ou custo menor. Um runner instalado uma vez e nunca atualizado agora pode parar um pipeline de CI, o sistema automatizado de build e testes, sem nenhuma mudança no código.

As duas regras de versão

Dois limites separados se aplicam, segundo o post com o cronograma que o GitHub publicou em 12 de junho de 2026.

Regra	O que exige	O que acontece se você não cumprir
Registro	Versão do runner 2.329.0 ou posterior	O runner não consegue se registrar nem se registrar de novo
Execução de jobs	Cada nova versão do runner instalada em até 30 dias após sua publicação	O runner para de executar jobs, mesmo que já esteja registrado

A regra de jobs é a mais rígida das duas. Sua versão mínima fica acima do mínimo de registro, e continua mudando. Um runner pode ser novo o bastante para se registrar e ainda assim velho demais para executar um workflow.

Quem é afetado

A regra cobre o GitHub.com e o GitHub Enterprise Cloud, o serviço hospedado do GitHub para empresas. O GitHub Enterprise Cloud com residência de dados, a edição que mantém os dados em uma região escolhida, aplica a regra desde 31 de julho de 2026. O GitHub Enterprise Server, o produto que as empresas instalam nos próprios servidores, não é afetado.

Como a implantação chegou aqui

O GitHub publicou o cronograma em junho e depois fez brownouts. Um brownout é um bloqueio curto e planejado que desliga runners antigos por algumas horas para que seus donos percebam antes do prazo real.

No Enterprise Cloud, os brownouts foram das 11h às 15h, horário do Leste dos EUA, em dias definidos. Eles aumentaram a cada semana, segundo o post de junho.

Semana	Dias de brownout	O que foi bloqueado
1	24 de agosto	Registro
2	31 de agosto, 2 de setembro	Registro
3	7, 9 e 11 de setembro	Registro e execução de jobs
4	14, 16 e 18 de setembro	Registro e execução de jobs

O motivo da regra é a infraestrutura. O DevOps.com relata que o GitHub começou a reconstruir os serviços de backend do Actions no início de 2024. A nova plataforma processa mais de 120 milhões de jobs por dia. Ela também permite que empresas iniciem sete vezes mais jobs por minuto do que antes. Exigir as versões dos runners conclui essa migração ao garantir que todo runner funcione na nova plataforma, segundo o DevOps.com.

Como verificar seus runners

O post do GitHub de 28 de setembro também adiciona uma REST API para a descontinuação de versões do runner. Ela retorna as datas de descontinuação de registro e de execução das versões do runner. Uma equipe pode usá-la para ver o próximo prazo chegando, em vez de descobri-lo por um job que falhou.

Runners com atualizações automáticas ativadas cumprem a regra dos 30 dias sozinhos, diz o post de junho do GitHub. Runners que alguém atualiza à mão precisam de uma rotina regular de atualização para ficar dentro da janela.

O que isso significa para desenvolvedores

Verifique hoje cada runner auto-hospedado, antes que um build falhe. Faça uma lista de cada runner e da versão que ele informa, e atualize primeiro tudo o que estiver abaixo da 2.329.0. Essas máquinas já estão bloqueadas para registro.

Depois veja como cada runner recebe suas atualizações. Runners embutidos em uma imagem de máquina virtual ou em uma imagem de contêiner são a armadilha comum. Eles começam com a versão que ficou congelada na imagem. As equipes costumam desligar as atualizações automáticas para manter os builds reproduzíveis. Com uma janela de 30 dias, essa imagem agora precisa ser reconstruída pelo menos uma vez por mês.

Trate a regra como permanente, não como uma migração pontual. Cada nova versão do runner inicia uma nova contagem de 30 dias. Coloque a versão do runner na mesma rotina de patches do sistema operacional, e ligue a API de descontinuação ao seu monitoramento.

Fique atento a runners que ficam em silêncio. Antes dessa regra, um runner ocioso costumava significar uma máquina quebrada. Agora pode significar que o GitHub simplesmente parou de enviar jobs para ele.