Anup Karanjkar

Posted on Oct 19 Originally published at wowhow.cloud

Node 26 Becomes LTS on 28 October: Upgrade Guide from 24 and 22

#node26 #nodejs26 #upgradenode #node24

Node.js 26 is scheduled to enter Long Term Support on 28 October 2026, eight days after Node 24 drops from Active LTS to Maintenance on 20 October, and it is supported through 30 April 2029.[1] Node 22 stays in Maintenance until 30 April 2027, and Node 20 has been end-of-life since 30 April 2026. As of 19 October the latest 26.x release is 26.12.0, shipped 14 October with V8 14.6 and npm 11.20.0[2]. This post gives you the full schedule table from the official file, the changes in Node 26 that can actually break an upgrade, the exact commands for nvm, fnm, Volta, GitHub Actions and Docker, and a plain answer to whether you should move now or wait. Nothing here is true until the release team flips the switch, so every date below is the planned one.

TL;DR

Node 26 becomes LTS on 28 October 2026 (planned). The schedule file lists no codename yet, so none is stated here.
Node 24 enters Maintenance on 20 October 2026 and reaches end-of-life on 30 April 2028. Staying on 24 is safe for production.
Node 22 is already in Maintenance and ends on 30 April 2027. It is the line that needs a plan first.
Node 20 is end-of-life since 30 April 2026 and gets no security fixes.
What bites in 26: removed http.Server.prototype.writeHeader(), removed legacy _stream_* modules, runtime deprecations for module.register(), and the removal of --experimental-transform-types.
Run your tests on 26 with --trace-deprecation this week; switch production after 28 October, not before.

Node.js release schedule as of 19 October 2026

The Node.js Release working group publishes its schedule as a JSON file, and the README table in the same repository is generated from the same dates[1][3]. The table below is copied from that file. The README adds the caveat that dates are subject to change, and that the exact date of an LTS move is chosen no later than the first day of the month it happens in.

Line	Status on 19 Oct 2026	First release	LTS start	Maintenance start	End-of-life

| Node 20 (Iron) | End-of-life | 2023-04-18 | 2023-10-24 | 2024-10-22 | 2026-04-30 |

| Node 22 (Jod) | Maintenance LTS | 2024-04-24 | 2024-10-29 | 2025-10-21 | 2027-04-30 |

| Node 24 (Krypton) | Active LTS until 20 Oct | 2025-05-06 | 2025-10-28 | 2026-10-20 | 2028-04-30 |

| Node 26 | Current | 2026-05-05 | 2026-10-28 | 2027-10-20 | 2029-04-30 |

Two readings of that table matter. First, the working group says an even-numbered line stays in Active LTS for 12 months and then spends 18 months in Maintenance[3]. Node 24 and 26 both fit that pattern: 28 October to 20 October is the 12 months, 20 October to 30 April the 18. Second, the Node 27 row carries no LTS date and no codename in the schedule file. The file does not say what that means for the odd/even rule, so check the file again before you plan anything around 27.

What Maintenance means for Node 24

The README defines Maintenance as critical bug fixes and security updates, with new features added only at the release team's discretion, typically when they help migration to a later line[3]. It does not mean abandoned. Node 24 will keep getting security releases for another 18 months. The practical difference is that you should stop expecting backports of new APIs, and you should treat the line as a place you are leaving, not a place you are settling.

Why Node 22 is the line that needs a decision

Node 22 has about six months of life left (30 April 2027). If you run it, the question is not whether to move but whether to go to 24 or straight to 26. Going to 24 buys you until April 2028. Going to 26 buys you until April 2029 and one fewer migration. The catch is that 26 has been out for five months as a Current release, and the changes in the next section apply to you in full.

What changed in Node 26 that matters when you upgrade

The 26.0.0 release notes, dated 5 May 2026, list the headline items as the Temporal API enabled by default, V8 updated to 14.6 and Undici updated to 8.0[4]. Version numbers from the release feed: 26.12.0 ships V8 14.6.202.34 and npm 11.20.0, while Node 24.22.0 ships V8 13.6 and npm 11.19.1, and Node 22.23.3 ships V8 12.4 and npm 10.9.9[2]. The npm major jump matters if you move from 22, because npm 10 to 11 is a separate set of changes to read.

New in 26.0.0

