Node.js 26 LTS Is Here: Why engines.node ">=20" Changes Your Runtime Without Asking

On 28 October 2026 the Node.js project moved Node.js 26 into Long Term Support. Its release index marks v26.13.0 as the first LTS release of the line, codename Lithium. A day later Vercel announced: "Node.js 26 LTS is now Generally Available for builds and Vercel Functions." The announcement includes this:

"If engines.node in your existing project’s package.json allows 26, such as >=20, your Node.js builds on Vercel will use 26 on the next deployment."

That sentence is worth reading slowly, whether or not you host on Vercel. A range like ">=20" looks like a floor, a promise that you need at least Node 20. Read by a platform that picks the newest version your range allows, it is something else: a standing instruction to move to every new major version as soon as one is offered. Your next deploy changes runtimes even though nobody asked it to.

What a range actually allows

We checked how common engines.node values treat a Node 26 release, using the same semver library npm uses, on 30 October 2026 with v26.13.0:

Anything with an open top end allows the next major version. Anything that names the major, such as 22.x, ^22 or a bounded range, does not. Vercel's own instruction for upgrading on purpose uses the second form: "Set engines.node to 26.x in your project's package.json and redeploy."

Why an unrequested major version is a problem

A new Node major is not just a bigger number. Vercel's release note for this one lists, among other changes, "HTTP/2 by default for built-in fetch" through Undici 8, the Temporal API, and V8 14.6. HTTP/2 for fetch is a good change for most apps, but it is still a change in how every outbound request from your code is made. Vercel also documents an opt-out for exactly this reason: "To keep HTTP/1.1, set the VERCEL_FETCH_DISABLE_H2 environment variable to 1 and redeploy."

The bigger problem is attribution. When the runtime changes as a side effect of a deploy, that deploy also carries whatever code change was in it that day. If something breaks, the obvious suspect is the code change. The runtime upgrade is the change nobody made on purpose, so it is the last place anyone looks.

Once you are on a major line, minor and patch updates are a separate question. Vercel says: "Minor and patch updates to Node.js 26 roll out automatically for builds and Vercel Functions." That is normal for a managed platform and usually what you want, since patch releases carry security fixes. The decision worth keeping in your own hands is the major version.

npm will not stop it for you

It is easy to assume engines is enforced. By default it is not. We installed a package declaring "engines": { "node": "22.x" } on Node v26.13.0. npm printed an EBADENGINE warning and installed anyway, with exit code 0. The same happened when that package was installed as a dependency of another project.

Adding one line to .npmrc turns the warning into a failure:

engine-strict=true

With that set, the same install stopped with npm error engine Unsupported engine and exit code 1. That makes a wrong runtime fail the install instead of slipping through it.

What to do

1. Name the major in engines.node. Use "22.x" (or "26.x" once you have tested it), not ">=20". Patch and minor updates still arrive. Major versions only arrive when you change the line.
2. Make the declaration enforceable. Add engine-strict=true to .npmrc, so an install on the wrong major fails in CI rather than warning into a log nobody reads.
3. Log the runtime at startup, and refuse the wrong major if you want a hard stop. We tested this on Node 22 and 26. It starts on 22 and exits with code 1 on 26:

   const expected = 22;
   const major = Number(process.versions.node.split(".")[0]);
   console.log(`Starting on Node.js ${process.version}`);
   if (major !== expected) {
     console.error(`Expected Node.js ${expected}.x, got ${process.version}. Refusing to start.`);
     process.exit(1);
   }

   Even the logging line alone answers the question you will otherwise ask during an incident: which deploy changed the runtime?
4. Upgrade the major in its own deploy. Change engines.node and nothing else, deploy, and watch. If something regresses, you know exactly what moved.

There is no deadline forcing this today. Vercel's announcement says nothing about ending support for older versions. On the Node.js project's own schedule, Node 22 is in maintenance until 30 April 2027, and Node 24 until 30 April 2028. Pinning 22.x is a safe holding position while you test 26 on purpose.

If the runtime in your container image is the part you are unsure about, our October Node.js security release post covers checking what version an image actually runs and rebuilding it.

Sources: Vercel changelog, "Node.js 26 LTS is now Generally Available on Vercel", published 29 October 2026; Node.js release index and Node.js release schedule. All read 30 October 2026. Range and npm results are from our own tests on 30 October 2026 with node:26-alpine (v26.13.0, npm 11.20.0).