Node.js 26 LTS: Release Date and the New Yearly Model

Node.js 26 is set to enter Long-Term Support (LTS) on October 28, 2026, according to the official release schedule maintained by the Node.js project on GitHub. That promotion arrives alongside a bigger change: starting with the next major version, Node.js 27, the project is retiring its decade-old twice-a-year, odd/even release model in favor of a single major release every year. From here on, every major version will eventually become an LTS release, there will be one Current release each April, and LTS promotion will happen every October.

If you only ever upgrade to LTS versions, the practical impact is small: support windows stay roughly the same length, and you still get a predictable fall upgrade target. But the version-numbering logic, the alpha-testing process, and the rhythm library authors and platform teams plan around are all changing. Here is what's confirmed from Node.js's own sources, what's new in Node 26 itself, and what the new cadence means for anyone who upgrades Node.js for a living.

When does Node.js 26 enter LTS?

Node.js 26.0.0 was released as the "Current" line on May 5, 2026, authored by Node.js release lead Rafael Gonzaga. Per the schedule.json file in the official nodejs/Release repository on GitHub, Node.js 26's lifecycle is:

As of today, that LTS promotion hasn't happened yet — Node.js 26 is still in its Current phase and is scheduled to move to LTS later this month. Node's own release announcement for 26.0.0 confirms the same framing: "Node.js 26 will enter long-term support (LTS) in October, but until then, it will be the 'Current' release." Once it flips to LTS on October 28, Node 26 becomes the version most production teams should standardize on, since Current releases are not intended for production use.

What's new in Node.js 26

The official Node.js 26.0.0 release notes list three headline changes, all verified directly against that post:

