Node.js 26 is LTS: do not let a platform schedule your upgrade

NodeSource’s weekly note on 6 October confirmed Node.js 26 as LTS. The next day, 26.11.0 shipped, with 26.11.1 available shortly after. The same note carried a more important line: Node.js 20 support keeps disappearing across platforms, including Vercel and GitHub Actions.

LTS is overrated as a promise

A lot of people read LTS as “I can stop moving”. That is not what it means.

LTS means the line receives security and critical bug fixes for a period. It guarantees you will not be left behind while you stay here. It does not guarantee staying here requires nothing from you.

The real deadline usually does not come from the Node project. It comes from platforms:

• a hosting platform stops offering a runtime
• a CI image drops the old version
• a dependency raises the bar in its engines field

When those happen, your package.json has not changed a single character, but the build is already broken.

The order I actually use

Roughly this:

1. Add a build on the new version in CI, running alongside the current one. This changes no dependencies; it just shows you whether it goes red.
2. If it is red, fix it, then merge. Production is still on the old version, so risk is zero.
3. Once it is green, switch engines and the primary CI version over.
4. Only then touch the local development environment.

The order of steps 1 and 4 is the point: let CI move to the new version first, and your machine last. Do it the other way round and you hit a pile of problems locally with no way to tell which are real and which are environment drift.

A note on N|Solid

The same note mentions N|Solid Runtime 6.3.8 supporting the latest Node.js 22 and 24. If you run that class of monitored runtime, be aware its support matrix tends to lag Node itself — check its version table before upgrading, or you will be stuck at “Node moved, monitoring did not”.

Also: the NodeConf EU recap is out, and JSConf México runs 28–30 October.

My take

My rule is simple: follow LTS, but do not wait for a platform to tell me.

Concretely, treat the runtime version as a dependency with an expiry date. It expires just like your npm packages, and it announces that expiry the same way — a failed build. The only difference is that an expired dependency usually gives you a day, while a runtime version gives you a year.

A year not spent upgrading is a year spent firefighting later.