Node.js 26 becomes LTS 'Lithium': the release that changed almost nothing, and that is the point

I was patching an old server on the evening of October 28 when I refreshed the Node.js release list and saw 26.13.0 'Lithium' (LTS). What stopped me was not the size of the release. It was how small it was. The notable changes section has three paragraphs: it is LTS now, nothing else changed, and by the way, libatomic.

A release that changes nothing is the one I most wanted to write down this month.

What actually changed: one field a program can see

process.release now reports the LTS shape instead of the current one, the codename is Lithium, and the support window runs to the end of April 2029. Otherwise 26.13.0 and 26.12.1 are the same code.

The ceremony matters more than the diff, because of what it means in practice: from here on, the 26.x line takes bug fixes and security patches only. For a service that has to run for three years, that is the best kind of news. You can finally stop reading every changelog.

24.22.2 ‘Krypton’ landed the same day. Two LTS lines running in parallel is the rhythm Node has kept for years, and two days later 27.0.0-alpha.0.0.0 showed up, which means the next major is already moving. Old line hardened, new line experimenting, the line in the middle doing nothing except holding still.

Why “no code changes” is good news

After enough years of ops work, my expectations for feature releases are negative. New features mean new branches, new defaults, new edge cases, and the most expensive property of a machine I run is not speed. It is predictability.

A release that only touches metadata is the project pressing freeze on your behalf. It does not promise faster. It promises unchanged. That promise is rarely said out loud in LTS language, so this tag gets its own line in my migration notes: 26.13.0 is where the 26 line starts, not another patch on 26.12.1.

The libatomic paragraph is a note to old images

The third paragraph is easy to skip: since Node 25, the official Linux binaries link against libatomic, and some distributions need it installed separately.

I have hit a version of this on a minimal Debian 12 image. It was not a build error. It surfaced only when an atomic operation ran, with a missing-symbol message that mentioned nothing about Node. If your deploy image is trimmed down (Alpine, distroless, minimal Debian), check that libatomic1 is present before upgrading. Thirty seconds there saves a night of debugging later.

Should you move now

If you run 26.12.x in production, move to 26.13.0 in your next maintenance window. The blast radius is essentially zero and the payoff is being inside the supported window on purpose rather than by accident. If you are on 24.x or 22.x, there is no rush: 24.22.2 also shipped, and both lines are supported. The machines that need attention are the ones still sitting on EOL releases.

One more thing worth doing while you are in there: pin CI to 26.13 instead of 26. A floating major feels convenient until it upgrades a minor version on a day you were not ready, and the first release of an LTS line is exactly the point worth pinning.

A reminder: Node’s November security releases are scheduled for November 11, HIGH severity across all three lines. I wrote the pre-announcement up here. It is fine to do both upgrades on the same day.