Temporal API on by default. The modern date and time API is available without a flag, contributed by Richard Lau in PR 61806[4]. Your Date code keeps working. Nothing forces you to migrate, but libraries that feature-detect Temporal may change behavior once it exists.
V8 14.6. The notes call out Map.prototype.getOrInsert() and getOrInsertComputed() (also on WeakMap) plus Iterator.concat()[4]. Both are small, but getOrInsertComputed removes the common get-check-set pattern in caches.
Undici 8.0.2 in the 26.0.0 release, which backs fetch. If you pin a custom undici dispatcher or agent, retest it.

Removed and deprecated in 26.0.0

These are the entries that break builds, taken from the Deprecations and Removals section of the changelog[4]:

http.Server.prototype.writeHeader() is gone. Use writeHead().
The legacy _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform and _stream_passthrough modules are removed. Old packages that require('_stream_readable') will throw. Import from node:stream.
--experimental-transform-types is removed, which hits anyone running TypeScript files through that flag.
module.register() is now runtime-deprecated, so loader setups built on it print a warning.
DEP0182 moved to end-of-life, DEP0203 and DEP0204 became runtime deprecations in crypto, and DEP0201 in stream became a runtime deprecation. I did not look up what each DEP number covers in the deprecations page, so grep your warnings for those codes.
Platform floor: the build now needs GCC 13.2 and drops Python 3.9[4]. That matters if you compile Node yourself or build native addons on old CI images.

One more change that is easy to miss: localStorage now returns undefined when no storage file is configured, per the semver-major list in the same release[4]. Code that assumed an object will fail at the first property access.

Useful additions since 26.0.0

Node 26 already has twelve minor releases (26.1.0 to 26.12.0), so some features you may want are not in 24. These are the ones listed under Notable Changes, with the release that added them[4]:

Version	Date	Addition

| 26.1.0 | 2026-05-07 | Experimental node:ffi module, behind --experimental-ffi |

| 26.2.0 | 2026-05-20 | stream.compose marked stable; writeInformation for 1xx responses |

| 26.8.0 | 2026-08-26 | TracingChannel in diagnostics_channel marked stable |

| 26.9.0 | 2026-09-16 | node:ffi enabled by default |

| 26.11.0 | 2026-10-07 | Buffer.stringLength(), isLatin1, Alpine Linux promoted to tier 2 support |

| 26.12.0 | 2026-10-14 | http.websocketMask() and websocketUnmask() |

The ffi row deserves a second look. The 26.1.0 notes say the API is inherently unsafe, since bad pointers or wrong signatures can crash the process or corrupt memory[4]. Being on by default in 26.9.0 does not make it safe. Treat it as something you do not use in production code until it has a track record. Also from the notes: the 26.3.0 release flags a risk that macOS Universal Binaries may not be maintained for the full life of Node 26, though the stated intention is to keep shipping them as long as practical.

Upgrade checklist: Node 24 or 22 to Node 26

1. Install 26 beside your current version

Do not replace anything yet. Install 26 next to what you run, so you can switch per shell.

# nvm: install, then carry global packages over from 24
nvm install --reinstall-packages-from=24 26
nvm use 26

# fnm
fnm install 26
fnm use 26

# Volta (pins the version in package.json)
volta install node@26
volta pin node@26

The --reinstall-packages-from flag is documented in the nvm README[5], and fnm install [VERSION] and fnm use [VERSION] are in the fnm command reference[6]. The Volta commands are from memory of its docs and I did not re-verify them today, so run volta --help if one fails. After 28 October, nvm install --lts should resolve to 26, but check node -v rather than trusting it.

2. Declare what you support in package.json

{
  "engines": {
    "node": ">=24 <27"
  }
}

Widening engines to cover both 24 and 26 lets you run both in CI during the transition without npm complaining. Add "engine-strict=true" to .npmrc if you want npm to enforce it. Also drop a .nvmrc or .node-version file: the actions/setup-node action reads either through its node-version-file input[7]. If you use Corepack for package managers, run corepack --version after installing 26 to confirm it is present, because Corepack distribution has changed across recent Node releases and I did not trace the details.

3. Run a CI matrix on both lines

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [24, 26]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci
      - run: npm test

The current major of actions/setup-node is v7; its latest release, v7.1.0, was published on 8 October 2026[7]. The README also notes that automatic package-manager caching is on by default and can be turned off with package-manager-cache: false for workflows that handle sensitive data. For a full pipeline around this step, see our GitHub Actions CI/CD pipeline for Node.js.

