Manu Shukla

Posted on Jul 27 • Originally published at ecorpit.com

One Node.js release a year from 2027: what the Node 27 LTS change means for your upgrade cadence

#node #lts #backend #upgradeplanning

One Node.js release a year from 2027: what the Node 27 LTS change means for your upgrade cadence

Summary. Node.js is ending the twice-a-year major release cadence it has run for a decade. Starting with Node.js 27, the project moves to one major release a year: a single Current release each April, promoted to Long-Term Support (LTS) each October, with every release now becoming LTS and the odd/even split retired. The change takes effect from October 2026, when Node.js 27 opens a six-month alpha channel; Node.js 27 itself ships in April 2027 and reaches LTS in October 2027. Node.js 26, released in April 2026, is the last line under the old model and reaches end of life in April 2029. The stated reason is security sustainability: a mostly volunteer team was maintaining four or five active release lines at once, and the project also paused its cash bug-bounty in 2026 after AI-generated submissions let reporters turn roughly $100 of tokens into $1,000 payouts. For engineering teams the question is not whether to care, but how to reset an upgrade cadence built around the old rhythm.

The announcement, published on the Node.js blog in March 2026 as "Evolving the Node.js Release Schedule," is short, but it rewires assumptions that backend teams have baked into CI, base images and dependency policy since the io.js merger. Matteo Collina, chair of the Node.js Technical Steering Committee (TSC) and maintainer of undici, the library behind fetch, told HeroDevs the non-LTS releases "barely get used," so the work to produce, test and secure them was spent on almost no one. This guide covers what changes, the exact dates for Node.js 22 through 27, why the project made the call, and how to plan upgrades and security patching around annual majors.

What is actually changing

For a decade Node.js has shipped a new major every six months. Even-numbered versions became LTS and were safe for production; odd-numbered versions were short-lived staging grounds that most teams skipped. That model dates to the io.js merger, and as the release working group put it, the original cadence was "an educated guess of what enterprises would need."

From October 2026 the model is simpler. There is one major release a year, it lands in April, it is promoted to LTS in October, and there is no longer an odd or even distinction because every release becomes LTS. A new six-month alpha channel takes over the early-testing role that odd releases used to serve, and version numbers now track the calendar year of the initial Current release, so Node.js 27 arrives in 2027 and Node.js 28 in 2028.

Dimension	Current model (through Node.js 26)	New model (Node.js 27 onward)
Major releases per year	Two (April and October)	One (April)
Odd/even LTS distinction	Yes; only even versions became LTS	Retired; every release becomes LTS
LTS promotion	October for the even release	October, every year
Early-testing channel	Short-lived odd releases	Six-month alpha channel (semver-major allowed)
Version numbering	Sequential	Aligned to calendar year of Current release
Concurrent active lines	Four to five	Fewer, by design
LTS support duration	About 30 months	About 30 months (unchanged)

The headline for most readers is in the last row: the support window per line does not shrink. What changes is how often a new major appears and what you call it.

The new release rhythm, phase by phase

Each Node.js line now moves through four phases. The alpha runs for six months, from October to March, and is the only window where semver-major breaking changes are allowed to land. The Current phase runs the next six months, April to October, for stabilisation. LTS then runs for 30 months with security fixes. After that the line is end of life and receives nothing further. Total supported life is about 36 months from the first Current release to end of life.

The alpha channel deserves attention because it is genuinely new. It is not the same as a nightly build. Alpha releases are signed, tagged and run through CITGM, the project's "canary in the gold mine" test that runs the test suites of major open-source packages against the upcoming Node.js version to catch ecosystem breakage early. Nightly builds remain untested automated builds from the main branch. The alpha is aimed squarely at library authors and CI pipelines, and the project has asked them to wire alpha releases into CI as early as possible. If you only test on LTS, you will not surface a breaking change until it is already affecting your users.

Here is how the first several lines land under the new schedule, taken from the project's published timeline.

Version	Alpha begins	Current (April)	Enters LTS (October)	End of life
Node.js 27	October 2026	April 2027	October 2027	April 2030
Node.js 28	October 2027	April 2028	October 2028	April 2031
Node.js 29	October 2028	April 2029	October 2029	April 2032
Node.js 30	October 2029	April 2030	October 2030	April 2033
Node.js 31	October 2030	April 2031	October 2031	April 2034

The project notes this schedule is not final and points to the machine-readable schedule.json in the Release repository as the authoritative record.

The dates that matter: Node.js 22 to 27

