Node.js LTS for Every Major Version: Why Stability Wins

The most important Node.js announcement of 2026 has no benchmark chart attached to it. In March, the project confirmed that starting with Node.js 27, every major version will get Long Term Support - a scheduling change, not a feature. And in a year when Bun and Deno keep shipping faster runtimes, that boring scheduling change may be the single strongest competitive move any JavaScript runtime made.

Every Node Major Goes LTS: The March 2026 Schedule Change

Node.js is abandoning its decade-old "odd releases die young" model. Beginning with Node.js 27, every major version will transition to LTS after its Current phase, retaining roughly 30 months of support, according to the official release schedule evolution announcement. The stated reason is blunt: odd-numbered releases saw low adoption because organizations simply waited for LTS. The dual-track experiment worked as a rehearsal ground - Temporal, V8 upgrades, Undici updates, and API removals all got exercised on the Current line before touching production users - but the "throwaway" odd majors created a version nobody actually deployed.

The current lineup as of July 2026, per the official Node.js releases page:

Why it matters: Node just told every platform team on Earth "you can plan your next five years of runtime upgrades on a calendar," and no competing runtime can credibly say the same.

The Numbers Say Boring Wins: 90% vs 21% vs 11%

The runtime wars have a scoreboard, and it's lopsided. The State of JavaScript 2025 survey puts Node.js at roughly 90% of runtime respondents (10,062 of 11,141), with Bun at ~21% and Deno at ~11%. Stack Overflow's 2025 survey shows Node.js leading the entire web-technologies category at 49.1%, ahead of React at 46.9%.

What's often missed: those Bun and Deno numbers skew heavily toward development and tooling use, not production traffic. Bun's growth is real where performance and tooling consolidation matter - test runners, bundling, local dev servers - but enterprises stay cautious about its fast-moving API surface and smaller ecosystem.

The contrarian read: this isn't Node winning on merit alone. It's Node winning on switching costs plus predictability. When your runtime carries a 30-month support contract, "slightly slower than Bun" is a rounding error against "we don't rewrite our runbooks every quarter."

Why it matters: The runtime decision in 2026 is an operational-risk decision, and 90% of the market has already voted on which risk profile they'll accept.

Node 24 Proves Discipline Isn't Stagnation

Node 24 "Krypton" is the first LTS in several cycles where language-level changes reshape everyday code. The headline is await using, explicit resource management that lands cleanup logic directly in the language:

javascriptCopy
// Before: manual cleanup, easy to leak on early return or throw
async function query(pool, sql) {
  const conn = await pool.acquire;
  try {
    return await conn.query(sql);
  } finally {
    await conn.release;
  }
}

// Node 24: the connection disposes itself when scope exits
async function query(pool, sql) {
  await using conn = await pool.acquire;
  return await conn.query(sql);
}

The await using declaration calls the object's [Symbol.asyncDispose] method automatically when the scope exits - including on exceptions and early returns. That try/finally pattern it replaces is exactly where connection leaks come from in real codebases: someone adds a second return path, forgets the finally block covers it, and the pool drains under load three weeks later. Moving disposal into the language removes the class of bug, not just the individual bug.

Node 24 also ships a built-in URLPattern API, which kills off the hand-rolled regex routing that has produced path-traversal and ReDoS bugs in Express and Fastify middleware for years. Add V8 13.6, npm 11, Undici 7, and Permission Model improvements per the Node.js 24.0.0 release notes, and the "conservative" release carries real substance.

Why it matters: Node's features arrive through conservative release gates rather than churn, so your team gets await using and URLPattern with a compatibility contract attached.

TypeScript Type Stripping Went Stable, Quietly Closing the Deno Gap

Node can now run TypeScript files directly. Type stripping - executing .ts files by erasing type annotations without transpilation - became stable in v25.2.0 and v24.12.0, with experimental warnings removed as early as v24.3.0 and v22.18.0, per the official TypeScript documentation.

bashCopy
# No flags, no loaders, no ts-node. Just:
node app.ts

This was Deno's founding pitch and one of Bun's strongest ergonomic arguments. Node absorbed it the Node way: slowly, behind experimental flags, across three major versions, until the semantics were settled. Combined with improved CommonJS/ESM interoperability, the old "Node is annoying to set up" argument is losing its remaining teeth.

Worth noting what type stripping deliberately does not do: type checking. Types are erased, not verified, so you still need tsc --noEmit in CI. If you're evaluating the full toolchain picture, compiler speed matters too - see how TypeScript 7.0's 11.9x compile-time speedup changes build strategy for the other half of that equation.

Why it matters: Every ergonomic advantage Bun and Deno held is being absorbed into Node without breaking a single existing project, which is the whole LTS thesis in miniature.

Security Rigor Is Now Part of the Release Contract

February 2026 brought new security reporting requirements alongside the v24.14 LTS and v25.7.0 releases. Behind that sits a year of structural work documented in the OpenJS Security Annual Report 2025: an OpenJS CVE Numbering Authority, automated Node.js security release workflows, and formal incident-response plans.

