Node.js 26 LTS: Upgrade Checklist for Production Apps

Node.js 26 becomes Active LTS on 28 October 2026 and is supported until April 2029. Upgrade after testing native addons, Corepack, removed APIs and fetch.

Every October one even-numbered Node.js release gets promoted to LTS, and this year it's Node 26. This one matters a bit more than usual: it's the last release under the old "two majors a year" model, and Node 22 has only six months of security fixes left. The API behind this website runs on Node 24 under PM2, so I went through the same list below before moving it. None of it is hard, but a few items fail in ways that look unrelated to Node, which is exactly why they waste an afternoon.

Key takeaways

• Dates: Node 26 is Active LTS from 28 October 2026 and reaches end of life on 30 April 2029. Node 22 ends on 30 April 2027. Node 20 is already end of life.
• Native addons must be rebuilt. NODE_MODULE_VERSION is now 147, so packages like bcrypt, sharp or better-sqlite3 need a fresh install, not a copied node_modules.
• Corepack isn't bundled anymore (since Node 25). If your CI or Dockerfile runs corepack enable, install it first.
• A few old APIs are gone: the private _stream_* modules and http.Server.prototype.writeHeader(). Old dependencies can crash on boot.
• Upgrade like a deploy: build a new release on Node 26, switch to it, keep the old one ready to switch back.

When is Node.js 26 LTS, and how long is it supported?

Node 26 was released on 5 May 2026 as the "Current" line. On 28 October 2026 it becomes Active LTS, which is the point where most teams should treat it as production-ready. It moves to maintenance in October 2027 and gets security fixes until 30 April 2029.

Here's where the other lines stand on that day:

• Node 24: moves into maintenance, end of life 30 April 2028. Safe to stay on for now.
• Node 22: already in maintenance, end of life 30 April 2027. Plan your move this winter.
• Node 20 and 25: end of life. No more security fixes. Move now.

The release schedule is changing after this

Starting with Node 27, Node.js ships one major release a year instead of two, and every release becomes LTS. Node 27 opens as an alpha in October 2026, becomes Current in April 2027 and LTS in October 2027. For you, nothing changes much: you'll still upgrade to a new LTS each year or two. The odd/even rule just stops mattering.

What breaks when you upgrade to Node 26

Native addons (ABI 147)

Every compiled package is tied to a NODE_MODULE_VERSION. Node 26 uses 147. If you copy node_modules from a Node 24 build, or a Docker layer cache reuses it, you'll see was compiled against a different Node.js version at startup. The fix is a clean install on Node 26:

rm -rf node_modules
npm ci            # or pnpm install --frozen-lockfile / bun install --frozen-lockfile

If a package has no prebuilt binary for Node 26 yet, it falls back to compiling from source, which needs build-essential and Python on the build machine. Check the package's releases before you upgrade production.

Corepack is not included

Node 25 stopped shipping Corepack, so Node 26 doesn't have it either. A Dockerfile or CI step that runs corepack enable to get pnpm or Yarn will fail with "command not found". Install it explicitly, or install the package manager directly. While you're editing the install step anyway, add the protections from my npm supply chain attack checklist.

npm install -g corepack && corepack enable
# or simply
npm install -g pnpm@10

Removed APIs

• The private stream modules _stream_readable, _stream_writable, _stream_duplex, _stream_transform, _stream_passthrough and _stream_wrap are gone. Your code probably doesn't use them, but a ten-year-old dependency might. Search your lockfile's packages: grep -rl "_stream_" node_modules --include=*.js | head.
• http.Server.prototype.writeHeader() is removed. Use writeHead().
• The --experimental-transform-types flag is removed. Plain type stripping still works, so node app.ts runs files that only use erasable TypeScript syntax.
• module.register() now prints a runtime deprecation warning. Tools that hook the module loader will be noisy until they update.

fetch() runs on Undici 8

Node's built-in fetch() is powered by Undici, which jumped to version 8. For normal API calls you won't notice. If you build headers dynamically or use custom dispatchers or proxy agents, run your integration tests against Node 26 before you trust it.

What you get in return

V8 14.6, the Temporal date and time API enabled by default (finally a sane replacement for Date math), Map.prototype.getOrInsert() and Iterator.concat(). Nothing you have to adopt on day one, but Temporal alone removes the need for a date library in many projects.

How I upgrade a production server to Node 26

The idea is to treat the Node version like any other deploy: build next to the running version, switch, keep a way back. This is how my own GitHub Actions deploys with release folders and auto-rollback work, and the Node upgrade fits straight into it.

1. Test in CI first

Add 26 to your test matrix a week before you touch the server, and pin the version you expect in package.json:

# .github/workflows/test.yml
strategy:
  matrix:
    node: [24, 26]
steps:
  - uses: actions/setup-node@v4
    with:
      node-version: ${{ matrix.node }}

// package.json
"engines": { "node": ">=24" }

2. Install Node 26 next to the old version

I use nvm on servers where several apps live together, because each app can stay on its own version and switching back is one command:

nvm install 26
nvm alias default 26
node -v

If you installed Node from NodeSource, its setup script switches the apt repo to the new major; the old binary is replaced, so take a snapshot first.

3. Build a fresh release and restart PM2 on the new Node

cd /srv/app/releases/new && npm ci && npm run build
pm2 update                  # restarts the PM2 daemon on the new Node
pm2 restart ecosystem.config.js --update-env
pm2 logs --lines 50

Forgetting pm2 update is the classic mistake: the daemon keeps running on the old Node, and your app silently does too. Check with pm2 describe app | grep "node.js version". If anything looks wrong, switch the current symlink back to the previous release, nvm alias default 24, and run pm2 update again.

4. Watch it for a day

Memory use and startup time are the two numbers I compare before and after. If the process starts restarting in a loop, the heap out of memory guide and the EADDRINUSE guide cover the two errors I see most after Node upgrades.

Frequently asked questions

Should I upgrade to Node 26 or stay on Node 24?

Node 24 is supported until April 2028, so there's no emergency. Move to 26 when your dependencies support it and you have a quiet week; new projects should start on 26. If you're on Node 22 or older, upgrade now, and going straight to 26 saves you one extra upgrade.

Can I skip from Node 20 or 22 straight to 26?

Yes. Node has no requirement to go through each version. Read the breaking-change notes for every major in between, run your tests and do a clean install. Jumping several majors at once just means a longer list to check.

Do I need to rebuild node_modules after upgrading Node?

Yes, if any dependency has a native addon. The safest habit is to never reuse node_modules across Node majors: delete it and run a clean install from the lockfile.

Does Bun or Deno change any of this?

If your app actually runs on Bun or Deno, the Node release schedule doesn't apply to the runtime. But build tools often still run on Node in CI, so the Corepack and native-addon notes can still affect your pipeline.

Is Node.js 26 stable enough for production?

From Active LTS on 28 October 2026, yes; that's what the label means. Many teams wait for the first few LTS patch releases. That's sensible, as long as "wait" has an end date.

Need a hand with the upgrade?

I upgrade Node.js apps and servers for clients: dependency audit, CI matrix, clean rebuild and a deploy with rollback ready. Have a look at my DevOps services or the CI/CD with auto rollback package, or tell me what you're running and I'll tell you what the upgrade involves.