The transition means two schedules run in parallel for a while. Node.js 26 is the last line under the old model; Node.js 27 is the first under the new one. If you are planning migrations for the next 18 months, these are the dates to put on the calendar.

Version	Status as of July 2026	Enters LTS	End of life
Node.js 22	Maintenance LTS	Already LTS	April 30, 2027
Node.js 24	Active LTS (latest LTS, v24.18.0)	Already LTS	April 30, 2028
Node.js 26	Current (latest release, v26.5.0)	October 2026	April 2029
Node.js 27	Not yet released; alpha from October 2026	October 2027	April 2030

Two practical takeaways fall out of this table. First, if you are on Node.js 22, you have until April 30, 2027 before patches stop, which is closer than it looks once you account for testing and change windows. Second, Node.js 24 is the safe production target today and is supported until April 30, 2028; there is no reason to rush onto Node.js 26 in production unless you need something specific from it, and Node.js 27 will not be production-ready until it reaches LTS in October 2027.

Why the project made this change

The blog post gives two reasons, and the HeroDevs interview with two TSC members fills in the rest.

The first reason is volunteer sustainability. Node.js is maintained mostly by volunteers, and the hard part is not writing features, it is security. Every additional active line multiplies backporting work. Marco Ippolito, a TSC member who shipped roughly 70% of the Node.js 20 LTS releases, pointed out that Node.js 22 and Node.js 26 have diverged enough that moving a single commit between them is genuinely difficult. Cutting the number of concurrent lines lets a small team focus on the releases people actually run.

The second reason is adoption data. A decade of usage shows odd-numbered releases saw minimal uptake because most teams wait for LTS, and the odd/even split confused newcomers. As Collina put it, the effort to produce, test and secure the non-LTS releases was spent on almost no one.

Underneath both reasons sits an uncomfortable pattern: most organisations do not upgrade Node.js after they deploy. Node.js 20 reached end of life on April 30, 2026, and in that same month it was still downloaded around 95 million times. Node.js 16, which is years past end of life, is still pulled roughly 20 million times a month. Ippolito's read is that teams fall so far behind in their dependency tree that upgrading stops being incremental and becomes a full refactor, so it gets deferred again. Fewer, more predictable majors are meant to lower that bar.

What this means for your upgrade cadence

If your policy was already "only run even LTS versions," the practical change is small: keep running LTS, and note that the version numbers now jump by one a year instead of two. The planning work is in three places.

Standardise on LTS and write down the target. Under the new model every release is LTS, so "run the current Active LTS" is a clean policy. Today that means Node.js 24 in production, with Node.js 26 becoming a candidate once it is promoted in October 2026. Pin your base container images to a major line, not to latest, so a rebuild never silently jumps a major.

Plan one migration a year, not two. The single-annual-major rhythm maps neatly to an annual dependency and runtime review. Budget a migration window each year to move to the newest Active LTS, and treat it as scheduled engineering rather than an emergency triggered by an end-of-life date. This is the same discipline that keeps teams off the Bun vs Node.js backend runtime decision cliff, where a runtime choice made years ago becomes expensive to unwind.

Decide who tests the alpha. For application teams the answer is usually nobody: alphas are not for production. For teams that publish libraries or maintain shared internal packages, wire the alpha channel into CI so breaking changes surface during the six-month alpha rather than after a Current release ships. If your build already depends on newer language features, the same care applies to changes such as Node.js native TypeScript type stripping, where runtime behaviour and tooling assumptions move together. Both belong in the same annual review that anchors the rest of the web platform and API roadmap.

Security under fewer release lines

The change is, at heart, a security decision, so it is worth looking at what a Node.js security event actually costs the project. On Monday, July 27, 2026, Node.js shipped coordinated security releases across the 26.x, 24.x and 22.x lines, with the highest-severity issue rated High across all three. That is three separate builds for one class of problem, and it is the routine case, not the exception.

The dependency chain is the reason. Node.js bundles its own HTTP parser and undici, the library that powers fetch. Each active LTS line pins a different undici major: Node.js 22 runs undici 6, Node.js 24 runs undici 7, and Node.js 26 runs undici 8. A single security fix in undici can therefore require three separate undici releases, coordinated across multiple releasers inside a tight window, and every one of them has to pass the hours-long CITGM run before it ships. Reduce the number of active lines and you reduce that multiplication directly, which is the point.

