Node.js 26 becomes Active LTS on 28 October 2026. Node 24 moves to Maintenance eight days earlier, on 20 October. So do you upgrade now? Short answer: there is no rush, but start testing this month, because a few things were removed and one of them might be in your code.
The dates that matter
These come from the Node.js project's own release schedule data:
Node 24: released 6 May 2025, LTS from 28 October 2025, Maintenance from 20 October 2026, end of life on 30 April 2028.
Node 26: released 5 May 2026, LTS from 28 October 2026, Maintenance from 20 October 2027, end of life on 30 April 2029.
Node 25: reached end of life on 1 June 2026.
If anything of yours still runs on 25, move it now. It no longer gets updates. If you are on 24, you have until April 2028, so the question is timing, not urgency.
What Node 26 adds
According to the 26.0.0 release notes, the notable changes are:
The Temporal API is on by default, as a modern replacement for the old
Dateobject.V8 moves to version 14.6, which brings
Map.prototype.getOrInsert()andgetOrInsertComputed(), plusIterator.concat().Undici, the HTTP client behind
fetch, is updated to 8.0.2.
A taste of Temporal. This adds 30 days to a date without the month-overflow surprises of Date:
const due = Temporal.PlainDate.from('2026-10-28').add({ days: 30 });
console.log(due.toString()); // 2026-11-27
And the Map additions replace the check-then-set routine:
const scores = new Map();
const score = scores.getOrInsertComputed(userId, (id) => computeScore(id));
I ran the Temporal example against a Temporal polyfill on Node 22, not on Node 26 itself, so test it on your own target version.
For most applications these additions are conveniences, not reasons to hurry. Iterator.concat() lets you chain iterators lazily without building an intermediate array, and Temporal is the one that will change how new code handles dates. None of them forces a migration on a service that works.
What was removed
The same release notes list these removals and deprecations. A May 2026 write-up from Node.js Design Patterns says most apps will not feel them, and suggests grepping for the ones below.
http.Server.prototype.writeHeader()is gone. UsewriteHead().The undocumented legacy stream modules (
_stream_readable,_stream_writableand relatives) are gone. Usenode:stream.The
--experimental-transform-typesflag is removed.module.register()is now runtime-deprecated.The native add-on version number changed to 147, so compiled add-ons need a rebuild.
A single command finds most of the code-level hits:
grep -rnE "_stream_|writeHeader\(|module\.register\(|experimental-transform-types" src scripts package.json
Remember to search inside node_modules too if a dependency might call these. Your own code is easy to fix; an old dependency is the usual blocker.
Moving early: pros and cons
For: Temporal and the new Map methods, support until April 2029 instead of April 2028, and one fewer upgrade to do later.
Against: dependencies that lag behind, native add-ons that need a rebuild, and extra CI time while you run two versions.
For most teams the "against" list wins until a few weeks after the LTS date. For a new service with few dependencies, the "for" list can win sooner.
A low-drama upgrade plan
Add 26 to CI beside 24. A build matrix such as
node-version: [24, 26]in GitHub Actions shows differences without moving production.Run the grep above and fix hits in your own code.
Reinstall and rebuild. After switching versions, run
npm ciand thennpm rebuildif you use native add-ons.Read your logs for deprecation warnings under 26, especially around
module.register().Move staging first, then one low-risk service, then the rest.
On the question of when: my view is to wait for the LTS date for production. The Node project's own wording is that 26 stays the "Current" release until October, so I would treat it as a test target until then. Test now, deploy after 28 October, and give it a few weeks of CI before you retire Node 24.
The exception: if you have been waiting for Temporal, you can start sooner in new services.
Telling your tools which versions you support
While you run two versions side by side, say so in package.json, so an install on an unsupported version warns you early:
{
"engines": {
"node": ">=24 <27"
}
}
When you are ready to move, change it to ">=26". If your team uses nvm, a .nvmrc file containing just 26 keeps everyone on the same major version, and printing node --version in your CI logs shows what actually ran. They are small things, but drift between a laptop, CI and production is behind many "works on my machine" bugs.
Node's release model is changing too
A post on the Node.js site dated 10 March 2026 says that starting with Node 27, there will be one major release a year, every release will become LTS and a six-month alpha phase from October to March will replace the old odd-numbered releases. Node 27.0.0 is due in April 2027 and reaches LTS in October 2027. Node 26 is the last release under the old model.
The takeaway: you have until April 2028 on Node 24, and the cost of moving early is mostly CI time. Add 26 to your matrix this week, fix what the grep finds and decide on the production date after 28 October.
