Node.js Release Schedule: Dates, LTS and the Yearly Change

Node.js is the server-side JavaScript runtime built on Google's V8 engine, and it has moved to one major release per year. The change starts with Node.js 27. The project set out the shift in its release schedule announcement. From version 27 on, one major release lands each April, the odd/even split disappears, and every release line becomes eligible for long-term support.

For most teams the practical answer is short. If you already run only LTS releases, you change almost nothing. If you track the Current line or maintain a CI version matrix, your planning cadence halves. A new Alpha channel also becomes the place to test early.

Dates below were re-checked against the Node.js release table and endoflife.date on October 11, 2026.

Node.js release dates at a glance

Version	First released	Enters LTS	End of life	Status on Oct 11, 2026
Node.js 20	Apr 18, 2023	Oct 24, 2023	Apr 30, 2026	End of life for 164 days
Node.js 22	Apr 24, 2024	Oct 29, 2024	Apr 30, 2027	Maintenance LTS
Node.js 24	May 6, 2025	Oct 28, 2025	Apr 30, 2028	Active LTS, Maintenance from Oct 20, 2026
Node.js 26	May 5, 2026	Oct 28, 2026	Apr 30, 2029	Current, LTS in 17 days
Node.js 27	Apr 2027 (Alpha Oct 2026)	Oct 2027	Apr 2030	Projected, not yet released

The Node.js 27 row is a projection from the announced schedule. Every other date comes from the release table and endoflife.date. Node.js 26 is the current release, and the Node.js 20 line is already past its end of life.

!Node.js support windows for versions 20 to 27, showing Current, LTS and Maintenance phases

What is Node.js changing about its release schedule?

Node.js is cutting its major release count from two per year to one, starting with Node.js 27. Under the old model, Node.js shipped a major version in April and another in October. Even-numbered releases were promoted to long-term support, and odd-numbered releases never were. That split is being removed. Under the new model, Node.js publishes one major release every April, and each one is eligible for long-term support, per the Node.js announcement.

Long-term support (LTS) is a phase where a Node.js release gets bug fixes and security patches but no new features. The LTS window stays at 30 months. InfoQ's report on the change framed the move as a response to how teams actually adopt Node.js, since odd releases saw little production use.

Version numbers also change meaning. Each release number now matches the calendar year it becomes Current. For example, 27.0.0 arrives in 2027 and 28.0.0 in 2028, per the Node.js announcement.

When does Node.js 27 actually arrive?

Node.js 27 becomes a stable release in April 2027, and its Alpha channel opens in October 2026. The Node.js Alpha channel is a six-month early-testing phase where Node.js can still make breaking changes. Alpha builds are published under semver prerelease tags such as 27.0.0-alpha.1, per the Node.js announcement.

After Alpha, Node.js 27 spends six months as the Current release, from April 2027 to October 2027. Node.js 27 then enters long-term support in October 2027 and reaches end of life in April 2030. Socket's write-up lays out the same phase structure and start date.

Node.js 26 is the last release under the old rules. Node.js 26 shipped on May 5, 2026 and enters long-term support on October 28, 2026, per the Node.js release table. Our coverage in "Node.js 26 turns Temporal on. Upgrade now or wait?" walks through what that release added.

Old schedule versus new schedule

The table below maps a single release through the old rules and the new rules. Node.js 26 follows the old path. Node.js 27 follows the new path.

Milestone	Node.js 26 (old model)	Node.js 27 (new model)
Alpha channel opens	None	October 2026
Stable release	May 2026	April 2027
Enters LTS	October 2026	October 2027
LTS type	Even release, LTS-eligible	Every release LTS-eligible
End of life	April 2029	April 2030
Total supported life	About 36 months	About 36 months

Source: the Node.js release schedule announcement.

The total supported life is close to unchanged. What moves is the entry point. A team that wants to test the next major early no longer waits for a Current release in April. That testing now starts in the Alpha channel the previous October.

Version-to-support-window reference

The table below gives the projected support window for the first Node.js releases under the new model. Dates for Node.js 28 and later follow the same April-to-April pattern. They are projections from the announced schedule, not separately confirmed release dates.

Node.js version	Alpha opens	Stable release	Enters LTS	End of life
26	None	May 2026	October 2026	April 2029
27	October 2026	April 2027	October 2027	April 2030
28	October 2027	April 2028	October 2028	April 2031
29	October 2028	April 2029	October 2029	April 2032

HeroDevs' maintainer interviews explain why the project chose a single yearly line over the two-track system.

Why is Node.js making this change?

Node.js is consolidating its release lines because maintaining four or five at once is too much work for a mostly volunteer team. The project said security releases are the hardest part of that work, since every active line needs its own backport.

Adoption data drove the rest of the decision. Odd-numbered releases were never promoted to LTS, so most production users skipped them and waited for the even-numbered line, as InfoQ noted. Cutting the release that few people ran removes real maintenance cost. It does not remove a version anyone depended on. Enterprises also asked for a fixed, predictable schedule they could plan platform upgrades around.

What should your team do now?

Your next step depends on how you consume Node.js today. Three cases cover most teams.

If you run only LTS releases, take no action. Keep upgrading LTS to LTS on the same 30-month support window. The one habit to drop is the odd/even mental model, because it no longer describes anything. Tell your team that every yearly Node.js version is now an LTS candidate.

If you track the Current line for early access to features, your cadence changes from twice a year to once a year. Move your early-testing work to the Alpha channel that opens each October. Pin the specific alpha tag in a dedicated CI job, such as 27.0.0-alpha.1, and treat breakage there as expected rather than urgent.

If you maintain a CI version matrix, plan for one new major entry per year instead of two. In practice, keep the active LTS line plus the current Alpha or Current line. Retire the older entry when its LTS window closes. This mirrors the upgrade-window discipline covered in ".NET 8 and .NET 9 End of Life: Both End Support Nov 10, 2026" and in "Python 3.10 End of Life Has Passed. 3.14 Is Four Hops Away", where a missed support date forces a rushed migration.

The V8 engine cadence does not change. Node.js still adopts a V8 version that is roughly six months old, per the Node.js v26 release notes. Migration windows between LTS versions also stay in place, so a team upgrading LTS to LTS keeps the same overlap it has today.