Node.js is going annual. Plan your upgrades now

Node.js is changing how it ships major versions, and the mental model every backend team has used for a decade is going away. Starting with version 27, the project moves from two major releases a year to one. The odd-versus-even rule, where odd-numbered releases were short-lived and even-numbered ones became long-term support, is being retired. Every annual release will now become LTS.

The new cadence is simple. One major lands each April, with LTS promotion the following October. Version numbers line up with the calendar year of a release's first Current phase, so 27.0.0 arrives in April 2027, 28.0.0 in 2028, and so on. There's also a new six-month Alpha channel, running October to March, where breaking (semver-major) changes are allowed and the release team runs popular packages' test suites against the upcoming version through CITGM. Node.js 26, the line that shipped this May, is the last one under the old model. Node 27's Alpha opens this October.

So what does this actually mean if you ship Node in production? Less than the headline suggests, and that's the point.

If your team already pins to LTS and ignores the Current line, almost nothing changes except the version math. You still upgrade roughly every two years, and you still get about 30 months of support per line. We've run plenty of long-lived enterprise projects this way, the Swiss compliance work in particular, where "boring and predictable" is a feature, not a complaint. Killing the odd/even rule mostly kills a piece of folklore that new hires always tripped over.

The real shift is the Alpha channel, and it's aimed at a group most teams forget they belong to: anyone who maintains a library, an SDK, or a shared internal package. For years the odd-numbered releases were where breakage surfaced first, and almost nobody tested against them. Now there's an explicit six-month window, October to March, to catch a breaking change before it reaches the LTS your clients depend on. From our PHP and Docker work, we've watched the same movie in other ecosystems: the breakage is rarely in the framework itself, it's in some transitive dependency nobody ran against the beta. An annual Alpha channel is the project handing you a fixed date to find that out.

Here's the actionable part. Add a Node Alpha job to your CI now, before October, even if it's allowed to fail. A single matrix entry that runs your test suite against the latest Node Alpha and reports without blocking the build. It costs you one extra job, and it turns "our app broke on the new Node" into a ticket you file in November instead of a fire you fight the following spring. If you publish packages, this isn't a nice-to-have. It's how you avoid being the dependency that breaks everyone else.

A word on the upgrade reflex this encourages. A predictable annual major is good, but "predictable" can lull teams into autopilot. We see this in mobile too. In our native iOS and Android projects, a yearly OS release trains teams to expect a smooth bump, right up until the year it isn't. Treat each Node major as a real migration with its own test pass, not a rubber stamp. The Alpha window exists precisely so the April release can be boring.

There's a security angle worth naming. Clearer support timelines mean fewer teams accidentally running an end-of-life runtime because they lost track of which line was "even" and which was a dead end. During our pentesting engagements, an out-of-support Node version is one of the more common findings, usually an old service nobody owns anymore. Every line becoming LTS, with a clean 30-month clock, turns "are we on a supported runtime?" into a yes/no question instead of a flowchart. Put that EOL date in your dependency tracker today.

The thing I keep coming back to: this is Node admitting that most teams never used the release cadence the way it was designed. One major a year, every one supported, breakage caught early through Alpha. It's less clever and more honest, and after years of explaining odd/even to clients, I'll take honest.

If keeping a fleet of Node services on supported, well-tested runtime versions sounds familiar, let's talk.