O GitHub marcou para 23 de setembro de 2026 a remoção do Node 20 dos runners do GitHub Actions. O prazo importa porque JavaScript actions não usam necessariamente o Node que o seu workflow instala para a aplicação: elas são executadas pelo runtime embutido no próprio runner, de acordo com o campo runs.using do arquivo de metadados da action. Desde 16 de junho de 2026, o Node 24 já é o padrão para essas actions; em 23/9, o Node 20 deixa de existir como opção no runner.
Na prática, o risco não está apenas em workflows que mencionam “Node 20” de forma explícita. Um arquivo YAML pode parecer atualizado e ainda chamar uma action antiga cujo action.yml declara node20. O objetivo da auditoria, portanto, é localizar dependências de actions, testar o conjunto inteiro sob Node 24 e corrigir runners incompatíveis antes do corte.
O que muda em 23 de setembro
O cronograma oficial do GitHub passou por ajustes. A nota de 25 de agosto de 2026 atualizou a data final de remoção para 23 de setembro. O Node 20, por sua vez, chegou ao fim de vida no projeto Node.js em 30 de abril de 2026. O GitHub começou a usar Node 24 por padrão em 16 de junho e manteve uma válvula de escape temporária para quem ainda precisava de Node 20.
- Até 23/9: é possível testar antecipadamente com FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true.
- Até 23/9: o opt-out temporário ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true ainda permite manter Node 20 em cenários suportados pelo runner.
- Depois de 23/9: essa saída deixa de funcionar porque o Node 20 será removido do runner.
Fonte principal: GitHub Changelog — Deprecation of Node 20 on GitHub Actions runners. O calendário de versões do Node.js confirma o fim de vida da linha 20 em 30 de abril de 2026: Node.js Release schedule.
Primeiro: não confunda o Node da action com o Node do seu projeto
Esse é o ponto mais importante para evitar uma falsa sensação de segurança. JavaScript actions são executadas por uma cópia de Node mantida dentro do runner. A documentação do runner descreve executáveis em diretórios próprios, como externals/node20 e externals/node24, e deixa claro que esse runtime não é o Node encontrado no PATH.
Já actions/setup-node instala ou seleciona a versão de Node usada pelos comandos da sua aplicação, como npm, pnpm, yarn, testes e builds. Assim, um workflow pode instalar Node 22 ou 24 para o projeto e, no mesmo job, executar uma action antiga ainda empacotada para Node 20. Para a auditoria do corte de 23/9, o que interessa é a versão declarada pelas JavaScript actions.
Referências: Node.js Connection Check do Actions runner e actions/setup-node.
Checklist de auditoria dos workflows
1. Faça um inventário de todos os usos de actions
Comece pelos arquivos em .github/workflows e liste cada ocorrência de uses:. Inclua actions do GitHub, actions de terceiros, workflows reutilizáveis e actions locais. Em repositórios grandes, uma busca por “uses:” nos arquivos YAML é mais confiável do que revisar workflow por workflow visualmente.
Não pare no primeiro nível. Um workflow reutilizável chamado por outro repositório pode conter suas próprias actions antigas. O mesmo vale para uma composite action local: ela pode encadear outras actions por baixo.
2. Descubra quais referências ainda dependem de node20
Para cada action encontrada, abra a versão efetivamente referenciada pelo workflow — tag, branch ou SHA — e verifique o arquivo action.yml ou action.yaml. Em uma JavaScript action, procure o campo runs.using. A sintaxe do GitHub aceita atualmente node20 e node24; o alvo da migração é node24.
Se a referência estiver presa a uma versão antiga, consulte as notas de versão da action. Actions oficiais importantes já migraram: por exemplo, actions/checkout informa Node 24 a partir da linha v5, e actions/setup-node também usa Node 24 em versões atuais. Não atualize cegamente apenas para “o maior número”: mudanças de major podem trazer alterações de comportamento que precisam entrar no teste.
Referências: Metadata syntax for GitHub Actions, actions/checkout e actions/setup-node.
3. Force Node 24 em uma branch de teste
Antes de trocar todas as referências, execute os workflows críticos com FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true definido no ambiente do workflow ou do runner. Esse mecanismo foi disponibilizado justamente para antecipar a migração. A meta é exercitar build, testes, publicação de artefatos, deploy, autenticação, caches e qualquer etapa que use actions JavaScript.
O teste deve reproduzir os caminhos que normalmente só aparecem em release ou produção. Um workflow que passa em pull request pode falhar apenas em um job de publicação, porque esse job chama actions diferentes ou usa runners diferentes.
4. Audite os runners self-hosted
O corte também é um problema de infraestrutura. O GitHub informa que Node 24 é incompatível com macOS 13.4 e versões anteriores. Além disso, Node 24 não tem suporte oficial a ARM32; por isso, runners self-hosted ARM32 deixam de ser suportados após a depreciação do Node 20.
Atualize o software do runner e inventarie sistema operacional e arquitetura de cada pool. Isso é especialmente importante em organizações que mantêm imagens antigas congeladas ou runners efêmeros construídos a partir de templates próprios. Em setembro de 2026 há ainda um segundo prazo próximo: o GitHub Enterprise Cloud inicia em 25 de setembro a aplicação integral de uma versão mínima para runners self-hosted. É um cronograma separado, mas pode atingir a mesma frota.
Referências: Self-hosted runners reference e Minimum version enforcement timeline for self-hosted runners.
5. Trate actions próprias como software que precisa de release
Se a organização mantém JavaScript actions internas, a correção não termina no YAML consumidor. A action deve mudar seu metadado para runs.using: node24, recompilar o bundle distribuído quando aplicável e passar por testes de integração. O GitHub recomenda testes automatizados e um processo de release claro para actions JavaScript, justamente porque dependências costumam ser distribuídas junto com o código compilado.
Depois de publicar a versão compatível, atualize os consumidores de forma controlada. Para actions de terceiros, o GitHub recomenda fixar referências em SHA completo quando a prioridade é imutabilidade; tags são mais convenientes, mas podem ser movidas. O melhor fluxo para esta migração é validar a versão compatível e então fixar o ref que efetivamente passou nos testes.
Referências: Releasing and maintaining actions e Secure use reference.
Como priorizar o que corrigir primeiro
| Situação | Risco antes de 23/9 | Ação recomendada |
|---|---|---|
| Action externa antiga com runs.using node20 | Alto | Atualizar para release compatível com Node 24 e testar |
| Action interna JavaScript em node20 | Alto | Migrar metadado, rebuildar bundle e publicar nova versão |
| Runner self-hosted macOS 13.4 ou anterior | Alto | Atualizar o sistema ou mover o job para outro runner |
| Runner self-hosted ARM32 | Alto | Planejar migração de arquitetura; Node 24 não tem suporte oficial |
| Workflow já passa com FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 | Menor | Remover dependências antigas, consolidar refs e repetir testes críticos |
| Projeto usa Node 20 via setup-node, mas actions estão em Node 24 | Diferente | Tratar a migração do runtime da aplicação separadamente; Node 20 já está EOL |
Planeje rollback sem depender do Node 20
Até 23 de setembro, o opt-out ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true pode servir como contenção temporária. Ele não é um plano de rollback para depois do corte. Quando o runtime for removido do runner, não haverá variável de ambiente capaz de restaurá-lo.
O rollback útil é outro: mantenha o commit anterior do workflow, registre os SHAs das versões testadas, faça a mudança em pull request e tenha uma referência Node 24 compatível conhecida para cada action crítica. Se uma atualização de major quebrar o comportamento, você precisa voltar para um ref anterior que também seja compatível com Node 24 — não para uma versão que dependa de Node 20.
Sequência prática para concluir antes de 23/9
- Inventarie todas as ocorrências de uses: em workflows, workflows reutilizáveis e actions locais.
- Classifique quais refs são JavaScript actions e verifique runs.using na versão realmente consumida.
- Atualize actions ainda presas a Node 20, lendo as breaking changes de cada major.
- Rode os fluxos críticos com FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true.
- Valide release, deploy, artefatos, autenticação, caches e jobs pouco frequentes.
- Atualize runners self-hosted, removendo macOS antigo e ARM32 do caminho crítico.
- Fixe refs testados e documente um rollback que continue em Node 24.
- Remova flags temporárias depois que a migração estiver estável.
O corte de 23/9 não exige uma reescrita geral do CI, mas exige saber exatamente quais actions o workflow executa e em qual runtime elas foram publicadas. Fazer essa auditoria agora transforma uma mudança de plataforma em uma atualização controlada; deixar a descoberta para o dia da remoção transforma dependências invisíveis em falhas de pipeline.
