ST Logo
Back to Blog
Full Stack

Node.js 27 and the New Annual Release Cycle: How to Plan Your Upgrades

Starting with Node.js 27, Node ships one major release a year and every release becomes LTS. Here is what the new Alpha, Current and LTS phases mean for your services and CI.

Sanjay ThakurSeptember 30, 20265 min read
Node.js 27 and the New Annual Release Cycle: How to Plan Your Upgrades

October 2026 marks a turning point for Node.js. Node.js 27 is the first major version under a new release model: one major release per year, every release becomes LTS, and a new Alpha phase replaces the old odd-numbered "Current-only" lines. If you maintain Node services, CLIs, or Next.js apps deployed to Vercel, the change affects how you pin versions and plan upgrades. Here is what changes and a practical checklist for adapting.

What Is Changing

Until now Node.js shipped two majors a year. Even-numbered versions (20, 22, 24, 26) became LTS; odd-numbered ones (21, 23, 25) were short-lived and saw little production use. The project's own reasoning is simple: most users wait for LTS, and maintaining four or five active release lines was becoming hard for a volunteer team to sustain.

Starting with Node.js 27, each yearly release goes through three phases:

PhaseDurationPurpose
Alpha~6 months (Oct to Mar)Early testing, semver-major changes still allowed
Current~6 months (Apr to Oct)Stabilization, library authors add support
LTS30 monthsSecurity and critical fixes

That's 36 months of support from the first Current release to end-of-life. Version numbers also line up with the calendar: 27.0.0 becomes Current in 2027, 28.0.0 in 2028.

For Node.js 27 specifically, the published plan is: Alpha from October 2026, Current in April 2027, LTS in October 2027, and end-of-life in April 2030.

Where Things Stand Today

As of late September 2026:

  • Node.js 26 is the Current release and the last one under the old model. It follows the familiar path to LTS and reaches end-of-life in April 2029.
  • Node.js 24 (Krypton) and Node.js 22 (Jod) are LTS lines.
  • Node.js 20 (Iron) and Node.js 25 are already end-of-life.

If anything in your fleet still runs Node 20, that's the first thing to fix. It no longer receives security patches.

What It Means in Practice

1. Pin an LTS line explicitly

Production should run Active or Maintenance LTS, never Alpha. Make the version explicit in every place that can pick one:

{
  "engines": {
    "node": ">=22 <27"
  }
}

# .nvmrc
24

On Vercel, the Node.js version is chosen in Project Settings or via the engines.node field in package.json, so keeping engines accurate matters beyond local development.

2. Test against the Alpha in CI, not in production

The Alpha phase is the new early-warning window, similar to what odd-numbered releases were meant to be. Add it as a non-blocking CI job so you learn about breaking changes months before they reach an LTS:

# .github/workflows/ci.yml
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [22, 24, 26]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

Once Node 27 Alpha builds are published, add a separate job for it with continue-on-error: true so failures are visible but don't block merges.

3. Fail fast on unsupported runtimes

A small runtime guard at startup is cheap insurance for CLIs and services that may be run in environments you don't control:

// src/runtime-check.ts
const [major] = process.versions.node.split('.').map(Number)
const MIN_MAJOR = 22

if (major < MIN_MAJOR) {
  console.error(
    `This app requires Node.js ${MIN_MAJOR}+ (found ${process.versions.node}). ` +
      'See https://nodejs.org/en/about/previous-releases'
  )
  process.exit(1)
}

4. Simplify your upgrade calendar

The new model makes planning much easier. There is exactly one new major a year and one LTS promotion each October. A reasonable cadence for most teams:

  • October: new LTS arrives. Start testing it in staging.
  • Q1 of the next year: move production to the new LTS once your dependencies support it.
  • Every month: take LTS patch releases, since these carry security fixes.

With 30 months of LTS per release, you can also choose to skip every other LTS if your team prefers fewer, larger upgrades, and still stay within support.

5. Library authors: update your support matrix

If you publish packages, the old "support all active LTS lines" rule still works, but it's worth stating clearly in your README which majors you test against, and treating the Alpha as a signal to fix deprecations early.

Key Takeaways

  • Node.js moves to one major release per year, starting with Node.js 27 in October 2026.
  • Every release becomes LTS; the odd/even distinction is gone.
  • New lifecycle: Alpha (6 months) → Current (6 months) → LTS (30 months), for 36 months of total support.
  • Node.js 26 is the last release under the old model; Node.js 20 is already end-of-life.
  • Pin LTS in engines and .nvmrc, test the Alpha in non-blocking CI, and plan upgrades around October.

Resources

Node.jsJavaScriptDevOpsTooling