Node.js adota uma LTS por ano a partir de outubro de 2026

O Node.js oficializou em abril de 2026 uma mudança estrutural no modelo de lançamentos: a partir de outubro de 2026, haverá uma versão major por ano, lançada em abril e promovida a LTS em outubro. A novidade principal é que todo release se torna LTS — acabando com a distinção entre versões pares (suportadas) e ímpares (descartadas em 6 meses).

O que muda na prática

Até hoje, quem mantém aplicação em produção precisava escolher apenas versões pares do Node.js para ter suporte prolongado. Versões ímpares — como a 21 e a 23 — tinham vida útil de apenas 6 meses, forçando atualizações rápidas ou saltos diretos. A nova política elimina essa divisão.

O ciclo documentado no blog oficial é direto: "As of October 2026: One major release per year (April), with LTS promotion in October. Every release becomes LTS." Na prática, quem roda SaaS ou API em Node ganha um calendário mais previsível — uma janela anual de atualização planejável, com 30 meses de suporte garantido por versão.

• Versão nova em abril de cada ano — estável para testes desde o lançamento.
• Promoção a LTS em outubro — mesmo ciclo, sem versão "descartável" no meio.
• 30 meses de suporte ativo por release, seguido de maintenance até o fim do ciclo.
• Versões ímpares deixam de existir como categoria separada.

Impacto em projetos que já estão em produção

Quem opera com Node.js v20 precisa agir antes: o v20 LTS encerra suporte em abril de 2026. Migrar para v22 ou v24 (quando disponível) é o caminho natural. A partir de 2027, o planejamento fica mais simples — basta acompanhar o release de abril e decidir quando promover no CI/CD.

Para quem usa Docker em produção, o impacto aparece nas tags de imagem. Imagens fixadas em versões ímpares antigas (ex.: node:21-alpine) já estão sem patch. Com o novo modelo, qualquer tag LTS futura representa uma versão com suporte real — sem precisar verificar se o número é par.

Por que a mudança aconteceu agora

A política de versões ímpares como "current" com vida curta criou um padrão histórico: adoção quase nula fora de ambientes de teste. A maioria dos projetos ignorava versões ímpares por completo, o que reduzia o feedback de produção disponível para os mantenedores antes da promoção a LTS. Com todos os releases virando LTS, a tendência é que cada versão receba carga real mais cedo — e bugs de borda apareçam antes do ciclo de suporte longo.

Para quem planeja stack no início de 2027 em diante, o calendário fica análogo ao do Go ou Python: uma versão relevante por ano, com janela definida para migração. Menos decisão de "qual versão seguir", mais execução. O guia Node.js 27 LTS: novo schedule e o que muda no seu CLI detalha os passos práticos para adaptar projetos ao novo ciclo.