Node Is Retiring Odd and Even, and the Rule You Use to Pick a Version Expires This Month

The Node.js release schedule changes this month, and the change quietly invalidates the heuristic almost every agency uses to choose a runtime. "Use the even-numbered version in production" has been correct for eleven years. It stops being a safe rule on October 28, 2026.

Two things happen in the same eight days. Node 24 leaves Active LTS on October 20. Node 26 is promoted into it on October 28. In between, and this is not a typo, no Node version is in Active LTS at all.

We wrote about what is shipping in PHP 8.6 in August. This is the other runtime under most of our build pipelines, and its change is structural rather than a feature list.

Two October dates, and eight days with no Active LTS

From Node’s own schedule.json, which is the project’s machine readable source of truth:

• Node 24 (Krypton) entered Active LTS on 2025-10-28 and drops to Maintenance on 2026-10-20.
• Node 26 shipped as Current on 2026-05-05 and becomes Active LTS on 2026-10-28.

Between October 20 and October 28 there is a gap. Node 24 is in Maintenance and Node 26 has not been promoted. If you have a client contract, a security questionnaire or an internal policy that says "runs on an Active LTS release of Node," there are eight days in October where the honest answer is that nothing qualifies, and after October 28 the answer becomes Node 26.

That is a small thing and it is the kind of small thing that produces an awkward email during a procurement review.

What the new node.js release schedule actually says

Node published Evolving the Node.js Release Schedule on March 10, 2026. The changes are introduced under the heading "As of October 2026." Four parts, quoted:

• "One major release per year (April), with LTS promotion in October."
• "Every release becomes LTS. No more odd/even distinction – Node.js 27 will become LTS."
• "Version numbers align with the calendar year of their initial Current release: 27.0.0 in 2027, 28.0.0 in 2028."
• A new alpha phase: "Alpha | 6 months | Oct to Mar. Early testing, semver-major allowed."

The full lifecycle becomes Alpha for six months from October, Current for six months from April, LTS for thirty months, then end of life, for a total of thirty six months of support from the first Current release.

The stated reason for dropping odd and even is blunt: "Odd-numbered releases see minimal adoption" and "the odd/even distinction confuses newcomers."

Node 27 is the first release under the new model. Its alpha begins October 28, 2026. 27.0.0 ships in April 2027, enters LTS in October 2027, and reaches end of life in April 2030. Node 26 is the last release line under the old model. There is no odd release in October 2026; Node 25 was the last of those and it reached end of life on June 1, 2026.

The blog post also carries its own hedge: "This schedule is not final and may be amended." The out-years are a plan. The October 2026 dates are in schedule.json.

The even-number rule has a precise expiry date

Worth being exact, because the rule does not fail all at once.

It is still correct today. Node 26 is even and becomes LTS on October 28, exactly as the heuristic predicts. Following it right now gives the right answer.

It becomes misleading on October 28, 2026, when 27.0.0-alpha.1 appears. An odd numbered Node will exist that is not a short lived throwaway. It is the next LTS, in its early testing phase. Anyone applying "odd equals skip, do not test" will skip the channel that has replaced odd releases as the compatibility testing vehicle. The Release team is explicit that this is the failure mode they are worried about: "Library authors: Please integrate Alpha releases to your CI as early as possible; if you only test on LTS releases, you will not be able to report bugs before they affect your users."

It becomes flatly wrong in April 2027, when 27.0.0 ships as a Current release destined for LTS.

The replacement mental model is simpler than the one it replaces: one release per year in April, and it is production ready when it enters LTS the following October. Alphas are explicitly "not intended for production use."

How much of this is actually new

Worth doing the arithmetic, because most coverage is treating this as a wholesale change and the support numbers do not move.

Under the old model, Node 24 went Current on May 6, 2025 and reaches end of life on April 30, 2028. That is thirty six months, of which thirty are LTS. Under the new model, Node 27 goes Current in April 2027 and reaches end of life on April 30, 2030. Thirty six months, of which thirty are LTS. The blog states it plainly: "Total support: 36 months from first Current release."

Cadence does not move either. You got one production bound release every twelve months before, in April. You get one production bound release every twelve months now, in April.

So what actually changes is the six month slot in between. It used to be filled by an odd numbered release: a real, installable, supported-for-a-while version that some people ran in production even though the project wished they would not. It is now filled by an alpha that Node says outright is "not intended for production use."

That is the substantive delta, and it moves responsibility. The odd release was a compatibility testing vehicle that tested itself, because enough people used it to surface problems. An alpha only works if maintainers deliberately run it. Hence the Release team’s direct ask to library authors, and hence the risk: if the ecosystem treats the alpha the way it treated odd releases, which was mostly to ignore them, the April majors will arrive less tested than the ones they replace.

The version renumbering is cosmetic. The testing model is not.

Node 26 will break your native modules

This is the part that will cost someone a day, and it has nothing to do with the schedule change. Node 26 becomes the LTS target on October 28, and it is a semver-major release.

NODE_MODULE_VERSION moves from 144 to 147. Every native addon has to be recompiled or have a prebuilt binary published for 147. In a WordPress or Sage front-end build that means sharp and sass-embedded first, and in wider Node work better-sqlite3, canvas, bcrypt and puppeteer are the usual suspects. Any Docker layer caching prebuilt binaries needs invalidating.

The legacy stream modules are fully removed: _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform and _stream_passthrough. Gulp-era plugins and their transitive dependencies still reach for these. They now throw rather than warn.