4. Update Docker base images

Docker Hub already carries the 26 tags: node:26, node:26-slim, node:26-alpine, node:26-bookworm-slim and node:26-trixie-slim, plus pinned forms like node:26.12.0[8]. Pin a major (node:26-slim) in production, and pin the full version if you need byte-identical rebuilds. I could not confirm from a primary source whether Docker will add an lts alias pointing at 26 on 28 October, so do not depend on one. If your image builds native addons on Alpine, remember that 26.11.0 promoted Alpine to tier 2 support[4], which is good news but not a reason to skip a test build. Our production Docker Compose guide for Node.js covers the rest of the stack.

How to test before you switch

Run the full suite on 26. Start with unit tests, then integration tests against real databases and queues. Failures from removed APIs show up as thrown errors, so they are loud.
Surface deprecations. Run node --trace-deprecation your-entry.js or set NODE_OPTIONS=--trace-deprecation in CI. Runtime deprecations print a warning with a stack, and the stack usually points at a dependency, not your code. To make the suite fail on them, use --throw-deprecation.
Grep for the removed names. Search your source and node_modules for writeHeader(, _stream_, module.register and experimental-transform-types. Dependencies are the usual source of old stream imports.
Rebuild native addons. Delete node_modules and run npm ci on 26 so every addon compiles against the new V8. Anything built with node-gyp needs a toolchain that supports GCC 13.2 on Linux; addons that ship prebuilt binaries need a release that targets Node 26's ABI. If a package has no 26 build, that is your blocker, not Node.
Diff your fixtures and configs. When a test fails on a data shape, normalize the sample before comparing. Paste it into the JSON formatter to normalize them before comparing, or run YAML configs through the YAML to JSON converter.
Soak in staging. Run 26 under real traffic in staging for a week and watch memory and latency. A new V8 changes garbage collection behavior in ways unit tests do not show.

If your project is a command-line tool, our Node.js and TypeScript CLI guide has patterns for testing across several runtime versions.

When to upgrade now, and when to wait

Your situation	Recommendation	Reason

| Production on Node 20 | Move now, to 24 at minimum | End-of-life since 30 April 2026; no security fixes |

| Production on Node 22 | Plan the move before spring 2027; test on 26 now | Ends 30 April 2027 |

| Production on Node 24 | Wait. Test on 26, switch in 2027 | Supported until 30 April 2028 |

| New project | Start on 24 today, or 26 after 28 October | 26 is the longer runway (to April 2029) |

| Library author | Add 26 to your CI matrix now | Users will adopt 26 as soon as it is LTS |

The reason to wait on 24 is boring and sound: LTS lines get fixes that have been audited by the release team, and a Current line that has just changed status has had less production exposure than the fifth month of a stable one. Node 26 has had five months of Current releases, and the 26.3.1 and 26.5.1 releases each shipped a list of CVE fixes[4]. Active patching counts in its favor, though it also shows the line has had real security work to do.

If you do move before the LTS date, treat it as a normal Current-line adoption: pin an exact version, watch the changelog for each minor, and be ready to roll back.

Frequently asked questions

What date does Node 26 become LTS?

The official schedule file lists 28 October 2026 as the LTS start for Node 26[1]. The README says dates are subject to change, so confirm on the day. This post was written on 19 October, before that date.

Is Node 24 still safe to use after 20 October?

Yes. From 20 October 2026 it is in Maintenance, which means critical bug fixes and security updates, until 30 April 2028[1]. You lose new-feature backports, not security fixes.

When does Node 22 reach end-of-life?

30 April 2027, according to the schedule file[1]. It has been in Maintenance since 21 October 2025.

Is Node 20 end-of-life already?

Yes. The schedule lists 30 April 2026 as its end date[1]. If you still run it, upgrade to 24 or 26 rather than hunting for patched builds.

Does Node 26 have a codename?

Not in the schedule file as of 19 October 2026, where the codename field for v26 is empty[1]. Earlier LTS lines got element names such as Jod and Krypton, but I will not guess one for 26.

Can I skip Node 24 and go from 22 straight to 26?

Yes, and many teams will. You inherit every removal and deprecation between the two lines, plus the npm 10 to 11 change, so read the changelogs for 24 and 26 and run the test steps above. I only reviewed the 26 changelog for this post.

Sources

8. Docker Hub: official node image tags (read 19 October 2026)

Originally published at wowhow.cloud

DEV Community