Which Node.js version to use in October 2026: LTS lines and the new schedule

Choosing a Node.js version used to be simple: take the newest even-numbered release once it reached Long Term Support. In October 2026 that rule still mostly holds, but this month is unusually busy. Node.js 26 becomes LTS on 28 October, Node.js 24 drops to maintenance on 20 October, and the project begins a new yearly release model, with Node.js 27 starting as an alpha.

If you run Node.js on servers, in CI or inside Docker images, these dates decide when you get security fixes and how long you can postpone the next upgrade. This guide sets out every supported release line as of 7 October 2026, explains the new schedule, and suggests which version fits which kind of project. All dates come from the Node.js Release Working Group schedule and the nodejs.org releases page, checked today.

The short answer: run Node.js 24 (Krypton) in production today, and plan to move to Node.js 26 during its LTS period. Upgrade anything still on Node.js 20 now, because that line reached end of life on 30 April 2026.

Supported Node.js release lines in October 2026

The Release Working Group publishes the schedule as a table in its repository and as a JSON file. Here is the state of each line on 7 October 2026, with the newest version published so far:

The schedule page notes that dates are subject to change, so check the official sources linked at the end before you commit to a long migration plan.

What the phases mean

• Current: receives most non-breaking changes that land on the main branch. Good for trying new features, but expect frequent minor releases (26.x went from 26.0.0 in May to 26.11.0 in October).
• Active LTS: new features, bug fixes and updates that the Release team has audited and judged stable for the line.
• Maintenance: critical bug fixes and security updates. New features arrive only occasionally, usually to help users migrate to a later line.
• End of life: no more releases, including security fixes. Anything still running an EOL line is on borrowed time.

Which version should you run?

The right answer depends on what you are deploying and how often your team upgrades. A practical mapping:

For most small teams the safest pattern is: stay on the Active LTS line, apply every patch release within a week or two, and schedule the move to the next LTS line during its first months of Active LTS rather than waiting for the old line's end of life.

What changes from Node.js 27: one major release a year

On 10 March 2026 the Node.js Release Working Group announced that, starting with 27.x, Node.js moves from two major releases per year to one. The old odd/even pattern, where odd-numbered versions never became LTS, ends with Node.js 26.

The new model has four phases:

The announcement gives 36 months of total support from the first Current release to end of life. Every release becomes LTS, and version numbers follow the calendar year of their first Current release: 27.0.0 in 2027, 28.0.0 in 2028. Alpha builds use semver prerelease versions such as 27.0.0-alpha.1; they are signed and tagged, but the project says they are not intended for production use.

For Node.js 27 the planned dates are: alpha begins in October 2026, 27.0.0 in April 2027, LTS in October 2027 and end of life in April 2030. The schedule JSON lists the alpha start as 28 October 2026 and the 27.0.0 release as 22 April 2027.

If you already upgrade only to LTS versions, the announcement's own summary applies: little changes beyond version numbering. The release team's stated reasons are that odd-numbered releases saw little adoption and that maintaining security fixes across four or five active lines had become hard to sustain for a mostly volunteer project.

Library authors are asked to add alpha releases to CI as early as possible, so that breaking changes are reported before they reach users.

What to check before moving to Node.js 26

Node.js 26.0.0 was released on 5 May 2026. Its release notes list the headline changes and several removals worth checking in your code base:

• Temporal enabled by default. The modern date and time API is available without a flag.
• V8 14.6, part of Chromium 146, which adds Map.prototype.getOrInsert(), getOrInsertComputed() and Iterator.concat().
• Undici 8, the library behind the built-in fetch().
• Removed: http.Server.prototype.writeHeader() (use writeHead()) and the legacy internal stream modules such as _stream_readable and _stream_writable. Some old packages still import these directly.
• Removed: the --experimental-transform-types flag. Type stripping of erasable TypeScript syntax still works, but enums and other syntax that needs code generation must be compiled by a separate tool.
• Runtime-deprecated: module.register(), used by some custom loaders.

Native add-ons must be rebuilt, because the release bumps NODE_MODULE_VERSION to 147. If you build Node.js from source, the release also raises the GCC requirement to 13.2 and drops Python 3.9 support.

A low-risk upgrade checklist

1. Find every place the version is pinned. Look in .nvmrc or .node-version, Dockerfile FROM lines, CI configuration, serverless runtime settings, and the engines field in package.json.
2. Read the changelog for each major version you skip. Going from 22 to 26 means reading the notable changes for 23, 24, 25 and 26, not just 26.
3. Run your tests on both versions in CI for at least one release cycle, so regressions show up as a failing job rather than a production incident.
4. Watch deprecation warnings. Start the application with --trace-deprecation in staging to see where deprecated APIs are called from.
5. Rebuild native dependencies and recreate lockfiles only if necessary; a clean npm ci on the new version will surface install-time problems.
6. Roll out gradually: one service or one instance group first, with an easy way back to the previous image.

Pin the major version, not an exact patch release, in places where you want security fixes to flow in automatically (for example a CI matrix entry of 24), and pin the exact version where you need reproducible builds (for example a production image that is rebuilt and promoted through environments). Whichever you choose, write down the policy so that everyone on the team updates the same files.

A quick way to see what a server is actually running:

node -p "process.version"        # e.g. v24.21.0
node -p "process.release.lts"    # 'Krypton' on 24.x; undefined on a Current release

The process.release.lts property only exists on LTS releases and is undefined on Current releases, which makes it a handy assertion in a deployment health check.

// fail fast if a container was built from the wrong base image
const [major] = process.versions.node.split('.').map(Number);
if (major < 24) {
  console.error(`Node.js ${process.version} is not supported; use 24.x or newer`);
  process.exit(1);
}

Summary

• Production default today: Node.js 24 (Krypton), supported until 30 April 2028.
• Node.js 26 becomes LTS on 28 October 2026 and is supported until 30 April 2029; plan your move during its Active LTS period.
• Node.js 22 is in maintenance until 30 April 2027. Node.js 20 and 25 are end of life.
• From Node.js 27 there is one major release per year, every release becomes LTS, and alpha builds start each October.

Next step: open your Dockerfiles and CI files today, list every pinned version, and replace any 20.x reference first.