The context makes this urgent rather than bureaucratic. A September 2025 npm supply-chain attack hit packages with over 2 billion combined weekly downloads, and the Shai-Hulud campaign compromised 180+ packages with additional waves continuing into 2026. The npm ecosystem is Node's greatest asset and its largest attack surface at the same time. Node's Permission Model - restricting filesystem, network, and child-process access at the runtime level - is the direct technical response, and its continued hardening in Node 24 turns "Deno's security model is better" from a decisive argument into a shrinking one.

Why it matters: Predictable, automated security releases are the difference between "patch Tuesday morning" and "emergency all-hands," and Node now has the institutional machinery for the former.

The Real Threat Is Legacy Node, Not Bun or Deno

Here's the uncomfortable statistic: roughly two-thirds of Node.js users run outdated or unsupported versions, according to the OpenJS Foundation. That finding prompted the launch of the Node.js LTS Upgrade and Modernization Program in March 2026, with NodeSource as the first partner.

The cost of ignoring the cadence isn't abstract. Per the official Node.js EOL page, Node 20 "Iron" already carries 27 high, 24 medium, and 9 low unpatched vulnerabilities post-EOL. Node 18 sits at 15 high, 19 medium, and 4 low. Those numbers only grow, and they come bundled with toolchain breakage and compliance red flags.

This reframes the language wars entirely. Node's stability advantage isn't automatic - it's a contract that only pays out when your team holds up its side by staying on Active or Maintenance LTS. A Node 18 deployment in 2026 has none of the security posture, none of the performance gains, and all of the audit risk.

Why it matters: Node's biggest competitor in 2026 is old Node, and two-thirds of the ecosystem is currently losing to it.

Competitors Are Copying the Playbook, Which Settles the Argument

The strongest evidence that LTS discipline wins isn't Node's market share - it's what the challengers are doing. Deno introduced LTS releases in Deno 2.x specifically for teams needing a stable production base. When your differentiator was "we move fast and fix Node's mistakes" and your roadmap now includes "long-term support windows," the market has spoken about what production buyers actually purchase.

Bun keeps winning the categories where raw speed and tooling consolidation dominate: local development, test execution, CI pipelines. That's a genuinely strong position. But enterprises evaluating Bun for production traffic consistently cite the same hesitations - smaller ecosystem, fast-moving surface area, no equivalent of a 30-month support commitment.

The honest framing for 2026: Bun and Deno are pushing the JavaScript runtime category forward, and Node is absorbing the best ideas at LTS pace. Python grows through AI workloads, Rust and Go pull systems developers, but production JavaScript keeps consolidating on the runtime with compatibility contracts, cloud provider support, npm integration, and hiring familiarity.

Why it matters: When every challenger starts shipping LTS programs, "stability as the killer feature" stops being Node's opinion and becomes the industry's consensus.

Worth Watching

• Node 26 entering LTS in October 2026 - watch whether the new every-major-LTS model accelerates enterprise adoption of even and odd releases alike
• Node.js 27's release under the new schedule - the first major to test the "every version gets 30 months" promise
• Uptake numbers from the LTS Upgrade and Modernization Program - whether the two-thirds-outdated figure actually moves in OpenJS's next report
• Bun's response to the LTS consensus - a Bun LTS announcement would confirm the thesis completely
• Permission Model adoption in production - the next wave of npm supply-chain incidents will test whether runtime sandboxing gets real traction

What To Do Now

Start here (your first step) Run node --version across every production service today. Anything below 22 is your priority; anything on 20 or 18 is an active security liability per the EOL vulnerability counts.

Quick wins (immediate impact)

• Add a CI test matrix covering Node 22, 24, and 26 to your main repositories this week, so the eventual Node 24 cutover is a config change rather than a project
• Enforce lockfiles in CI (npm ci, never npm install) and enable --ignore-scripts for installs where feasible, given the ongoing supply-chain campaigns

Deep dive (for those who want more)

• Pilot Node 24's Permission Model (--permission with explicit --allow-fs-read and --allow-net grants) on one non-critical service and document what breaks
• Refactor one connection-pool or file-handle module to await using with [Symbol.asyncDispose], then measure whether leak-related incidents drop over the following quarter

Useful Resources

• Node.js Release Schedule - Official LTS status and support timelines for every version
• Evolving the Node.js Release Schedule - The March 2026 announcement moving every major to LTS
• Node.js 24.0.0 Release Notes - Full details on V8 13.6, npm 11, Undici 7, and Permission Model changes
• Node.js TypeScript Support - Official documentation on native type stripping
• OpenJS Security Annual Report 2025 - The CNA launch and security release automation work

What This Means For You

The 2026 runtime decision isn't about syntax or benchmarks. It's about which platform lets you schedule risk instead of absorbing it, and Node's answer - annual LTS for every major, 30-month support windows, automated security releases, and features that arrive pre-hardened - is currently the only complete one in JavaScript.

The action is equally clear: the advantage only exists for teams that follow the cadence. Treat runtime upgrades as planned quarterly platform work, keep production on Active or Maintenance LTS, and test against Current so October's Node 26 LTS transition is a non-event. In a year defined by supply-chain attacks and runtime fragmentation, minimizing surprise is probably the most valuable feature any runtime ships.