On October 28, 2026, the Node.js project promoted the 26.x line to Long Term Support with version 26.13.0, codenamed Lithium. The release itself is deliberately boring: release manager Richard Lau's notes say that other than updating metadata, such as the process.release object, no further changes from Node.js 26.12.1 are included. That is the point. LTS is not a feature drop, it is a promise: the line you have been testing for six months is now the line the project will keep patched until April 30, 2029.

If you run Node.js behind an API, a build pipeline, or a Next.js app that already had a rough October, this is the signal to start planning the move, not to rush it.

What LTS actually changes

Node.js 26 first shipped on May 5, 2026, and spent six months as a Current release: fine for development and CI, not the default for long-lived production workloads. Promotion to Active LTS flips that default. From now on, 26.x gets bug fixes and security patches on a predictable schedule, moves to Maintenance in October 2027, and reaches end of life on April 30, 2029. The project's guidance is blunt: production applications should only use Active LTS or Maintenance LTS releases.

What you inherit with the line matters more than the promotion release itself. Node.js 26 enables the Temporal date and time API by default, replacing the old Date object with immutable, time zone aware types. The engine moves to V8 14.6, and Undici, the HTTP client behind the built-in fetch(), moves to version 8. The line also carries the October 21 security release, which patched issues across the 26.x, 24.x, and 22.x lines with a highest severity of High, including a Brotli decoder flaw that could corrupt process memory and lead to remote code execution. If your 26.x installs are still older than 26.12.1, the LTS promotion is the least of your reasons to update.

This is the last old-school LTS

Node.js 26 is also the last major release under the project's traditional schedule. Under the old model, two majors shipped per year, only even-numbered lines became LTS, and odd-numbered lines died after six months. From Node.js 27 onward, the model is annual: one major per year in April, every major becomes LTS the following October, and a six-month Alpha phase runs from October to March so library authors can test breaking changes before they ship.

That Alpha phase matters. Node.js 27's Alpha opened on the same day 26 went LTS, and the release team urges library authors to integrate Alpha releases into CI early, because if you only test on LTS releases, you cannot report bugs before they affect your users. The old shortcut, odd numbers are throwaways, stops working the moment you see a 27.0.0-alpha build. Treat Alpha as an early warning channel, never as a production runtime.

What breaks when you move to 26

Most breakage will come from old transitive dependencies, not from your own code. Node.js 26 removes http.Server.prototype.writeHeader() (use writeHead()), removes the internal _stream_* modules that some ancient packages import directly, and removes the --experimental-transform-types flag. module.register() is runtime-deprecated and prints warnings. Building Node.js from source now needs GCC 13.2 or newer, which matters if you maintain custom Docker images.

The practical test is cheap: add Node.js 26 to your CI matrix this week and run the suite. If it passes, you have a green light for a scheduled move. If it fails, the failure list is your migration backlog, and it is almost always concentrated in one or two unmaintained packages.

The operator's upgrade order

Work through this in order. Every rushed Node.js upgrade story starts with a runtime somebody forgot.

  1. Inventory every Node.js you run. Not just your laptop: servers, CI runners, base images, serverless runtimes, and single executable apps that embed their own copy of the runtime. Run node -v on each, and check node -p "process.release.lts" on the new build: a codename means LTS, undefined means it is still Current.
  2. Patch the line you are on first. On 26.x below 26.12.1, 24.x below 24.22.1, or 22.x below 22.23.4, take the October 21 security fixes now, before any major-line move. A clean npm audit does not cover the runtime itself.
  3. Rebuild container images on a fresh pull. An image built before October 21 keeps the old runtime until you rebuild it. The same applies to startup snapshots and single executables: they embed Node.js, so they stay vulnerable until rebuilt.
  4. Decide by line, not by FOMO. On Node.js 24? Supported until April 2028, in Maintenance since October 20, 2026, so a stable service can wait for a quiet window. On Node.js 22? End of life is April 30, 2027, so put the move on the calendar now. On Node.js 20 or older, or the short-lived 25 line? Both are end of life, no patch is coming. That is the urgent queue.
  5. Pin deliberately, then verify. Pin the LTS line in your version manager, Dockerfile, and CI matrix, deploy to staging, and confirm the running process reports the version you think it does. Same discipline as this blog's OpenSSL 4.1 upgrade playbook: patch, verify, then move on.

Start new projects on 26, move old ones on evidence

New projects should start on Node.js 26: it is the recommended production line, with the longest support runway of any current line. Existing services move when their tests pass on 26 and the move fits a quiet release window, not before. Waiting is fine for a stable service. Waiting with no plan is how teams end up doing forced upgrades at 3 a.m., usually the week a security advisory lands.

If you are still deciding how runtimes get onto your machines, our guide to installing software on Linux covers the version manager route that makes this kind of line switch a one-command change instead of a reinstall.

Node.js 26 'Lithium' will be with us until April 2029. That is a long time to run a runtime you chose on purpose, and a long time to regret one you drifted onto. The LTS label gives you the runway. Use the next quiet week to earn it.

Sources

  • Node.js project, "Node.js Releases" (v26 listed as LTS, last updated October 28, 2026): https://nodejs.org/en/about/previous-releases
  • Node.js project, "Evolving the Node.js Release Schedule": https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule
  • Node.js project, "Wednesday, October 21, 2026 Security Releases": https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
  • Node.js 26.13.0 release notes (release manager Richard Lau; metadata-only change over 26.12.1), via the Node.js release blog.