The bug-bounty pause sits in the same story. The reporting and triage path is unchanged; reports still come through HackerOne and are triaged by volunteers. What paused is the cash bounty, for two reasons. One is funding: the bounty lost its sponsor, and the OpenJS Foundation is working with vendors to fund a restructured program scoped to high and critical vulnerabilities. The other is a flood of AI-generated, low-quality reports. Collina described the economics plainly: someone can spend about $100 in tokens generating submissions and turn that into a $1,000 bounty, which turns low-effort reporting into a money-making scheme. Not all of it is noise; the share of plausible AI-assisted submissions has climbed to roughly two-thirds, and LLMs are now good at chaining several low-severity issues into a working exploit that would be slow for a human to assemble. But the asymmetry between generating a report and verifying one is what broke the model.

For teams still on end-of-life Node.js, the harder truth from maintainers who patch old versions is that those versions are less secure than most teams assume, because new fixes frequently turn out to apply to end-of-life code too. When a line ends, upstream patches stop; there are no more releases. The security-release cadence itself now runs monthly across the JavaScript ecosystem, a pattern also visible in the Next.js July 2026 security release, so a clear runtime-support policy is no longer optional.

India-specific considerations

For Indian engineering teams and the growing base of global capability centres running Node.js services, the schedule change lands on top of a compliance clock. The Digital Personal Data Protection (DPDP) Act 2023 requires organisations that handle personal data to maintain reasonable security safeguards. Running an end-of-life runtime that no longer receives security patches is difficult to defend as a reasonable safeguard once a fix exists upstream and cannot reach you.

The practical guidance is the same, with a compliance overlay. Keep production on a supported Active LTS line, budget the annual migration as a named engineering task, and record the runtime-support policy alongside your other data-protection controls so an auditor can see it. Teams that want the full engineering picture can start from the DPDP Act engineering playbook for Indian startups and fold the Node.js upgrade cadence into that programme rather than treating it as a separate task.

FAQ

When does the new Node.js release schedule start?

The new model takes effect from October 2026, when Node.js 27 opens its six-month alpha channel. Node.js 27 ships as a Current release in April 2027 and is promoted to Long-Term Support in October 2027. Node.js 26, from April 2026, is the final line under the old twice-a-year model.

Does every Node.js version become LTS now?

Yes. Under the new schedule every major release becomes Long-Term Support, and the odd/even distinction is retired. Node.js 27, an odd number that would previously have been skipped by most teams, will carry LTS status. Each line keeps a support window of about 30 months, the same as today.

When does Node.js 22 reach end of life?

Node.js 22 is in maintenance LTS and reaches end of life on April 30, 2027. Node.js 24, the active LTS line, reaches end of life on April 30, 2028. Node.js 26 enters LTS in October 2026 and reaches end of life in April 2029. Plan migrations against these dates.

Why is Node.js reducing its release lines?

The project cited volunteer sustainability. A mostly volunteer team was maintaining four or five active lines at once, and security backports across them had become hard to coordinate. Adoption data showed odd-numbered releases saw minimal use, so the effort to produce, test and secure them reached almost no one.

What is the new Node.js alpha channel for?

The alpha channel runs for six months, from October to March, and allows semver-major changes for early testing. It replaces the role odd releases once played, but is aimed at library authors and CI pipelines, not production. Alpha builds are signed and tested through CITGM, unlike untested nightly builds.

Should we upgrade only to LTS Node.js versions?

For most production teams, yes. Under the new model every release is LTS, so standardising on LTS covers all supported majors. The exception is library authors, who should test against the alpha channel early so they can report breakage before it reaches users who depend on their packages.

Does the schedule change affect Node.js security patches?

The security process itself is unchanged: reports still go through HackerOne and volunteers triage them. Fewer active lines should make coordinated security releases easier, because a single fix, such as one in undici, no longer has to ship across four or five diverging majors at once.

Is running an end-of-life Node.js version risky?

Yes. Once an LTS line ends, upstream patches stop, and maintainers report that old versions are less secure than teams assume because new fixes often apply to them too. Node.js 20 still saw about 95 million downloads in the month it reached end of life, in April 2026.

How eCorpIT can help

eCorpIT runs Node.js backends in production for clients across fintech, healthcare and commerce, and we plan runtime upgrades as scheduled engineering rather than an emergency. Our senior engineering teams audit an application's dependency tree, map each service to a supported LTS line, and stage migrations off end-of-life versions before the cutoff date. For teams bound by the DPDP Act 2023, we design upgrade and patching workflows aligned with its security-safeguard expectations, backed by our ISO 27001:2022 and CMMI Level 5 practices. If your services still run on Node.js 20 or older, talk to our engineering team about a runtime upgrade plan.