Node.js Is Slowing Down on Purpose. The Reason Is a Maintainer Crisis.

Node.js is changing its release schedule, and on paper it's all upside: one major release a year instead of two, and every release becomes LTS. The announcement frames it as a gift to developers. Read the working group's reasoning and it's something else — a project with 91 active collaborators admitting it can't keep up. Here's what's changing, why it's happening, and what to do about it.

What actually changes

For a decade, Node.js shipped two majors a year: the even-numbered one got 30 months of long-term support, while the odd "Current" line lived about six months and was never meant for production. Starting with Node 27, there's one major a year, and every release eventually becomes LTS. The concrete calendar, from the release repository's own schedule.json:

Node 26 (shipped May 5, 2026) enters LTS on October 28, 2026, moves to maintenance on October 20, 2027, and reaches end of life on April 30, 2029.
Node 27 opens its six-month Alpha on October 28, 2026 — the same day 26 goes LTS — ships as 27.0.0 on April 22, 2027, and becomes LTS in October 2027.
Node 24, the current LTS, moves to maintenance on October 20, 2026 and is supported until April 30, 2028.
Node 22 leaves maintenance in April 2027. If you're still on it, that's your deadline.

The lifecycle is simple from here on: a six-month Alpha (October to March) for breaking changes, a six-month Current (April to October) for stabilization, then LTS. The support window doesn't get longer — the big visible change is that odd/even version roulette is gone. Node 25 will be the last odd release. Ever.

The real reason: branches, not features

The release working group was candid about the motive. The schedule dates back to the 2015 io.js merger — "an educated guess of what enterprises would need," in their words — and their usage data shows almost nobody ran the odd releases in production. But someone still had to keep each branch alive: every security fix got backported into the odd line for its six months of existence, stacking on the overlapping LTS lines into four or five live release lines at once, each needing the same backporting discipline. The annual schedule cuts that to at most three.

The proposal — credited to TSC member Rafael Gonzaga and debated publicly in the release repository — also floated shortening the LTS window to 24 months. That part didn't survive. What survived was the simplest cut: kill the branch almost nobody used but everyone paid to maintain. The working group's own summary for most developers: "If you already only upgrade to LTS versions, little changes beyond version numbering."

And the branch count isn't the whole story — AI is piling on. This year's collaborator survey put numbers on the strain: Node.js runs on 91 active collaborators, and the recurring complaint isn't technical. Reviewing low-quality AI-generated pull requests eats a significant chunk of contributor time, while the security team faces a sharp rise in AI-generated vulnerability reports — many not directly exploitable, all still requiring manual triage. The project's answer has been a human-accountability line (machine-generated contributions without a human owner are discouraged) and an OpenJS Security Stewardship Program exploring a 50/50 funding split between researcher bounties and maintainer work — an admission that the people doing the boring maintenance are the scarce resource.

Contrast that with what browser vendors just did — Chrome, Edge and Firefox sped up to a two-week release cycle. Node is slowing its major cadence down, because it's solving the opposite problem: not shipping features faster, but surviving the branches it already has. Newer runtimes like Deno and Bun, backed by venture money and young enough to have no decade of release lines, don't face this math yet. Node's schedule change is what it looks like when a project gets old enough that its biggest cost isn't innovation — it's the accumulated weight of keeping everything it ever shipped secure.

The catch nobody's talking about

Not everyone bought the deal. Engineer Kevin Lentin warned during the public discussion that the annual cadence creates a trap: skip even one yearly release and you face a two-year gap between majors — roughly twice the old wait. Teams that used the six-month Current line as a low-stakes preview lose it: under the new model, you wait a full year between any new major release at all.

And the headline framing deserves one honest correction. "Every release is LTS now" is good PR, but the number of concurrently supported LTS lines is still governed by the same math — a fixed support window and one promotion a year. What you gain is real but modest: the removal of a branch that almost nobody ran in production and that consumed volunteer hours for six months every year. Node.js contributor James Snell acknowledged the old model "was based entirely on corporate adoption cycles that were relevant at that time." Fair — but if you were one of the fast-moving teams that actually used the preview window, your experience gets slightly worse so the release team's doesn't keep getting worse. That's the trade, stated plainly.

Node 26 upgrade checklist: what breaks

The migration is calm: the breaking list is short, almost everything on it deprecated for years. The ones with real shrapnel:

The internal _stream_* modules are gone. Deprecated since Node 12, now removed — any require('_stream_readable') throws MODULE_NOT_FOUND. This breaks old dependencies, not your code: grep -rn "_stream_" node_modules --include="*.js" -l | head tells you in seconds whether you're affected.
Undici 8 makes global fetch strict. Headers built from dynamic values — a token copied with a trailing newline, strings from a database — now throw a TypeError instead of being silently sanitized. Sanitize at the edge where the value enters your system.
Native addons need a rebuild. NODE_MODULE_VERSION moves to 147, so bcrypt, sharp, better-sqlite3 and friends must be recompiled. Build requirements went up too: GCC 13.2 minimum, and Python 3.9 was dropped from the toolchain. If you compile addons inside an old Debian/Alpine image, update the image first.
module.register() is runtime-deprecated. The async hooks API used by instrumentation loaders, APM agents and tools like tsx now warns; the replacement is the synchronous module.registerHooks(). You update your dependencies to versions that already migrated instead of rewriting anything.
writeHeader() is removed. The undocumented alias of writeHead(). grep -rn "writeHeader" src/ finds it if your codebase is old enough.

Despite the rumors, the things that don't break: the Temporal API coexists with Date, TypeScript runs natively (node app.ts, no flags), and V8 14.6 only adds.

What to do this week

The order that produces the fewest surprises: install 26 next to your current version (fnm or Volta make rollback instant), npm rebuild against the new ABI, run your suite with node --pending-deprecation --trace-deprecation, grep for the fossils, and update your APM/telemetry agents to versions declaring Node 26 support.

New project: start on 26 today. No reason to begin something long-lived on 24.
Production on 24: the window opens October 28, when 26 enters LTS. With 24 supported until April 2028, there's no rush — but the longer you wait, the further this checklist drifts from fresh memory.
Production on 22 or 25: move now. April 2027 looks far away until it isn't, the 22 → 26 jump is the bigger one, and 25 was the last odd release that will ever exist.
Library and platform teams: your testing calendar just moved from six months to twelve, with a six-month Alpha to test breaking changes. If your org's upgrade policy references "even-numbered" Node versions by rule, that rule no longer maps onto anything after Node 27 — update it before it confuses someone.