GitHub Actions e self-hosted runners: prazo de versão mínima até 16 de março de 2026

Resumo executivo

No changelog de 5 de fevereiro de 2026 (atualizado em 20/02), o GitHub confirmou que o enforcement de versão mínima para configuração/registro de self-hosted runners foi estendido para 16 de março de 2026.

O requisito informado é claro: runners precisam estar em **v2.329.0 ou superior antes de executar ./config.sh**.

Essa diferença é importante porque o bloqueio anunciado é no momento de registro/configuração, não no simples ato de executar jobs em um runner já registrado.

O que exatamente muda

Segundo o anúncio oficial:

• de 2026-02-23 a 2026-03-13, há brownouts programados de configuração/registro;
• em 2026-03-16, começa o bloqueio permanente para registro abaixo de v2.329.0;
• o impacto informado é para GitHub.com (GHES não entra nessa mudança).

Também houve detalhamento para quem usa ARC (Actions Runner Controller): as imagens de runner precisam carregar versão compatível.

Não confundir dois mecanismos de bloqueio

Esse ponto costuma gerar erro de comunicação entre times:

1. Enforcement de registro/configuração (anuncio do dia 5/2): bloqueia onboarding de runner antigo.
2. Política contínua de atualização (docs): se updates automáticos estiverem desabilitados, o runner precisa ser atualizado em até 30 dias após release, senão jobs podem parar de enfileirar.

Ou seja: mesmo que você passe no corte de registro, ainda pode sofrer indisponibilidade por atraso contínuo de patch.

Por que isso vira incidente em empresas

Os maiores riscos aparecem em três lugares:

• imagem base de runner congelada sem pipeline de refresh;
• autoscaling com templates antigos em pools efêmeros;
• inventário incompleto de runners por organização/projeto.

Quando chega brownout, o problema parece "surpresa de plataforma", mas normalmente é falta de governança de imagem e ciclo de patch.

Playbook de remediação em 7 passos

1. Inventariar todas as fontes de provisionamento (VM, container, ARC, scripts manuais).
2. Identificar quem ainda registra abaixo de v2.329.0.
3. Atualizar imagens e scripts para fixar versão mínima compatível.
4. Recriar runners de templates legados (não apenas atualizar um host isolado).
5. Testar registro durante janela de brownout para validar operação real.
6. Definir SLO interno de update de runner (ex.: máximo 14 dias após release).
7. Monitorar release feed do actions/runner para evitar novo ciclo de urgência.

Indicadores que valem acompanhar

• percentual de runners registrados em versão suportada;
• tempo médio entre release e rollout da imagem interna;
• falhas de registro por versão durante brownout;
• fila de jobs por grupo de runner após update.

Sem esses indicadores, a equipe só descobre problema quando pipeline crítica para.

Conclusão

O prazo de 2026-03-16 não é apenas ajuste técnico. É um teste de maturidade operacional do seu stack de CI.

Times que tratam runner como artefato versionado de plataforma, com refresh contínuo e monitoramento, atravessam esse tipo de enforcement com baixo impacto. Times que tratam runner como "servidor que um dia foi configurado" tendem a sofrer parada evitável.

Pergunta final: hoje você consegue provar, em minutos, quais pools ainda tentam registrar abaixo de v2.329.0?

Fontes

• Notice of upcoming Actions runner minimum version enforcement (extended to March 16) - publicado em 2026-02-05 (com atualização em 2026-02-20)
• Self-hosted runners reference (runner software updates) - documentação oficial
• actions/runner releases - repositório oficial de releases