• Temporal API enabled by default. Temporal, the modern date/time API meant to replace the long-criticized legacy Date object, now ships enabled out of the box in Node 26 (landed via node#61806, authored by Richard Lau). Previously it required an experimental flag.
• V8 updated to 14.6.202.33, aligning Node's JavaScript engine with Chromium 146. This brings newer engine-level features, including Map/WeakMap upsert helpers like getOrInsert() and iterator-sequencing additions such as Iterator.concat().
• Undici updated to 8.0.2. Undici is the HTTP client that backs Node's built-in fetch and related APIs, so this is a direct upgrade to Node's native networking stack.

The release also removes or deprecates several long-flagged APIs: http.Server.prototype.writeHeader() is removed (use writeHead()), the legacy internal _stream_* modules are fully removed, module.register() is now runtime-deprecated, and the experimental --experimental-transform-types flag has been removed. On the build side, Node 26 now requires GCC 13.2 and drops Python 3.9 as a supported build dependency. Because several of these are semver-major changes, teams running custom native addons or relying on the removed stream internals should test against Node 26 before switching their LTS default once it promotes in October.

Why Temporal, by default, is the headline change

Of everything in the 26.0.0 release notes, enabling Temporal by default is the change most likely to show up in everyday application code. Temporal is a TC39-championed JavaScript proposal designed to replace the native Date object, which has been criticized for decades for inconsistent parsing, mutable instances, and awkward time-zone handling. Temporal introduces a set of immutable, explicit types — for plain dates, times, date-times with time zones, durations, and instants — so developers no longer have to reach for third-party date libraries just to do time-zone math or duration arithmetic correctly.

Node.js had exposed Temporal behind an experimental flag in earlier versions; Node 26 is the first line where it's on without any flag at all, which is itself a semver-major change, since any application or dependency that happened to define its own global named Temporal could now collide with the built-in. The official release notes flag this directly as a semver-major commit (node#61806), so it's worth a quick grep across a codebase and its dependency tree before upgrading a production service to Node 26, specifically for any code shadowing a global called Temporal.

The bigger story: one major release a year

Node.js has published a separate announcement, "Evolving the Node.js Release Schedule," explaining that the current twice-a-year cadence is roughly ten years old, dating back to the period when Node.js and io.js merged. The project's own stated reasons for changing it:

• Odd-numbered releases "see minimal adoption" because most users wait for LTS.
• The odd/even split "confuses newcomers."
• Many organizations skip odd releases entirely and upgrade only on LTS versions.
• Maintaining four or five concurrent release lines strained the project's volunteer release team.

Starting with Node.js 27, in effect as of October 2026, the new structure is:

• One major release per year, shipping every April, with LTS promotion every October.
• Every release becomes LTS — the odd/even distinction disappears entirely; Node.js 27 itself will become an LTS line.
• A new six-month Alpha channel fills the early-testing role odd releases used to serve, but semver-major changes are explicitly allowed during Alpha, and alpha builds are signed, tagged, and tested through CITGM (Canary in the Goldmine).
• Alpha versioning follows semver prerelease format, e.g. 27.0.0-alpha.1.
• Version numbers now track the calendar year of each line's first Current release: 27.0.0 ships in 2027, 28.0.0 in 2028, and so on.

According to Node's announcement, total support remains 36 months from a line's first Current release to end of life, and LTS itself still runs 30 months — the project says it isn't shortening support, just removing the odd-numbered lines that most teams never touch anyway. Migration windows, where two LTS versions overlap so teams have time to move, are also preserved.

How the new Alpha channel actually works

The Alpha channel is the piece of the new model with no real precedent in Node's recent history, so it's worth walking through what Node's own announcement says about it. Alpha releases are built, signed, and tagged the same way stable releases are, and they're run through CITGM (Canary in the Goldmine), the project's compatibility-testing tool that runs a large sample of real-world npm packages against a candidate build to catch ecosystem breakage before it ships. That's a meaningfully higher bar than an unofficial nightly build from the main branch.

Two details matter for anyone deciding whether to adopt Alpha builds in their own pipeline. First, semver-major changes — the kind that used to only land in a brand-new odd-numbered major — are explicitly allowed to land during the Alpha window, meaning breaking changes can still appear release-to-release within Alpha itself. Second, Alpha builds are not guaranteed to contain every commit from main; a releaser can choose to hold a change back from a given Alpha build, for instance when a runtime deprecation is staged separately from the removal that eventually follows it. Node's guidance is blunt about who this is for: library authors and CI maintainers should integrate Alpha into their test matrix as early as possible, because teams that test only against LTS releases will find out about breaking changes too late to report them before the next Current release ships.

Why Node.js made this change

Node's post attributes the proposal to Node.js Technical Steering Committee member Rafael Gonzaga, who raised the idea of reworking the schedule to reduce the number of concurrent release lines the mostly volunteer release team has to support simultaneously. With fewer lines to backport security and bug fixes to, the project argues it can focus more effort on making each release — now, by definition, an eventual LTS release — more stable before it reaches general production use.

What this means if you're upgrading Node.js

For most teams, the near-term advice doesn't change much: continue tracking LTS releases, and treat Node.js 26 as the version to standardize new projects on once its LTS window opens on October 28, 2026. A few practical notes follow from the schedule change:

• Library authors and CI maintainers should start testing against Node.js 27 Alpha builds as early as possible once they appear, since Alpha is explicitly where semver-major breakage will show up first — testing only against LTS releases means bugs get reported too late to fix before general availability.
• Enterprise and platform teams get a more predictable planning calendar: one upgrade decision per year, every April/October cycle, instead of tracking which of two concurrent lines is which.
• Anyone still depending on the old odd/even mental model (skip odd versions, adopt even ones) should retire that heuristic going forward — Node.js 27 is itself destined to become an LTS line, not a short-lived experimental one.
• If you're running containers or CI images pinned to Node major versions, expect the next bump after Node 26 to be Node 27 directly, with no Node 28 "odd-skip" release in between to confuse version pins.
• Version-manager and Docker-tag habits should be rechecked once Node 26 promotes. Base images and version managers like nvm typically add an "lts" alias the moment a line is promoted, so pulling the latest LTS tag on or after October 28, 2026 should resolve to Node 26 rather than Node 24 — worth confirming in your own CI logs rather than assuming, since the exact rollout timing of tags can lag the official promotion by a short window.
• Packages with an engines field in package.json that currently cap support at an even-numbered LTS line will need that range extended to cover Node 26, and eventually Node 27, once those lines are the active LTS target.

Teams that manage Node.js versions across many services sometimes track this the same way they track other platform runtime changes — the way, for example, engineering orgs had to plan around Windows 10's extended security update timeline or around tooling updates like Python's own version-management changes. The common thread is the same: knowing the exact support dates, from a primary source, is what actually matters for upgrade planning — not general version-number folklore.

Node.js 26 vs. the current LTS, Node.js 24

Node.js 24 has been the LTS line most production systems should be running since late 2025, and per the same nodejs/Release schedule it moves into its own Maintenance phase on October 20, 2026 — about a week before Node 26 takes over as the new Active LTS line on October 28. Node.js 26 itself is the Current release in the meantime, intended for early adopters and anyone preparing to migrate rather than for production. Developers building or testing tooling — including AI-assisted coding setups that increasingly rely on protocols like MCP for connecting editors to external tools and runtimes — will want their local Node.js version to match whichever line their CI pipeline targets, since semver-major removals like the deleted legacy stream modules can break tooling that hasn't been updated.

Where this leaves odd-numbered releases

Node.js 25, released under the old model, is the last short-lived odd-numbered Current release; it was never going to be promoted to LTS and reaches end of life on its existing schedule. Node.js 26 is effectively the last release produced under the old twice-a-year framework, even though its own LTS window runs on the same 30-month timeline LTS releases have used for years. Node.js 27 is the first release built entirely under the new one-a-year rules, starting with its Alpha phase in October 2026.

What's next

The immediate date to watch is October 28, 2026, when Node.js 26 is scheduled to formally enter LTS per the nodejs/Release schedule. After that, the next milestone under the new model is the Node.js 27 Alpha channel opening the same month, followed by Node.js 27.0.0 as a Current release in April 2027 and its own LTS promotion in October 2027. Developers who want the authoritative, continuously updated version of these dates should check the nodejs/Release schedule.json file directly, since it is the single source Node.js's own tooling and release team use to track every line's status.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage