Node.js 22, 24, 26: Which LTS to Move to, and When?

As of September 2026, three active lines coexist in the Node.js world: 22, 24, and 26. The question of which one to move to, and when, can no longer be answered with "the newest version is always best" logic, because each line has its own risk profile and timeline. This guide gives you a concrete migration decision based on the official Node.js release schedule and the real breaking changes.

💡 Pro Tip: Before deciding, check which line you're on with node -v and check your native dependencies (compiled modules like bcrypt, sharp, sqlite3) with npm ls --depth=0 — the real risk isn't in the version number, it's in the ABI compatibility of these modules.

Table of Contents

• Version table as of September 2026
• The difference between Active LTS / Maintenance / Current and their risk profiles
• The October 2026 breaking point: what happens when Node 26 becomes LTS
• What actually breaks on upgrade (N-API, native rebuilds, OpenSSL)
• OpenSSL 3.5 and security level 2
• V8 13.6 and native addons
• Compiler and platform requirements
• Breaks already in effect on Node 26 (Current)
• Minimum versions supported by Next.js/Prisma/Sentry
• Zero-downtime upgrade procedure and rollback
• How to set up your CI matrix
• The 2027 horizon: Node.js's move to a yearly single-LTS model
• FAQ
• Should I move from Node.js 22 to 24, or wait for 26?
• When does Node 22 reach EOL?
• When will Node 26 become LTS?
• Why do native modules break on a Node version upgrade?
• Does it make sense to jump directly from Node 24 to Node 26?
• Can I use Prisma 8 on Node 22?
• Conclusion
• Sources

Version table as of September 2026

The Node.js project supports three versions simultaneously, each in a different phase:

Source: nodejs/Release official schedule.

As of the writing date (2026-09-23), the latest release on the 26.x series is patch v26.10.0 (September 21, 2026; npm 11.19.1, V8 14.6.202.34, OpenSSL 3.5.8, ABI module version 147). The 24.x series is roughly at 24.21.x (early September 2026), and 22.x roughly at 22.23.x (late July 2026) — confirm the exact patch with nvm ls-remote --lts right before upgrading, since patches ship every few weeks.

The difference between Active LTS / Maintenance / Current and their risk profiles

The three phases offer different guarantee levels:

• Current: Contains changes straight from the main development branch that haven't passed LTS approval yet; major API breaks can land here freely.
• Active LTS: New features, bug fixes, and updates that the release team considers "suitable and stable" are accepted — the recommended phase for production.
• Maintenance LTS: Only critical bug fixes and security updates; adding new features is at the release team's discretion and rare.

Practical risk ranking: Current > Active LTS > Maintenance LTS. Node 22 is currently in Maintenance — safe if you're not waiting on new features, but not an investment in the future. Node 24 is in Active LTS — the right default for most teams. Node 26 is still in Current — fine for test/trial environments, but wait until October 28, 2026 for production.

The October 2026 breaking point: what happens when Node 26 becomes LTS

October 28, 2026 isn't a single date — it's two events eight days apart: on that same calendar, Node 24 drops from Active LTS to Maintenance LTS (October 20, 2026), and eight days later Node 26 moves up to Active LTS. In other words, the third week of October 2026 is the moment the answer to "which line should you pick for a new project" changes.

An important distinction: since Node 26 is already in the Current phase, teams using 26.x as of 2026-09-23 are already seeing SEMVER-MAJOR breaks. The LTS label arriving on October 28, 2026 doesn't undo those breaks — it only adds the guarantee that "it's now stable, you can take it to production." The breaking changes below apply both to "those already on 26" and "those waiting for LTS" — only the timing differs.

A context note: with the plan it published on March 10, 2026, the Node.js project announced a move to a model of one major release per year, with every release becoming LTS; this eliminates the even/odd distinction and adds a six-month Alpha channel. Node 27's schedule under this new cadence was already given in the announcement as absolute dates: Alpha in October 2026, 27.0.0 in April 2027 — keep this as background while making your 22/24/26 decision; it needs no direct action.

What actually breaks on upgrade (N-API, native rebuilds, OpenSSL)

There are four categories far more critical than the version number bump itself:

OpenSSL 3.5 and security level 2

Node 24 switched to OpenSSL 3.5 by default, and security level 2 became the default: RSA/DSA/DH keys shorter than 2048 bits, ECC keys shorter than 224 bits, and RC4-based cipher suites are now rejected. If you have an old certificate or a legacy TLS integration, check your key lengths before upgrading.

V8 13.6 and native addons

With the V8 engine moving to 13.6, compiled (native) addons that bind directly to V8 APIs may not work without an update; in some cases, where C++17 used to be sufficient, C++20 support may now be required. Preferring packages bound to NODE-API rather than V8 directly reduces future rebuild obligations wherever possible.

Compiler and platform requirements

Starting with Node 24, MSVC support for building on Windows was removed and ClangCL became mandatory; building from source requires a minimum of gcc 12.2 on AIX/Linux and a minimum of Xcode 16.1 on macOS. Prebuilt macOS binaries now require a minimum of macOS 13.5; prebuilt binaries are no longer provided for 32-bit Windows (starting with 23.0.0) or 32-bit Linux on armv7 (starting with 24.0.0).

Breaks already in effect on Node 26 (Current)

ServerResponse.prototype.writeHeader() (DEP0063) has been fully removed — you must use writeHead(). The legacy _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform, and _stream_passthrough modules have been fully removed (DEP0193 is no longer just a runtime warning — it's now End-of-Life). On the flip side, the Temporal API is enabled by default in Node 26 and Undici has been upgraded to 8.0.2 — an advantage for your date/time code.

These two breaks show up like this in practice: if old HTTP server code still calls res.writeHeader(200, {...}), that call now hits an undefined function and throws a TypeError on Node 26 — it isn't silently ignored. Similarly, a dependency that requires one of core's node:_stream_* modules won't find it on Node 26. A quick scan of the codebase before upgrading is worth doing:

1# Scan for writeHeader and legacy _stream_* usage
2grep -rn "writeHeader(" src/ --include="*.ts" --include="*.js"
3grep -rn "node:_stream_\|require('_stream_" node_modules --include="*.js" --include="*.cjs" -l

On the TLS/OpenSSL side, you can quickly verify in a staging environment with openssl whether the move to security level 2 actually affects you — checking an old certificate's key length is far cheaper than getting a surprise "handshake failure" in production:

1# Check certificate key length (below 2048 bits is rejected on Node 24+)
2openssl x509 -in cert.pem -noout -text | grep "Public-Key"

To understand why native modules break: every Node major version can change the V8/N-API ABI (NODE_MODULE_VERSION). If .node compiled addons were packaged against the old ABI, they segfault on the new version due to struct offset/symbol mismatches, or get rejected by Node's own version check. Packages bound to the stable N-API (rather than V8 headers) are largely immune to this problem. The first step after upgrading:

1# Check which native modules are compiled
2npm ls --all 2>&1 | grep -i "gyp\|native"
3 
4# On ABI mismatch, try a clean rebuild first
5rm -rf node_modules package-lock.json
6npm install
7npm rebuild
8 
9# To rebuild a specific package
10npm rebuild bcrypt --build-from-source

If you're still getting errors after rebuilding, check the package's own GitHub page for an open issue about "Node 24/26 support" — that's the most reliable place to see whether a prebuilt binary has been published for the new line.

Minimum versions supported by Next.js/Prisma/Sentry

Could the rest of your stack be holding you back? As of 2026-09-23, the engines.node fields of current npm registry releases are as follows:

The only real risk here is Prisma: if your project is stuck on an early Node 22 minor (before 22.18), move to at least a current 22.x patch (around 22.23.x) before upgrading to Prisma 8. Next.js and Sentry aren't a bottleneck, since their minimums already sit below all three LTS lines. To confirm the exact numbers for your own project:

1npm view next engines.node
2npm view prisma engines.node
3npm view @sentry/nextjs engines.node

Defining an engines field in your own package.json is also the cheapest way to explicitly document which Node line you're targeting within your team and CI configuration — a useful reference point, especially for teams where different developers use different local Node versions:

1{
2  "engines": {
3    "node": ">=22.18.0"
4  }
5}

Keeping this field manually in sync with the version in your .nvmrc lets you catch "works locally but breaks in CI" version mismatches early.

Zero-downtime upgrade procedure and rollback

A Node major version upgrade carries TLS/OpenSSL behavior-change and native ABI risk, so it shouldn't be tried directly in production. The recommended order:

1. Install the target version locally and in CI — nvm install 24 && nvm use 24 (or n 24), update your .nvmrc/.node-version file.
2. Do a clean rebuild of native dependencies — add the npm rebuild step from the previous section to your CI pipeline, so ABI mismatches get caught before merge.
3. Verify TLS/OpenSSL behavior in staging — especially for services using an old certificate or legacy integration, test the security level 2 check in staging.
4. Canary/blue-green deployment — route the new Node version to a small percentage of traffic (say, 5-10%), and watch the error rate and p95 latency.
5. Keep a rollback plan ready — keep the build artifact compiled with the old Node version (including native modules) for at least one deployment window; if something breaks, route traffic back and rebuild native modules against the old version.

The critical point: rollback isn't just switching the Node binary — native modules rebuilt against the new ABI must also be rebuilt against the old ABI when you go back. Storing node_modules as a version-tagged artifact saves time during a live rollback.

Across a team with multiple services, moving in waves rather than all at once further reduces risk: upgrade the lowest-traffic, least critical service first, and move to the next wave if nothing breaks. Wait at least one full business day between waves and compare error rate, memory usage, and p95/p99 latency — that shows you whether there is a performance regression relative to the previous Node version. This matters especially for the OpenSSL 3.5 move, since the weak key/cipher combinations security level 2 rejects only surface on connections hitting real traffic — better to see that in a wave-controlled environment than live.

How to set up your CI matrix

When setting up your CI matrix, follow two principles: always test the Active LTS line running in production, and add the next Current line as an early warning — but never make Current a deploy gate. Lines dropped to Maintenance and nearing EOL just create noise; remove them.

1# .github/workflows/ci.yml (GitHub Actions with actions/setup-node)
2strategy:
3  matrix:
4    node-version: ["24.x", "26.x"] # Active LTS + Current for early warning
5    # '22.x' has dropped to Maintenance: keep only if you support an old branch
6    include:
7      - node-version: "26.x"
8        experimental: true # 26.x is still Current: shouldn't block
9continue-on-error: ${{ matrix.experimental || false }}
10steps:
11  - uses: actions/checkout@v4
12  - uses: actions/setup-node@v4
13    with:
14      node-version: ${{ matrix.node-version }}
15      cache: "npm"
16  - run: npm ci
17  - run: npm rebuild
18  - run: npm test

A break on the 26.x line should only be "informational" (via continue-on-error: true) — making it a deploy-blocking gate before October 28, 2026 would be premature; after that date, once promoted to Active LTS, upgrade its role from "early warning" to "mandatory."

The 2027 horizon: Node.js's move to a yearly single-LTS model

On March 10, 2026, the Node.js project announced a plan to drop the even/odd distinction and ship a single major release per year, with every release going straight to LTS, alongside a six-month Alpha channel. The schedule is already fixed for Node 27: Alpha starts October 2026, 27.0.0 ships April 2027, it enters LTS October 2027, and reaches EOL April 2030; phase durations are Alpha 6 months, Current 6 months, LTS 30 months. Today's "even number = LTS candidate" intuition stops holding in the coming years — keep this plan as a reminder while making your 22/24/26 decision: whichever line you pick, move forward knowing the version-numbering logic will change within a few years.

FAQ

Should I move from Node.js 22 to 24, or wait for 26?

Node 24 is the right default for most production services, because it's in the Active LTS phase and has passed the release team's "stable" approval. Node 26 is still in the Current phase; it can be considered for new projects once it moves to Active LTS on October 28, 2026, though library maintainers benefit from adding it to their test matrix already.

When does Node 22 reach EOL?

April 30, 2027. It's currently in the Maintenance LTS phase (since October 21, 2025) and only receives critical bug fixes and security updates.

When will Node 26 become LTS?

It moves to Active LTS on October 28, 2026. As of 2026-09-23 it's in the Current phase, with the latest patch being v26.10.0.

Why do native modules break on a Node version upgrade?

Every major Node version can change the V8/N-API ABI (NODE_MODULE_VERSION). .node files compiled against the old ABI segfault on the new version due to struct offset/symbol mismatches, or get rejected by Node's own version check; the fix is a clean rebuild with npm rebuild.

Does it make sense to jump directly from Node 24 to Node 26?

Not before October 28, 2026 — Node 26 is still in the Current phase and carries no production guarantee. After that date, jumping directly is technically possible if you've rebuilt your native dependencies and passed the OpenSSL/security level tests in staging; the only prerequisite is evaluating the breaking changes of both intermediate versions (24 and 26) together.

Can I use Prisma 8 on Node 22?

It depends on which Node 22 patch you're on. Prisma CLI's engines.node requirement is >=22.18.0 — meaning Prisma 8 installation fails on Node 22 minors before 22.18, but current Node 22 patches (around 22.23.x) already meet this requirement. Confirm with npm view prisma engines.node for your own target version, since Prisma 8 is still shipped with a release-candidate (rc) tag as of the writing date, and the requirement may change.

Conclusion

At its core, the Node.js 22/24/26 decision is a risk-management question: Node 22 is safe but not a future investment, Node 24 is the right production default for most teams, and Node 26 should stay in test/trial environments until October 28, 2026. The real risk isn't the version number — it's the OpenSSL security level change and the ABI compatibility of your native dependencies — so planning your upgrade order by native dependency density is safer than by version number.

To approach the rest of the Node.js ecosystem's runtime and tooling transitions with the same discipline, I recommend Next.js 16.3's removal of runtime='edge' and its return to Node, the removal of the Rust engine in the Prisma 6-to-7 migration, TypeScript 7's decision to move to a Go compiler, the Next.js 16.3 Instant Navigations and Cache Components guide, and setting up serverless production with Hono.js — all decisions affecting your stack in this same September-October 2026 window.

Sources

• nodejs/Release official release schedule — the primary source for Active LTS, Maintenance, and EOL dates for Node 22/24/26.
• endoflife.date/nodejs — a secondary compilation confirming LTS transition dates and current patch numbers.
• Node.js v22-to-v24 migration guide (official) — breaking changes in OpenSSL 3.5, V8 13.6, and compiler requirements.
• Node.js v24.0.0 release notes (official) — removal of MSVC support on Windows and ClangCL becoming mandatory.
• Node.js v26.0.0 release notes (official) — removal of writeHeader(), legacy stream modules, the Temporal API, and the V8 version.
• Node.js deprecations document (official) — End-of-Life versions for the DEP0063 and DEP0193 entries.
• nodejs.org/dist/index.json — current Node 26.x patch number and ABI module version.
• Evolving the Node.js release schedule (official announcement) — the plan to move to a yearly single-major LTS model.
• npm registry: next@latest, prisma@latest, @sentry/nextjs@latest — engines.node minimum version requirements.