A Node.js upgrade looks quiet until a dependency calls an API that the new runtime has removed. Version 26, which entered long-term support in October 2026, is one of those releases. It turns on a better way to handle dates, refreshes the JavaScript engine and the HTTP client, and deletes some older surfaces. UK teams running production services on Node should treat it as a planned change, not a version bump in a Dockerfile.
The release has been available since May. Long-term support is the moment many firms allow it onto production. That is the right moment to have already run the application, the native modules and the build in a staging environment that matches the real one.
What shipped on 5 May 2026
Node.js 26 was released on 5 May 2026. It enables the Temporal API by default, updates the V8 JavaScript engine to 14.6, and upgrades Undici, Node's HTTP client, to version 8. The release also removes or deprecates older APIs. Node's release history is the place to confirm which lines are still supported, and the note on the release schedule explains how the project expects teams to move between versions.
Node.js said version 26 would enter long-term support in October 2026. For a UK business, LTS is the sensible production track, because it is the line that receives fixes for longer. It is not a promise that application code written for Node 20 or 22 will run unchanged. The release notes are the compatibility list. A changelog skimmed for the word "feature" and not for "removed" is how upgrades surprise people on a Friday deploy.
Temporal is a clearer way to talk about time
Temporal is a modern set of date and time APIs, meant as a more robust alternative to JavaScript's Date object. Date handling is awkward because applications mix time zones, calendar dates, durations and exact timestamps, and Date makes those easy to confuse. Temporal offers dedicated types for those ideas, so the code can say which one it means.
Enabling Temporal by default does not rewrite existing Date calls. It makes the new API available without a flag, which is the point at which teams can start using it in new code. A booking time, a published-on date and a "this offer lasts three days" duration are different types of fact. UK services that show times to customers, especially across British Summer Time, already know how a single Date object can slip. Moving new code to Temporal is a good use of the upgrade. Rewriting every old call in the same release is not required, and it is a larger change than the runtime bump.
Removals are the part that breaks the build
Node.js 26 removes http.Server.prototype.writeHeader() and several legacy stream modules, among other deprecations and removals. An application that still calls writeHeader, or a dependency that still imports a legacy stream, will fail when it runs on 26 even if the business logic is fine. The fix might be a small change in your code, or it might be waiting on a library release. Find that out in staging.
- Read the official release notes for removals, not only for the Temporal headline.
- Run the application, its native modules and the production build on Node 26 in staging.
- Check HTTP client behaviour where the app depends on Undici's defaults.
- Search dependencies for removed APIs before you schedule production.
- Roll out in stages if the service is large enough that a full cutover would hide a fault.
A phased rollout makes unexpected behaviour visible before every user hits it. That is ordinary release practice, and a runtime upgrade is a release. GitHub's storage rebuild is a reminder from the same season that development platforms are under more load from automated change. A Node upgrade still wants a human to watch the first production slice.
Use the upgrade to tidy the edges
A planned runtime change is a reasonable time to review date handling, update dependencies, run security checks and add tests around the services that would hurt if they misbehaved. It is a poor time to fold in an unrelated redesign. Keep the upgrade about the runtime, the dependencies it forces, and the tests that prove the important paths. Date bugs and removed APIs are enough scope for one release.
Teams that skip staging because "it is only Node" are the ones who meet writeHeader in production. The official notes exist so that guesswork is unnecessary. Assume the upgrade is not transparent until the test run says so. Include the build pipeline in that run. A native module that compiles on a developer laptop can still fail in the image you deploy, and a lockfile that resolves differently on Node 26 will not show up in a code review that never installed it.
Upgrade on a timetable you control
Software development for a UK service includes the runtime it runs on, not only the features in the repository. Cloud hosting is where that runtime is actually pinned, built and rolled out. Leaving the version to a default image is how a removal becomes an outage.
Web Works Rise builds with Next.js, React and TypeScript on Node, from a UK-led team in Birmingham and a development hub in Tunisia. If Node 26 is the next production runtime and you want it tested before the cutover, talk to the team about the services, the native modules and the date logic that must keep behaving.