Skip to main content

Node 26 Hits Active LTS on October 28: A Builder Checklist for Git-Push PaaS Teams

11 min readDora NodaDora Noda
Share
On this page

On October 28, 2026 — 32 days from today — two things happen at once. Node.js 26 graduates from Current to Active LTS, and the decade-old release model that produced it shuts down for good: the same day, the Node 27 alpha channel opens under a new one-major-per-year cadence in which every release becomes LTS. If you operate a git-push PaaS, the builder images you ship, the default runtime you resolve, and the package managers you bundle all have a dated, non-negotiable appointment with that calendar.

This post is the pre-flight checklist for that appointment: the exact dates, what actually breaks tenant builds on Node 26, the packaging fallout (Yarn v1 and Corepack are gone from the images), and what the new annual cadence means for your version policy. Nothing here requires a rewrite — but every item requires a decision before October 28.

The dates that matter​

All dates below are from the Node.js Release working group's schedule, which is the only authority a builder should track:

Release lineStatus on Oct 28, 2026Key dateEnd of life
Node 26Active LTS (from Current)LTS starts Oct 28, 2026Apr 30, 2029
Node 24 (Krypton)Maintenance (critical/security fixes only)Maintenance starts Oct 20, 2026Apr 30, 2028
Node 22 (Jod)MaintenanceAlready in maintenanceApr 30, 2027
Node 25End of lifeEOL was Jun 1, 2026—
Node 20End of lifeEOL was Apr 30, 2026—
Node 27 alphaOpensOct 28, 2026 (same day 26 goes LTS)—

Two details deserve emphasis because builders get them wrong. First, Node 24 enters maintenance on October 20 — eight days before Node 26 becomes LTS — so there is a one-week window where the newest Active LTS is still 24 while 26 sits in Current. If your default-version logic keys off "latest Active LTS," it flips on the 28th, not the 20th. Second, Node 25 went EOL on June 1, 2026 (its last release, 25.9.0, shipped April 1): any tenant still pinned to 25.x is already running an unpatched runtime, and Heroku's buildpack started flagging 25.x deploys as EOL months ago.

Why the LTS date — not the May release date — is the deadline​

Node 26.0.0 shipped on May 5, 2026. A builder that tracks release dates would have considered 26 "available" for nearly six months by the time it matters. But the ecosystem does not move on release day; it moves on LTS day, and three data points prove it.

First, Heroku's Node.js support policy explicitly follows the Node.js release schedule: Current lines are installable, but the supported production story keys off LTS. Heroku derives its default Node version from version metadata rather than hardcoding it, and it warns on deploys using EOL runtimes. That is the correct shape for any builder: resolve versions from upstream data, and treat LTS transitions as the events that move defaults.

Second, Cypress pins its Docker images' primary Node version to the Active LTS line. Its Yarn-removal tracking issue states the transition to Node 26 as primary happens in October 2026 — at LTS promotion, not at the May release. When the ecosystem's biggest test-image publisher moves on LTS day, tenant CI matrices move with it, and tenant apps that build on your PaaS inherit whatever your default resolves on that date.

Third, LTS promotion is when conservative tenants unpin. Teams that held engines at 24.x "until 26 is LTS" will bump within weeks of October 28. Your builder will see a surge of first-time 26 builds in November — including builds whose dependencies were last tested against Node 24 or even 22. The breakage list in the next section is what those builds will hit.

What actually breaks tenant builds on Node 26​

Marco Orta's LTS upgrade guide (September 2026) sorts the 24-to-26 breakage by impact, and the list is short: checklist work, not refactoring work. From a builder operator's perspective, each item has an observable build- or boot-time symptom:

  1. Removed _stream_* internals. The private modules _stream_readable, _stream_writable, _stream_duplex, _stream_transform, _stream_passthrough, and _stream_wrap — deprecated since Node 12 — are gone. require('_stream_readable') now throws MODULE_NOT_FOUND. Your tenants' code rarely touches these; their old transitive dependencies do. Symptom: a boot-time crash in a dependency that hasn't been updated in years, on an app that "changed nothing."

  2. Undici 8 strictness. The global fetch now validates headers strictly and handles redirects differently. Dynamically built header values containing characters like stray newlines — passed silently by Undici 7 — now throw TypeError before the request leaves. Symptom: runtime errors in apps that assemble auth headers or proxy upstream responses at request time.

  3. Native addon ABI bump (NODE_MODULE_VERSION 147). Every compiled addon — bcrypt, sharp, better-sqlite3, canvas, isolated-vm — needs a rebuild or a fresh prebuild. One project already hit this in the wild: isolated-vm 6.x has no Node 26 prebuild and fails to compile against Node 26's V8, requiring a major bump to 7.x. Symptom: was compiled against a different Node.js version at boot, or a failed node-gyp rebuild at build time if the builder image lacks a toolchain.

  4. module.register() runtime-deprecated. The async module-hooks API used by instrumentation loaders, transpilers, and APM agents now warns at runtime; the replacement is the synchronous module.registerHooks(). Symptom: deprecation warnings in tenant logs from observability agents — noisy but non-fatal, and worth a tenant advisory rather than a builder change.

  5. writeHeader() removed from the HTTP server. The long-deprecated alias is gone; writeHead() remains. Symptom: TypeError at boot in very old frameworks or vendored HTTP helpers.

  6. Extensionless require in ESM packages removed. A historical resolver exception that let "type": "module" packages require a CommonJS file without an extension is gone. Symptom: resolution failures in mixed-module packages that never added explicit .cjs/.js extensions.

