Artigo Build·Desenvolvimento·10 min de leitura

Node.js 27 LTS: novo schedule e o que muda no seu CLI

Node.js muda para um release major por ano. Veja como adaptar seu CLI ou SaaS ao novo schedule de LTS, evitar breaking changes e planejar suporte.

Por Vitor Morais

Fundador do MochaLabz · publicado em 26 de abril de 2026

O novo schedule de release do Node.js muda uma convenção que durou anos: a partir de agora, sai um release major por ano em abril, e todo release — incluindo os ímpares como o 27 — passa a ter promoção para LTS em outubro. Quem mantém uma CLI open-source, um micro-SaaS ou um pacote npm precisa entender essa mudança antes de tomar decisões de suporte para clientes.

O modelo antigo era simples de decorar mas gerava confusão: versões pares viravam LTS, ímpares ficavam no esquecimento. Com a nova cadência, não há mais 'versão descartável'. Todo major entra no ciclo de suporte ativo, o que é bom para quem publica ferramentas para terceiros — mas exige atenção ao timing de upgrade para não deixar usuários em versão sem suporte.

O que mudou de verdade no schedule do Node.js

Historicamente, o Node.js seguia o padrão de releases pares para LTS e ímpares como 'Current' sem promoção garantida. Isso criava uma situação estranha: versões como Node.js 19, 21 e 23 chegavam, tinham alguns meses de vida e eram descontinuadas sem nunca virar LTS. Devs que queriam estabilidade precisavam esperar o próximo número par.

O novo modelo elimina essa distinção. Cada versão major lançada em abril tem uma janela definida: fase 'Current' por cerca de seis meses e, em outubro, promoção formal para LTS com ciclo de suporte ativo. Isso significa que o Node.js 27, lançado em abril de 2026, vira LTS em outubro de 2026 — algo inédito para uma versão de número ímpar.

Por que o Node.js mudou?

A pressão veio de dois lados: empresas reclamavam da cadência de 2 anos entre LTS estáveis, e mantenedores de ferramentas sofriam com versões ímpares abandonadas cedo demais. Um major por ano com LTS garantido resolve os dois problemas.

Abril: novo release major no canal 'Current'.
Outubro: promoção do release atual para LTS.
Todo major vira LTS — acabou a distinção par/ímpar.
Versões antigas continuam no ciclo de 'Maintenance' antes de EOL.
Canal Alpha disponível meses antes do release final para testar breaking changes.

Impacto direto para quem mantém CLI em Node.js

Se você tem uma CLI publicada no npm — seja um gerador de projetos, um script de automação ou uma ferramenta de build — o novo schedule muda o que você precisa declarar no campo engines do package.json. Antes, a prática comum era fixar >=18 ou >=20 (versões LTS estáveis). Agora, com o 27 entrando em LTS em outubro, seus usuários vão começar a rodar a CLI em versões novas mais rápido.

package.json — campo engines atualizado

{
  "name": "minha-cli",
  "version": "1.4.0",
  "engines": {
    "node": ">=20"
  }
}

Definir >=20 ainda é seguro para a maioria dos cenários porque o Node.js 20 segue em suporte ativo por alguns anos. Mas se sua CLI usa APIs que mudaram no 22 ou no 24, você pode ter usuários em 27 esperando comportamento diferente. A recomendação prática: rode sua suíte de testes explicitamente contra o canal 'Current' (Node.js 27) assim que ele entrar em abril, não espere outubro.

GitHub Actions — matriz com versão Current

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [20, 22, 27]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

Adicione node@27 à matriz de CI agora

Não espere usuários reportarem erro. Incluir a versão 'Current' na matriz do GitHub Actions custa zero e te avisa antes do LTS chegar. Descobrir um breaking change em outubro é muito pior do que em maio.

Como o canal Alpha ajuda a detectar breaking changes antes

O Node.js disponibiliza builds Alpha meses antes do release oficial de abril. Esses builds são instáveis por definição, mas servem exatamente para testar breaking changes — mudanças em APIs V8, behavior de fetch nativo, alterações no módulo crypto, flags de linha de comando renomeadas ou removidas.

Para um freelancer que vende uma ferramenta de CLI para clientes, testar no Alpha não é paranoia: é o tipo de ação que evita passar vergonha quando um cliente atualiza o Node dele e sua CLI para de funcionar. O processo é rápido: você baixa o build Alpha via nvm ou fnm, roda seus testes, anota o que quebrou e abre issue ou já corrige.

Instalar versão Alpha com nvm

# Listar versões disponíveis incluindo nightly/alpha
nvm ls-remote --no-colors | grep 'v27'

# Instalar e testar isolado
nvm install v27.0.0-alpha.1
nvm use v27.0.0-alpha.1

npm ci
npm test

# Voltar pra versão de produção
nvm use 20

O ponto cego mais comum de CLIs que quebram entre versões é a dependência de APIs internas do V8 acessadas via bindings nativos (pacotes com .node compilado). Se sua stack usa algum addon nativo — bcrypt, bindings de SQLite, sharp para imagens — esses são os primeiros a testar. Pure-JS não tem esse problema.

Timeline de suporte: quanto tempo cada versão dura

Com o novo schedule, cada versão major tem uma vida útil definida. O ciclo padrão é: seis meses como 'Current', depois entra em LTS ativo por cerca de dois anos, e mais um ano em 'Maintenance' (só patches de segurança críticos). O total gira em torno de três anos e meio de suporte por versão.

Ciclo de suporte por fase — modelo novo
Fase	Duração aproximada	O que recebe
Current	~6 meses (abr–out)	Todas as features, bugs, breaking changes
LTS Ativo	~2 anos	Bug fixes, patches de segurança, algumas features
Maintenance	~1 ano	Apenas patches de segurança críticos
EOL	—	Sem suporte oficial; migre imediatamente

Para um micro-SaaS rodando em produção, a regra de ouro continua sendo: siga LTS ativo, não 'Current'. Mas para ferramentas que você publica para outros devs — onde o usuário controla a versão dele — sua CLI precisa pelo menos funcionar no Current, mesmo que não seja oficialmente suportada. Isso diferencia uma ferramenta profissional de um script pessoal.

Onde o Node.js 27 deve mudar comportamento na prática

Releases majors do Node.js historicamente trazem breaking changes em áreas específicas: atualização do V8 (que pode mudar comportamento de regex, Promise, ou Intl), remoção de flags experimentais que viraram estáveis, e mudanças em módulos built-in como fs, http e crypto. Os pontos que mais afetam CLIs e micro-SaaS indie são:

`fetch` nativo: cada versão estabiliza mais partes da API; código que dependia de node-fetch como polyfill pode ter conflito.
*`--experimental-` flags removidas**: features que eram experimentais em versões anteriores podem ser promovidas ou removidas sem aviso de deprecation longo.
ESM vs CJS: o comportamento de require() de arquivos .json e interop entre CommonJS e ESM continua evoluindo.
Permissões de arquivo: mudanças em fs.chmod e comportamento de umask em diferentes sistemas.
`crypto` e TLS: versões mínimas de protocolo podem ser bumpeadas, quebrando conexões com servidores antigos.

Se sua CLI lê arquivos de configuração em JSON usando require(), vale checar o behavior no Node.js 27 — a semântica de require(json) dentro de ESM mudou entre versões recentes. Um padrão mais seguro é usar fs.readFileSync + JSON.parse, que funciona igual em qualquer versão moderna.

Leitura de config.json — padrão seguro entre versões

import { readFileSync } from 'node:fs';
import { join } from 'node:path';

function loadConfig(configPath: string): Record<string, unknown> {
  const raw = readFileSync(join(process.cwd(), configPath), 'utf-8');
  return JSON.parse(raw);
}

export const config = loadConfig('minha-cli.config.json');

Planejar suporte para clientes que usam versões antigas

A situação mais comum para quem vende serviço de manutenção de CLI ou SaaS node é o cliente que ainda roda Node.js 18 — porque "está funcionando". Com o novo schedule, o prazo de EOL de cada versão fica mais claro, o que te dá argumento concreto para cobrar uma migração: mostrar a data de EOL da versão atual do cliente e o custo de manutenção em versão sem suporte.

Se você cobra por projeto de migração de Node.js, o novo schedule também cria oportunidade de proposta recorrente: a cada outubro, um major novo entra em LTS — é o momento natural para revisitar a infraestrutura do cliente. Isso se encaixa bem em contratos de retainer, que vale muito mais do que projeto pontual para a sua receita mensal como freelancer. O artigo sobre precificação de SaaS MVP tem a lógica de como estruturar isso como produto.

Node.js 18 entra em EOL em abril de 2025

Se você ou seu cliente ainda rodam Node.js 18 em produção, a janela de Maintenance já encerrou ou está encerrando. Patches de segurança críticos param. Migrar para o 20 ou 22 antes de testar o 27 é o primeiro passo — não pule versões sem testar a intermediária.