module.register() is runtime deprecated. That is the ESM loader hooks registration API, used by ts-node, tsx and several instrumentation and APM tools. Expect deprecation warnings filling CI logs before anything actually breaks.

--experimental-transform-types is removed. Any script or CI step still passing that flag fails to start outright, which at least fails loudly.

http.Server.prototype.writeHeader() is removed in favor of writeHead(), which reaches old Express-era middleware and hand-rolled mock servers.

And if you build Node or native modules from source in a custom CI image, the floor moved: GCC 13.2 minimum, Python 3.10 minimum for node-gyp, and Windows SDK 11 required. Older Debian and CentOS based build containers will stop working.

On the other side of the ledger, Node 26 enables the Temporal API by default and ships V8 14.6, so Iterator.concat() and Map.prototype.getOrInsert() are available.

The Docker tags nobody has decided yet

This is the least settled area and the one worth pinning around rather than through.

FROM node:24-alpine is unaffected by anything here. What is undecided is what the floating tags will mean. The nodejs/docker-node project has two open issues, #2389 and #2524, with no decision recorded. The open questions in their own words include whether "Alpha releases are to be packaged as Node.js Docker images or not," what prerelease tags would be named, and whether "lts, current, latest will change meaning under the new schedule."

node:current is the genuinely risky one. Today it means 26. From April 2027 there is a six month window each year where "current" is ambiguous with an in-flight alpha.

Pin to an explicit major in Dockerfiles until docker-node publishes a policy. Same reasoning for .nvmrc: a file containing lts/* flips from 24 to 26 on October 28, 2026, which is a real dated behavior change for anyone using floating aliases.

For package.json, ranges written as >=20 or ^22 || ^24 encode the even-number assumption. Bounded ranges per supported line age better. WordPress Core’s own .nvmrc currently pins 24.18, and Gutenberg has moved to devEngines.packageManager in package.json as the single source of truth for the npm version CI installs, which is a pattern worth copying.

Where the managed platforms actually are

We checked the platforms our readers actually deploy to. The summary is that every one of them is still organized around the old model.

• AWS Lambda: nodejs26.x exists but is public preview only and, in Amazon’s words, "should not be used for production workloads." nodejs24.x and nodejs22.x are the production choices. nodejs20.x is already deprecated.
• Vercel: 24.x is the default, with 22.x and 20.x available. Node 20 is being deprecated on October 1, 2026.
• Netlify: Node 24 has been the default since July 7, 2026, for new sites only. Existing sites keep whatever they are pinned to. NODE_VERSION, .nvmrc and .node-version all override the UI setting.
• Cloudflare Workers: a different model entirely. Workers does not expose Node major versions, and as of August 4, 2026 the nodejs_compat and nodejs_compat_v2 flags are enabled by default for compatibility dates of 2026-08-04 or later. The LTS and EOL question does not map onto it.
• WP Engine Atlas: publishes a per-version table listing 26 as Current, and defaults to the Active LTS when package.json does not specify. It recommends bounded ranges such as ">=24.0.0 <25.0.0".
• Pantheon: its June 2026 release note says Node 26 is available as an LTS runtime for Next.js sites and that Node 20 has been removed, selected through engines.node. Its Requirements and Considerations page still says Front-End Sites "can run v16, v18, or v20." The two pages contradict each other and we could not determine which is authoritative. Ask support before planning around either.

No platform has published guidance on the annual model or the alpha channel. Not one. Expect vendor documentation to lag well into 2027, which means the version tables you are reading on their docs sites will keep implying an even-number rule that Node has already retired.

Node 20 is already dead and is still in your Dockerfile

While we are here, the most urgent Node fact on this page has nothing to do with the new schedule.

Node 20 reached end of life on April 30, 2026. That was five months ago. It receives no security patches. It is also, in our experience, the single most common value still sitting in agency .nvmrc files, Dockerfiles and CI matrices, because it was the safe default for two years and nothing forces a change.

Only three Node lines are supported right now: 22 in Maintenance, 24 in Active LTS, and 26 as Current. Node 25 also went end of life, on June 1, 2026.

A CI matrix written as [20, 22, 24] is testing a runtime with no security support. It should read [22, 24, 26].

What to change

This week: grep your repositories for 20 in .nvmrc, .node-version, engines fields, Dockerfiles and CI configs. That is an EOL runtime, and it is a bigger problem than anything the schedule change causes. It is also the same class of exposure as an unpatched CI pipeline: nothing visibly fails, so nothing prompts a fix.

Before October 20: if any client agreement or security questionnaire says "Active LTS," know that the answer is Node 24 until October 20, nothing between the 20th and the 28th, and Node 26 after that.

Before October 28: decide what your floating tags should do. .nvmrc files containing lts/* will move to 26 on their own. Dockerfiles using node:current or node:lts should be pinned to an explicit major until the Docker image project publishes a tag policy.

When you move to Node 26: budget for native module rebuilds first. NODE_MODULE_VERSION 147 is the item most likely to break a build, and it breaks it in a way that looks like a dependency problem rather than a runtime problem.

If you publish libraries: add the Node 27 alpha to your CI matrix as an allowed-to-fail leg from October 28. That is the explicit ask from the Release team, and the alpha channel only works as a safety net if people actually run it.

The rule that is going away was never written down anywhere official. It was folklore that happened to be true for eleven years. What replaces it is simpler and, for once, actually documented.

Frequently Asked Questions