- Vercel says Node.js 26 LTS is generally available. Existing projects whose engines.node setting allows 26, such as >=20, will build on it at their next deployment.
- Vercel makes HTTP/2 the default for built-in fetch in Functions and says it can reduce latency. Setting VERCEL_FETCH_DISABLE_H2 to 1 keeps HTTP/1.1.
- Teams can set engines.node to 26.x, and should review version ranges and outbound HTTP calls. A project pinned to 26.x still receives minor and patch updates.
A version range is a scheduling decision
A version range in a settings file looks like a note about compatibility. On Vercel, it can also set the date your runtime changes. That is worth understanding before the next routine deploy.
Vercel announced on October 29 that Node.js 26 LTS is generally available for builds and Vercel Functions. It is the default for all new projects. Existing projects can move as well, depending on one setting.
How the setting works
Every Node.js project can state which versions it accepts in a field called engines.node, inside its package.json file. Vercel says that if the field allows 26, builds will use Node.js 26 at the next deployment. Its example of such a setting is >=20.
Take a developer who wrote >=20. The likely intent was "20 or newer is fine." That is the author's reading, not something Vercel states. The range says nothing about when to adopt a new major version. Under this rollout, any project whose range allows 26 will build on it at its next deployment.
The lesson here is that a loose range hands the timing to the platform. The change may be harmless. But a team that did not choose the date may not have tested for it.
What is new in Node.js 26
Vercel lists three headline changes.
The first is HTTP/2 as the default for the built-in fetch call, which now runs on Undici 8. Fetch is how a function requests data from another service. Vercel says built-in fetch calls can now share a connection with servers that support HTTP/2. It adds that this can reduce latency when functions call APIs or databases over HTTP.
That is a vendor statement of what can happen. The announcement gives no benchmark figures and no count of affected projects.
The second is the Temporal API, which Vercel presents as an alternative to the Date object for working with dates and times in JavaScript. Vercel says its values cannot be altered after creation, and that time zones and calendars are built in. That matters where invoices, bookings or deadlines cross regions.
The third is a newer V8, the engine that runs JavaScript, at version 14.6. One feature Vercel names is Map.prototype.getOrInsert(), a shortcut that returns a stored entry or adds a default. These are conveniences for developers, not reasons to hurry.
Why HTTP/2 deserves a closer look
The following is general background, not a Vercel finding. Vercel reports no problems with this change.
Under HTTP/1.1, a busy function often opens several connections to the same service. Under HTTP/2, many requests travel over one connection. A team might therefore see fewer open connections on the service being called. It might also see different latency patterns, because requests no longer queue on separate connections.
Anything sitting between the function and the service could behave differently as well. A load balancer or proxy may treat one long-lived connection differently from many short ones. Timeouts and limits on simultaneous requests are examples worth checking.
This only applies to built-in fetch calls to servers that support HTTP/2. Other HTTP clients in your code are not mentioned in Vercel's notes. A transport change like this is the kind of thing teams should watch for in monitoring, since it may not show up as a failed test.
Staying in control
Vercel documents the options. To move on your own schedule, set engines.node to 26.x in package.json and redeploy. To keep HTTP/1.1 in Functions, give the environment variable VERCEL_FETCH_DISABLE_H2 the value 1 and redeploy.
If you ship prebuilt output yourself, your Vercel CLI must be version 65.8.0 or newer to deploy Node.js 26 Functions.
One planning point is easy to miss. Pinning to 26.x fixes the major version, not the minor or patch. According to the changelog, Vercel applies later Node.js 26 minor and patch releases to builds and Functions without any action from you.
Questions to put to your team
First, which of our projects declare a range like >=20, and who decided that was acceptable? Second, which services do our functions call with built-in fetch, and have we checked how they behave over HTTP/2? Third, is any date logic, such as money, scheduling or compliance dates, a candidate for Temporal, and is it tested on Node.js 26? Fourth, who owns the choice between taking the default and setting VERCEL_FETCH_DISABLE_H2 to 1?
None of this argues against upgrading. It argues for choosing the day. A runtime change you scheduled is routine maintenance. One that arrived with an unrelated deploy is something you must explain afterwards.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Vercel.
Follow this story: every update on Node.js security releases