Checklist de migração: do Current ao LTS em produção

O processo de atualização não é rocket science, mas tem uma sequência que evita surpresa em produção. Para uma CLI publicada no npm ou um SaaS rodando em Vercel/Cloudflare Workers, o fluxo abaixo cobre os principais pontos de atenção. Nota: Workers da Cloudflare têm sua própria runtime baseada em V8 e não seguem exatamente a versão do Node.js — verifique a compatibilidade separadamente para esse ambiente.

Instale o Node.js Current via nvm em ambiente de dev isolado.
Rode o teste de fumaça: npm ci && npm test. Anote qualquer falha antes de mudar código.
Cheque addons nativos: liste dependências com .node binário e busque releases compatíveis.
Valide o `engines` no package.json: atualize para refletir o mínimo testado.
Adicione a versão nova à matriz de CI no GitHub Actions para rodar em todo PR.
Monitore o CHANGELOG oficial do Node.js na semana do release para breaking changes de última hora.
Atualize produção em outubro, quando o major já tem o badge de LTS e a comunidade reportou os bugs mais críticos.

Para SaaS hospedado no Vercel, a atualização de runtime é feita no package.json via engines ou nas configurações do projeto. O Vercel tende a suportar versões LTS rapidamente após o release oficial — mas não assuma: verifique na documentação deles qual versão está disponível antes de fazer o deploy. O mesmo vale para Cloudflare Workers, que tem seu próprio processo de atualização de runtime independente do ciclo do Node.js.

Perguntas frequentes

O Node.js 27 vai ser LTS mesmo sendo versão ímpar?+

Sim. Com o novo schedule de release, a distinção entre versões pares e ímpares deixou de existir para fins de LTS. Todo major lançado em abril será promovido para LTS em outubro, incluindo o 27. É uma mudança fundamental no modelo de suporte.

Preciso migrar agora para o Node.js 27 ou posso esperar?+

Para produção, não migre ainda — espere outubro quando o 27 receber o badge de LTS e os bugs mais críticos já tiverem sido reportados e corrigidos. O que você deve fazer agora é rodar seus testes contra o canal Current para descobrir breaking changes com antecedência.

Como testar minha CLI no Node.js 27 sem afetar meu ambiente de dev?+

Use `nvm` ou `fnm` para instalar a versão 27 em paralelo com sua versão atual. Crie uma shell separada com `nvm use 27`, rode `npm ci && npm test`, e depois volte com `nvm use 20`. Seu ambiente de produção não é afetado.

O que é o canal Alpha do Node.js e como acessá-lo?+

São builds de pré-lançamento disponibilizados antes do release de abril. Você pode listá-los via `nvm ls-remote` e instalar pelo número de versão completo, como `v27.0.0-alpha.1`. Não use em produção — serve exclusivamente para testar compatibilidade e reportar bugs.

Meu SaaS roda no Vercel. Preciso fazer algo diferente?+

O Vercel gerencia a runtime Node.js por conta própria. Configure o campo `engines` no seu `package.json` e verifique na documentação do Vercel qual versão LTS está disponível como opção. O Vercel normalmente suporta versões LTS rapidamente após o release oficial.

O que acontece se eu ignorar o EOL de uma versão do Node.js em produção?+

Você para de receber patches de segurança críticos. Para SaaS com dados de usuário ou CLI distribuída para clientes, isso é risco real de CVE sem correção. Além disso, ecossistemas de pacotes como o npm costumam dropar suporte a versões EOL, o que pode quebrar instalações futuras.

#nodejs-lts#nodejs-27#cli-nodejs#release-schedule#javascript#solopreneur#indie-hacker

Node.js 27 LTS: novo schedule e o que muda no seu CLI

O que mudou de verdade no schedule do Node.js

Impacto direto para quem mantém CLI em Node.js

Como o canal Alpha ajuda a detectar breaking changes antes

Timeline de suporte: quanto tempo cada versão dura

Onde o Node.js 27 deve mudar comportamento na prática

Planejar suporte para clientes que usam versões antigas

Checklist de migração: do Current ao LTS em produção

Perguntas frequentes

Artigos relacionados

Tabela de preços dinâmica com Stripe e Next.js

Feature flags no Next.js com Vercel Flags sem pagar terceiro

Segurança indie: 5 camadas que seu SaaS precisa (sem overkill)

UUID v7 no PostgreSQL: quando migrar e ganhar 2x de performance