Node.js Goes to One Major Release a Year

For ten years Node.js developers have repeated the same folk wisdom: odd-numbered versions are for tourists, even-numbered ones are for production. This month the project retires the joke. The Node.js release schedule is changing to one major release a year, and the odd/even split disappears with it.

If you run servers, build boxes or automation on Node, this is mostly good news, with one new habit to adopt. Here is what the Node.js release team actually announced, what the dates look like, and a small script to keep your own fleet on the right side of end-of-life.

What changed in the Node.js release schedule

Under the old model Node shipped two majors a year, one in April and one in October, and only the even ones became LTS. Under the new model there is one major, in April, and every release becomes LTS. Node.js 26 is the last release line under the old model; 27 is the first under the new one.

• One major per year, released in April. Version numbers follow the calendar year of the first Current release: 27.0.0 in 2027, 28.0.0 in 2028.
• No more odd/even distinction. Node.js 27 will become LTS.
• A new Alpha phase of six months (October to March) where semver-major changes are still allowed, followed by six months of Current (April to October), then 30 months of LTS.
• Total support is 36 months from the first Current release to end of life.

The project's reasoning is refreshingly data-driven. Over a decade of usage, odd releases saw minimal adoption because most users wait for LTS, the odd/even rule confused newcomers, and juggling security releases across four or five active release lines was hard for a project that is mostly volunteer-maintained.

Managing security releases across four or five active release lines has become difficult to sustain.

The dates that matter for your servers

The Release repository publishes the authoritative dates in schedule.json. At the time of writing these are the lines you are most likely running:

• Node 22 (Jod): Maintenance LTS, end of life 2027-04-30.
• Node 24 (Krypton): Active LTS since 2025-10-28, Maintenance from 2026-10-20, end of life 2028-04-30.
• Node 26: released 2026-05-05, Active LTS from 2026-10-28, end of life 2029-04-30.
• Node 27: Alpha starts 2026-10-28, first release in April 2027, end of life 2030-04-30.

The project also states the schedule is not final and may be amended, so treat schedule.json, not a blog post (including this one), as the source of truth.

Check your fleet against schedule.json

Rather than trusting memory, query the file. This script reads the official schedule and tells you how many days remain before the Node version you are running reaches end of life. It uses only built-in fetch, so it runs on any current Node.

const URL = "https://raw.githubusercontent.com/nodejs/Release/HEAD/schedule.json";

const major = process.versions.node.split(".")[0];
const schedule = await (await fetch(URL)).json();
const entry = schedule["v" + major];

if (!entry) {
  console.log("Node " + major + " is not in schedule.json");
  process.exit(1);
}

const days = Math.ceil((new Date(entry.end) - Date.now()) / 86400000);
console.log("Node " + major + " (" + (entry.codename || "no codename") + ")");
console.log("  maintenance starts: " + (entry.maintenance || "n/a"));
console.log("  end of life:        " + entry.end + " (" + days + " days)");

if (days < 180) {
  console.error("Upgrade soon: under 180 days of support left.");
  process.exitCode = 2;
}

node node-eol.mjs
# Node 22 (Jod)
#   maintenance starts: 2025-10-21
#   end of life:        2027-04-30 (199 days)

The non-zero exit code makes it easy to wire into a nightly job or a CI step, so an approaching end of life becomes a failing check instead of a surprise.

The new Alpha channel: for CI, not production

Alpha is the genuinely new idea. Alpha releases use semver prerelease versions such as 27.0.0-alpha.1, are signed and tagged (unlike Nightly builds) and are tested through CITGM, which runs the test suites of major open-source packages against the upcoming version. They may not contain every change from main, and the API can change between releases. The audience is library authors and CI pipelines, not production.

The release team's advice is blunt: integrate Alpha into CI early, because if you only test on LTS you cannot report bugs before they reach your users. A non-blocking CI job is a cheap way to do that.

name: ci
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    continue-on-error: ${{ matrix.experimental }}
    strategy:
      fail-fast: false
      matrix:
        include:
          - node: "22"
            experimental: false
          - node: "24"
            experimental: false
          - node: "26"
            experimental: false
          # Replace with the exact alpha tag once it is published
          - node: "27.0.0-alpha.1"
            experimental: true
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci
      - run: npm test

What to do about it

• Pin servers to an LTS major in a version file or base image tag, and move off Node 22 before 2027-04-30.
• If you only ever upgraded to even versions, expect little change beyond the numbering. The project says as much.
• Library authors and tool builders: add an Alpha job to CI once 27 alphas appear in late October.
• Run the schedule check on a timer so end-of-life dates reach you before they reach production.

The takeaway: the cadence got simpler, the support window got longer, and the only new work for most teams is a non-blocking Alpha job and a calendar reminder. Your future self, staring at a Node 22 base image in April 2027, will be grateful.