Two things explicitly do not break, and your tenant advisory should say so: the Temporal API ships enabled by default but coexists with Date (migration is optional and gradual), and running TypeScript directly (node app.ts with no flags) is now stable — the only casualty is the --experimental-transform-types flag itself, which was removed because the feature graduated. Tenants with that flag in an npm script just delete it.

The highest-leverage builder action here is the one Cypress modeled: open Node 26 compatibility testing early, months before LTS, against the Current line. If your builder maintains a corpus of representative tenant apps (a Next.js app, an Express API with bcrypt, a worker with sharp), run it against Node 26 now and record which of the six items fires. That corpus is also your regression suite for every future LTS flip.

The packaging fallout: Yarn v1 and Corepack are gone​

The subtler breakage is not in Node's API surface but in what ships around it. Two removals land on builder images at once:

Yarn v1 Classic is no longer bundled as of Node 26.0.0. The official node images state it plainly: Yarn v1 ships only in image variants for Node 25 and below, because upstream Yarn v1 is frozen and unmaintained. Cypress is following the same line: its images drop Yarn v1 for NODE_VERSION >= 26, deprecate the YARN_VERSION escape hatch below 26, and disallow it at 26 and above.

If your builder derives from the official node images — or mirrors their package set — any tenant build that runs yarn install expecting a preinstalled Yarn v1 will fail on Node 26 with yarn: command not found. The fix is a builder decision, not a tenant decision: either install Yarn v1 explicitly in your Node 26 builder images (pinning 1.22.22, the final release), or detect yarn.lock and install it on demand. Doing neither converts a packaging change into a tenant-facing outage on the first November deploy.

Corepack is no longer distributed, starting with Node 25. The Technical Steering Committee voted to stop bundling Corepack (it stays maintained as a regular npm package: npm install -g corepack). Heroku's buildpack stopped using Corepack to install pnpm and Yarn back in January 2026 while keeping support for the packageManager field in package.json. Node 26 images ship without Corepack entirely.

For a builder, the Corepack removal means the packageManager-field flow you may have gotten for free now needs an explicit install step: npm install -g corepack && corepack enable, or direct installation of the declared manager. Heroku's approach — honor packageManager, but provision the manager yourself instead of via Corepack — is the pattern to copy.

Note what these two removals share: both push package-manager provisioning from the base image into the builder's explicit logic. A builder that treated "yarn works" and "corepack works" as ambient properties of a Node image must now treat both as features it owns, tests, and documents.

Node 26 is the last train on the old schedule​

The official announcement frames the cadence change clearly: starting with Node 27, the project ships one major per year in April, and every release becomes LTS that October after a six-month Current phase (preceded by a six-month alpha channel). The odd/even distinction — odd lines dying young, even lines living 30 months — disappears.

For builder version policy, three consequences follow:

  • The "skip odd lines" heuristic dies with Node 26. Any builder logic that refuses odd majors, or that assumes even majors are the only LTS candidates, needs revisiting before Node 27 ships in April 2027. Under the new model there are no short-lived lines to skip.
  • The alpha channel is the new early-testing input. The Node 27 alpha opens October 28, 2026 — the same day 26 goes LTS. A builder that runs its representative-app corpus against the alpha gets a full year of warning before the next LTS, instead of the six months the Current line historically provided.
  • Total support stays 30 months per line. The LTS window tenants rely on does not shrink; only the release half of the cycle changes. Tenant advisories should lead with that sentence, because "one release a year" reads to some teams as "slower security fixes." It is not.

Node 26 itself gets the full old-model LTS treatment — Active until October 20, 2027, maintenance through April 30, 2029 — so promoting it to your default is a 30-month commitment with a well-understood tail, including a comfortable overlap with Node 24 (EOL April 2028) for slow-moving tenants.

The builder checklist​

Concretely, before October 28:

  1. Add Node 26 to your builder's test matrix now, against the Current line — the Cypress playbook. Include at least one native-addon app (sharp or bcrypt) to smoke out ABI-147 rebuild behavior and toolchain gaps in your build image.
  2. Decide the default-flip date and mechanism. Either flip the default to 26 on October 28 (keying off Active LTS, like Cypress's primary images) or stage it: opt-in via version pin immediately, default flip a few weeks later. Either way, key the logic off upstream schedule data, not a hardcoded version — Heroku's nodejs-data-derived default is the model.
  3. Start warning on EOL runtimes. Node 25 (EOL June 1) and Node 20 (EOL April 30) deploys should warn today; Node 22 should get a "maintenance ends April 2027" advisory. Warnings are cheap; silent EOL builds are how tenants find out from a CVE.
  4. Provision Yarn v1 explicitly in Node 26 builder images (or install on demand when yarn.lock is present). Verify yarn --version works in the image; "it worked on 24" is not evidence.
  5. Provision the packageManager flow without Corepack. Either npm install -g corepack in the image or resolve pnpm/Yarn versions yourself. Test with a pnpm-based and a Yarn Berry-based fixture app.
  6. Publish a tenant advisory covering the six breakages, the two non-breakages (Temporal, type stripping), and the Yarn/Corepack provisioning change. Link the LTS upgrade guide and the release schedule so tenants can self-serve.
  7. Update version-policy code for the annual cadence. Find every place your builder assumes even-means-LTS or skips odd majors, and schedule its removal before Node 27 ships in April 2027. Subscribe your representative-app corpus to the Node 27 alpha channel when it opens on October 28.

None of these is hard. All of them are time-boxed: the tenants who unpin in November will judge your builder by whether their first Node 26 deploy just works.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex