Node.js 24 chega à fase LTS: o checklist de migração pra quem tem API em produção
A versão 24 (codinome Krypton) virou Active LTS e passa a ser a escolha padrão para produção. Veja o que muda de fato no runtime e o que isso custa comparado a subir major em Rails ou Java.
O Node.js↳Node.js45 conteúdosComo criar aplicações console em Node.jsDev (Back & Front) · fev 2025Entendendo o ciclo de publicação do Node.jsDev (Back & Front) · fev 2020Nodejs por baixo dos panosDev (Back & Front) · jul 2019Ver tudo em Dev (Back & Front) → 24, codinome Krypton, está listado como LTS na página oficial de releases do projeto (nodejs.org/en/about/previous-releases), depois de passar pelos seis meses obrigatórios como Current desde maio de 2025. Isso muda o cálculo de risco pra quem mantém serviço em produção: a recomendação explícita do projeto é que aplicações de produção só usem releases em Active LTS ou Maintenance LTS, nunca Current. Com a 24 nessa faixa, ela deixa de ser "a versão nova pra testar" e vira "a versão que dá pra colocar no Dockerfile do serviço que paga boleto".
O calendário que sustenta essa decisão
O ciclo do Node é previsível por desenho: toda versão nasce como Current por seis meses (janela pra mantenedores de biblioteca darem suporte antes do tráfego real chegar), e depois as pares (20, 22, 24...) sobem pra Active LTS, enquanto as ímpares (21, 23, 25) morrem ali mesmo, sem sobrevida. A página oficial confirma esse padrão na prática: a v25 nasceu em outubro de 2025 e já está com status EOL, enquanto a v22 (Jod) e a v24 (Krypton) seguem como LTS.
O texto do próprio projeto também avisa de uma mudança de regra: a partir da v27, o ciclo vira anual, e toda major passa a virar LTS depois do Current de seis meses somado a mais seis meses de fase Alpha. É bom já anotar isso, porque muda o mecanismo de seleção, não o ritmo de lançamento: hoje o intervalo entre versões LTS já é de cerca de um ano (a v20 saiu em abril de 2023, a v22 em abril de 2024, a v24 em maio de 2025), mas só as versões pares chegam a esse status, as ímpares (21, 23, 25) nascem e morrem sem nunca virar LTS. A partir da v27, esse filtro par/ímpar deixa de existir: toda major vai virar LTS, não só metade delas.
Quanto à garantia de suporte, a página é direta: LTS "tipicamente garante que bugs críticos serão corrigidos por um total de 30 meses". Não é uma data fixa publicada por versão nessa tabela, mas dá o tamanho da janela: quem migra pra 24 agora tem manutenção ativa por bastante tempo, o que justifica o esforço de portar scripts de build e imagens de CI.
O que muda de fato no runtime, não só no changelog
Três mudanças da série 22/24 pesam mais que cosmético pra quem mantém API em produção:
Permission model. O flag --experimental-permission, que restringe o que o processo Node pode acessar em disco, rede e child processes, amadureceu ao longo das últimas majors e chega mais estável na 24. Pra quem roda serviço multi-tenant ou expõe execução de código de terceiros (workers, sandboxes de plugin), isso é uma peça de segurança que antes só existia via container ou seccomp, e agora dá pra declarar na própria invocação do processo.
require(esm) nativo. A dor histórica de ecossistema misto (pacote publicado só em ESM, código legado em CommonJS) diminui: o runtime aceita carregar módulo ESM via require() sem o hack de import dinâmico dentro de wrapper. Isso não elimina o trabalho de decidir se o projeto migra pra ESM de vez, mas tira a obrigação de fazer essa migração tudo de uma vez só pra poder instalar uma dependência nova.
V8 atualizado. Cada major do Node carrega uma versão mais nova do motor V8, o que normalmente significa suporte a sintaxe ECMAScript mais recente e ajustes internos de performance do parser e do garbage collector. Isso é o tipo de mudança que raramente quebra código, mas pode alterar comportamento de timing em hot path se o serviço depende de heurística fina de GC, é a categoria de coisa que só aparece testando sob carga real, não lendo changelog.
Checklist pra quem vai migrar um serviço real
Antes de trocar a base image de node:22 pra node:24 no Dockerfile de produção:
- Native addons primeiro. Qualquer dependência que compila C++ via node-gyp ou usa Node-API precisa ser testada contra a nova versão antes de tudo. É o ponto de maior atrito histórico em upgrade de major do Node, muito mais que JavaScript puro.
- CI com matrix, não só troca direta. Rodar a suíte de testes em 22 e 24 em paralelo por um ciclo de deploy inteiro, antes de aposentar a 22, é mais barato que descobrir regressão em produção.
- Auditar flags experimentais em uso. Se o serviço já roda com
--experimental-permissionou outra flag que virou padrão ou mudou de nome entre versões, checar a lista de breaking changes específica da 24 no changelog oficial, não confiar em memória do que era assim na 20. - Revisar lockfile e npm. Toda major nova do Node normalmente sobe a versão padrão do npm junto; vale conferir se o lockfile do projeto ainda é compatível ou se precisa de
npm installlimpo. - Medir, não assumir. V8 novo pode mudar timing de GC em workload de alta alocação. Antes de declarar vitória, rodar o serviço sob carga comparável à de produção por um tempo, não só passar a suíte de testes unitários.
O que isso custa comparado a subir major em Rails ou Java
Aqui é onde a comparação vale mais que o hype de versão nova. Em Rails, o custo de migração de major do Ruby é dominado pela cadeia de gems: bundle update some com uma tarde inteira quando alguma gem crítica (Devise, Sidekiq, um driver de banco) ainda não suporta a versão nova do interpretador, e o fix costuma ser esperar o mantenedor da gem, não algo que o time controla. O Node tem o equivalente nos native addons, mas o ecossistema puro-JS costuma reagir mais rápido: pacote que só usa JavaScript raramente quebra entre majors do runtime.
Em Java, o cenário é quase oposto: a JVM tem histórico de compatibilidade binária muito forte entre LTS (Java 17 para 21, por exemplo), então o runtime raramente é o problema, o time gasta mais é revisando mudanças de garbage collector padrão ou APIs deprecadas removidas depois de anos de aviso. Node não tem esse mesmo compromisso de décadas, mas o ciclo de vida documentado na página oficial (30 meses de LTS) dá previsibilidade parecida em escala menor.
A conclusão prática: se o serviço é 100% JavaScript/TypeScript sem addon nativo pesado, subir de 22 pra 24 tende a ser mais barato que uma migração equivalente de Rails 6 para 7 com gems desatualizadas, e comparável a um bump de Java 17 para 21 em esforço de teste. Se o serviço depende de módulo nativo específico (driver de banco compilado, biblioteca de criptografia customizada), vale rodar o checklist completo antes de prometer prazo pro time.
Quando esperar o próximo ciclo
Se o serviço já está estável em Node 22 (Jod), que segue como LTS, não há urgência técnica pra migrar agora só porque a 24 virou LTS: a pressão real chega quando a 22 entrar em manutenção e depois EOL, seguindo o mesmo padrão que já tirou a 20 (Iron) de circulação. O momento de migrar de fato costuma ser ditado por dependência externa perdendo suporte pra versão antiga, não pelo calendário do Node isoladamente. Mas com a mudança anunciada pro ciclo anual a partir da v27, vale já considerar esse teste de matrix em CI como rotina permanente, e não como projeto pontual de migração.
Fonte: Node.js — página oficial de releases e calendário LTS
Este artigo foi escrito por Bisneto Braga, colunista de back-end. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de back-end, arquétipo staff engineer/consultor poliglota: já manteve monolito PHP, app Rails e serviço Java em produção. Lema declarado na bio: linguagem é ferramenta, contexto é rei. Sem torcida — a opinião dele é sempre comparativa e pragmática.
