Node.js 26 and the LTS Release Schedule

Node.js publishes a major release every six months, in April and October, but the two are not equivalent. Even-numbered majors move into Long Term Support in October of their release year and are maintained for around thirty months in total. Odd-numbered majors are short-lived proving grounds that reach end of life within about six months. Node.js 26 arrives in April 2026 as the next even-numbered line. This article explains the phases, the dates and how to choose.

Even and odd are not the same

The single most important fact about Node.js releases is that the parity of the major version determines its lifetime.

• Even-numbered majors (22, 24, 26) are released in April, become Active LTS the following October and are supported for roughly thirty months from release.
• Odd-numbered majors (23, 25, 27) are released in October and reach end of life around six months later, when the next even release appears.

Odd releases exist so that risky changes - new V8 versions, deprecations, API changes - can be exercised in public before landing in a line that people will run for years.

The three phases

An even-numbered release spends its first six months as Current, transitions to Active LTS in October, then drops to Maintenance roughly a year later and stays there until its thirty months are up.

Which version to run

In production: the most recent Active LTS. That is the version the ecosystem tests against, the one native module authors publish prebuilt binaries for, and the one with the longest remaining support.

Do not deploy an even release the week it appears. Between April and October it is still Current, meaning semver-minor changes can land. Waiting for the October LTS promotion costs nothing and avoids surprises.

Odd releases belong in CI, not production. Adding the current odd release to your test matrix gives early warning about deprecations without putting anything at risk.

Watch the end-of-life dates. Once a line leaves Maintenance it receives no security fixes at all. Running an end-of-life Node.js is one of the more common findings in a dependency audit.

Pinning the version

Declare the supported range in package.json so that tooling and hosting platforms agree:

{
  "engines": {
    "node": ">=22.0.0 <27.0.0"
  }
}

For local development, a .nvmrc file keeps the team on one version:

24

Container images should pin a specific tag rather than node:lts, which moves underneath you when a new LTS is promoted.

What has been changing

Recent Node.js releases have narrowed the gap between the runtime and what previously required dependencies:

• A built-in test runner with watch mode and coverage reporting.
• Native TypeScript handling for stripping types at runtime, reducing the need for a separate build step in simple cases.
• A permission model for restricting filesystem, network and child-process access.
• ESM and CommonJS interoperability improvements, including the ability to require ES modules under defined conditions.
• Web-standard APIs such as fetch, WebSocket, URLPattern and web streams available as globals.
• Regular V8 upgrades, which bring JavaScript language features along with performance work.

Each major also raises the minimum supported platform versions - compilers, glibc, macOS and Windows releases - which is worth checking before upgrading build infrastructure.

Conclusion

The Node.js schedule is simple once the even/odd rule is clear: even majors in April become LTS in October and live about thirty months, odd majors in October are testing grounds with a six-month life. Node.js 26 in April 2026 becomes Active LTS that October. Run the current Active LTS in production, keep the odd release in CI, and track the end-of-life dates so an upgrade never becomes urgent.