Two things are happening to Node.js at once this October, and they are easy to conflate.
The first is routine: Node.js 26, released 5 May 2026, is promoted to Long Term Support in October 2026. That is the normal cadence and it is the version most teams will standardise on for the next two and a half years.
The second is not routine: the Node.js project is moving to one major release per year, starting with Node.js 27. The odd/even mental model that every Node shop has used since 2015 — even-numbered versions get LTS, odd-numbered versions are throwaway — stops being true. If your upgrade policy is written down anywhere, it is now wrong.
What the new schedule actually is
Under the new model, each major release follows this path:
| Phase | Duration | Example (Node.js 27) |
|---|---|---|
| Alpha | 6 months | October 2026 → March 2027 |
| Current | 6 months | April 2027 → October 2027 |
| LTS | 30 months | October 2027 → April 2030 |
That is 36 months from first Current release to end of life. Majors land in April, are promoted to LTS in October, and the version number matches the calendar year of the initial Current release — 27 in 2027, 28 in 2028.
Three consequences follow:
- Every release becomes LTS. There is no longer such a thing as an odd-numbered release you skip on principle.
- There is a new Alpha channel, six months long, where
semver-majorchanges are allowed to land. This is the new place to find out what breaks. - Support duration does not change. LTS is still 30 months, and the overlap between LTS lines that gives you a migration window is preserved.
The project's stated reason is reducing volunteer maintenance burden — fewer concurrent release lines to patch and backport into. Quality gates, security process, CITGM and the V8 adoption cycle are unchanged.
If your policy is "only ever run LTS," almost nothing changes for you except the numbering. If you maintain a library, the Alpha channel is the change you should act on: put an alpha lane in CI, because that is now where breakage becomes visible six months before it reaches your users.
What is in Node.js 26
Node 26 is a real major, not a version bump. The things most likely to affect you:
Temporal is enabled by default. The replacement for Date is no longer behind a flag. This does not break existing Date code, but it does mean you can stop pulling in a date library for the common cases, and new code written against Temporal will run on the LTS line. This is the single best reason to move.
V8 14.6.202.33 (Chromium 146), which brings Map.prototype.getOrInsert() and getOrInsertComputed() (plus the WeakMap equivalents) and Iterator.concat(). The upsert methods quietly delete a lot of if (!map.has(k)) map.set(k, ...) boilerplate.
Undici 8.0.2, the HTTP client that backs fetch.
Removals and deprecations that will bite:
http.Server.prototype.writeHeader()is removed — usewriteHead().- The legacy
_stream_*modules are removed. Anything reaching into_stream_readableand friends — usually an old transitive dependency, not your code — stops working. --experimental-transform-typesis removed. If you were running TypeScript directly through Node with type stripping plus transform, check which flag you actually depend on before upgrading.module.register()picks up a runtime deprecation warning.localStoragereturnsundefinedwhen no file is configured.- Readable streams now read one buffer at a time, which is a behavioural change in code that assumed otherwise.
Build and native modules: NODE_MODULE_VERSION moves to 147, so every native addon must be rebuilt — this is the classic cause of a "works on my machine, explodes in the container" upgrade. GCC requirement rises to 13.2, Python 3.9 is dropped as a build dependency, and the Windows SDK moves to 11.
What this changes
For an application team on Node 24 LTS: plan the move to 26 now, while 26 is still Current, and do it before October if you can. The two things that actually consume time are rebuilding native dependencies against NODE_MODULE_VERSION 147 and finding the transitive dependency that still imports _stream_readable. Both are discoverable in an afternoon with a clean node_modules and a full test run — neither is discoverable from a changelog.
For a library maintainer: the Alpha channel starting this October is the material change. Add it to CI now. The whole point of a six-month alpha window is that breakage gets reported by maintainers rather than by users on release day, and that only works if maintainers actually test there.
For everyone: delete the sentence in your engineering handbook that says "we skip odd-numbered Node versions." It stops being true with Node 27, and a team upgrading on a rule that no longer holds will skip an LTS release by accident.
One honest caveat — announced schedules are plans. This one is a project-governance decision with a clear rationale behind it, and the first real test is whether Node 27 actually ships in April 2027. Nothing about your Node 26 upgrade depends on that, so do the 26 work on its own merits.