Node.js 26 becomes LTS this month — which version to run, what breaks, and the new once-a-year schedule

Key takeaways

• Node.js 26 is promoted to LTS in late October 2026. On the same schedule, Node 24 leaves Active LTS on 20 October 2026 and moves to maintenance (security fixes only) (endoflife.date, Node.js releases).
• Node 20 is already dead (EOL 30 April 2026). Node 22 has six months left: EOL is 30 April 2027. If production still runs 20, upgrade now — the security releases due on 21 October will not patch it (nodejs.org).
• Node 26 is the last release under the old two-a-year model. From Node 27 there is one major per year (April), every line becomes LTS, and a new Alpha channel starts in October 2026 (Node.js announcement).
• What breaks on 26: native add-ons need a rebuild (new ABI), private _stream_* modules and writeHeader() are removed, --experimental-transform-types is gone, and module.register() now warns.
• Our advice: new projects start on 26. Existing apps on 24 can wait for the first few 26.x LTS patches, but should be on 26 well before Node 24's April 2028 EOL. Apps on 22 should skip 24 and go straight to 26.

1. What actually changes in October

For years an even-numbered major has shipped in spring as "Current" and been promoted to Long-Term Support in October. Node 26.0.0 shipped on 5 May 2026; the latest build is 26.12.0 (14 October). The LTS label is what most hosts, base images and enterprise policies wait for.

Three things happen around the same date:

1. 26.x becomes Active LTS. It gets backported fixes and security patches until April 2029.
2. 24.x ("Krypton") moves to Maintenance LTS. It gets security and critical fixes only, until 30 April 2028.
3. 27.x Alpha begins. This is new: signed, tagged pre-releases that are explicitly not for production, so library authors can test early.

2. Support dates at a glance

Dates are from endoflife.date and the Node.js release page. Odd-numbered lines (21, 23, 25) were short-lived and are all past EOL. If anything in your stack still says node:25, change it.

3. The new release model, explained once

The project announced in March 2026 that, starting with 27, it moves from two majors a year to one:

For application teams little changes: you still move to the line that went LTS in October. There are just no more odd versions to avoid.

4. What breaks when you move to 26

Node 26 runs on V8 14.6 and ships Undici 8 under the built-in fetch() (Node.js Design Patterns summary). The changes that cause real upgrade tickets:

• Native add-ons must be rebuilt. NODE_MODULE_VERSION is now 147. Anything with a .node binary (bcrypt, sharp, better-sqlite3, older node-sass) needs a fresh install on 26. If a package has not published 26-compatible prebuilds, it will try to compile, and that needs GCC 13.2+ and Python 3.10+ on the build box.
• Private stream modules are removed. require('_stream_readable') and the other _stream_* internals are gone. Old transitive dependencies are usually the cause; npm ls and a grep of node_modules will find them.
• http.Server.prototype.writeHeader() is removed. Use writeHead().
• --experimental-transform-types is gone. If you ran TypeScript enums or decorators straight through Node, you need a real build step (tsc, esbuild, swc) again. Plain type-stripping of .ts files is not affected by this removal.
• module.register() emits a DeprecationWarning. Custom loaders still work, but noisy logs in CI are a sign to migrate.
• Smaller behaviour changes: readable.read() without a size now returns one buffered chunk, and localStorage is undefined without a backing file. Hand-written stream parsers and test suites are where these show up.

The good news: Temporal is on by default. It is a proper date-time API with separate types for dates, times and instants in named time zones. For Indian products that store IST timestamps, render them for users abroad and calculate billing periods, it replaces a lot of moment/date-fns glue. Browsers still need a polyfill, so share the code carefully between server and client.

5. A practical upgrade plan

Week 1 — inventory (1–2 hours). Run node -v on every server, container and CI runner. Grep for FROM node: in Dockerfiles, node-version in GitHub Actions, .nvmrc, and "engines" in package.json. Write the versions down; most teams find at least one forgotten Node 18 or 20 cron box.

Week 1 — patch what you have. Apply the 22.x/24.x/26.x security releases due on or after 21 October (nodejs.org). Each line has at least one HIGH-severity fix. This is separate from the major upgrade and should not wait for it.

Week 2 — test on 26. - Bump CI to a matrix of your current version plus 26. - rm -rf node_modules && npm ci on 26 to force native rebuilds. - Run the suite with NODE_OPTIONS=--throw-deprecation once, to surface every deprecated call. - Load-test one service. V8 upgrades usually help throughput, but measure before you claim it.

Week 3–4 — roll out. Staging first, then one low-risk production service, then the rest. Pin an exact image tag (node:26.x.y-bookworm-slim), not node:latest. On serverless platforms, check that the provider offers a Node 26 runtime before you plan the date; managed runtimes often lag the LTS label by weeks.

6. The India angle

The effort column above is our estimate, not a benchmark. Even so, at common Indian contractor rates of ₹800–2,000 an hour, a clean 24→26 upgrade for a small app costs roughly ₹2,000–12,000. A 20→26 jump with native modules and a broken build server can cost ten times that. Running an EOL runtime does not save that money; it postpones the bill and adds risk on top.

The risk is also regulatory: CERT-In's 2022 directions require incident reports within six hours, and the DPDP Act adds breach duties. An incident on an unpatched, EOL runtime is hard to defend to a client or auditor.

Two local patterns are worth checking:

• Agency-built sites on shared hosting. Many Indian agencies deploy Node apps through a hosting panel's version dropdown and then never touch it again. Log in and check which version is actually selected.
• Freshers and students. Tutorials often pin Node 18 or 20. Use nvm or fnm, make 26 the default, and keep old versions only for old course projects.

7. Checklist

1. Inventory every Node runtime you own: servers, containers, CI, cron boxes, laptops.
2. Apply the 21 October security releases on 22.x / 24.x / 26.x.
3. Anything on Node 20 or older: schedule the upgrade to 26 this month.
4. Add Node 26 to the CI matrix; rebuild native modules; run once with --throw-deprecation.
5. Pin exact versions in Docker, .nvmrc and engines; ban latest.
6. Put 30 April 2027 (Node 22 EOL) and 30 April 2028 (Node 24 EOL) in the team calendar today.

Runtime upgrades are easy to postpone and expensive to rush. We run version inventories, patch windows and staged upgrades for client servers under Managed IT services — and if you are containerising a Node app for the first time, start with our Docker Compose generator.