Node.js Release Schedule Changed — Plan Now

Node.js just reworked the Node.js release schedule: starting in October 2026, there’s one major release per year (April), it promotes to LTS in October, and—crucially—every release becomes LTS. That’s a cleaner map for teams already juggling Node 20’s End of Life on April 30, 2026 and planning what comes next. Here’s the thing: the new cadence doesn’t just change version numbers; it changes how you budget time, test your dependencies, and run CI for the next three years.

What exactly changed in the Node.js release schedule?

The project is simplifying the cadence and the support windows. In effect, the new model locks predictability into the calendar and reduces the number of active lines that volunteers must maintain. The highlight reel:

• One major each April. It becomes LTS in October.
• Every major will be LTS—no more odd vs. even confusion.
• A six‑month Alpha channel (October–March) for early, breaking changes.
• The LTS window remains 30 months; total from first April release to EOL is 36 months.
• Node 26 (April 2026) is the last line under the current model; Node 27 (April 2027) is the first under the new model.

Practically, that means you can forecast runtime lifespan with real dates instead of vibes. If you adopt in the first LTS month (October), you’ll have roughly 30 months before EOL pressure returns. That’s enough runway for two annual planning cycles and one big architectural initiative.

Node 20 EOL: the six‑week triage you can still ship

Today is March 14, 2026. Node 20 reaches EOL on April 30, 2026. If you’re still running 20 in production, you have six and a half weeks to move. That’s tight but shippable with focus. If you want a fast, opinionated path, use our 30‑day recipe in this 30‑day upgrade game plan and pair it with the guidance below.

Week 1 (by March 20): lock your dependency graph. Snapshot package‑lock.json, generate a bill of materials (SBOM), and flag native modules. Spin up parallel CI matrices for Node 22 and 24. Find the red.

Week 2 (by March 27): clear TypeScript and test runner issues. Most breakage clusters around tsconfig moduleResolution, jest/node‑test runner behavior, and sharp/node‑sass prebuilds. Unstick those first.

Week 3 (by April 3): soak tests on the target version. Run canaries in a staging environment with production parity. Compare p95 latencies, memory, and start‑up time. If you’re mostly green on 24 but still have one stubborn lib, consider isolating it behind a worker process pinned to 22.

Week 4–5 (by April 17): progressive rollout. Start with internal tooling and background jobs. Then canary 5–10% of production traffic. If error budgets hold for 72 hours, scale to 50%.

Week 6 (by April 24): finalize, freeze, and add a backout. Tag images, freeze deploys except for hotfixes, and keep a tested revert to 22 in your pocket for seven days after the cutover.

If you need a structured engagement to get from red to green, talk to us about a fixed‑fee upgrade sprint—see what we do for engineering teams and our ship‑by‑April‑30 guide.

Which LTS should you target—Node 22 or Node 24?

Let’s get practical. As of mid‑March 2026, Node 22 is in Maintenance LTS with EOL on April 30, 2027. Node 24 is Active LTS with EOL on April 30, 2028. Translation: 24 buys you an extra year of runway, plus a more active stream of vetted fixes through October 2026.

Choose Node 24 if: your platform (Docker base, PaaS, Functions runtime, build images) supports it today; your native deps have prebuilds for 24; and your CI can absorb the change this month.

Choose Node 22 if: your hosting or frameworks aren’t yet certified for 24; you hit a critical library pinned to 22; or you’re in change freeze and only have a narrow validation window. It’s still supported until April 2027, which keeps you safe while you plan the move to 26 LTS in late 2026 or early 2027.

Not sure where to land? We wrote a pragmatic take on deciding between 22 and 24 here: upgrade to 22/24 the smart way.

The Alpha channel: how to use it without breaking main

The release team introduced a formal Alpha channel (October–March) for next April’s major. It’s signed and tested, and it’s where semver‑major changes can land. That’s your early warning system—use it.

A simple CI pattern that works

• Create a weekly “future runtime” workflow that installs the current Alpha and runs only your fast suites (lint, typecheck, unit, a smoke E2E).
• Don’t make Alpha a required check for merges. Instead, pipe failures to a Slack channel with owners and labels (runtime‑compat, third‑party, perf).
• Maintain a 10‑package canary list—your most critical transitive dependencies—and track their Alpha pass rate. When one fails, open an upstream issue with a minimal repro and link it in your tracking doc.
• Snapshot metrics. Keep a dashboard for start‑up, heap, and long‑tail latency on Alpha vs. LTS to catch regressions early.

Added benefit: your library authors get signal early enough to fix things before October LTS. You stop waking up to “surprise” breakages during your upgrade quarter.

A pragmatic framework to stay current without burning out

Here’s a four‑part framework we’ve used with product teams—4R: Runtime, Repos, Runners, Rollouts.

1) Runtime

• Pick a single target LTS per fiscal year (e.g., adopt 26 LTS in Q1–Q2 FY27).
• Lock base images and glibc/musl variants across services to avoid “works on my container” bugs.
• Track EOLs for Node and critical OS layers in one place. Gate deploys when the target runtime is out of policy.

2) Repos

• Standardize package managers (npm, pnpm, or Yarn Berry) and Node versions via .nvmrc/.node‑version + corepack.
• Enforce engines in package.json and fail CI if out of range.
• For monorepos, carve out a canary app that compiles and runs first on the new Node; if it passes, fan out to the rest via workspaces.

3) Runners

• Keep CI runners one minor ahead of production. If prod is 24.14.x, test with 24.15.x as soon as it drops.
• Cache native module prebuilds per Node ABI to speed green builds and reduce flaky retries.
• Add a weekly “ncu” (npm‑check‑updates) job that proposes dependency bumps in small batches; auto‑merge patch‑level updates with passing tests.

4) Rollouts

• Ship in this order: internal tooling, jobs/cron, APIs, frontends.
• Use feature flags or traffic splits for runtime changes just like you do for features.
• Define a crisp backout: pinned container images, DB rollback notes, and an incident template labeled “Runtime Regression”.

People also ask

Does odd vs. even still matter?

No. Under the new Node.js release schedule, every major becomes LTS. The odd/even distinction is going away starting with Node 27 in April 2027.

How long is LTS support?

Plan for 30 months of LTS coverage, with about 36 months from first April release to End of Life. If you adopt during the first LTS month (October), you get roughly 30 months before EOL.

What if my cloud provider lags on new Node versions?

It happens. If Node 24 isn’t available on your platform today, target 22 (supported through April 2027), and push your provider for status dates. Keep a thin service layer so you can swap base images without refactoring core code.

Risk hotspots to check before cutover

• Native modules: sharp, bcrypt, sqlite, node‑sass—verify prebuilds for your CPU/OS.
• Test runners: if you’re moving from Jest to the built‑in test runner, rebaseline watch mode and reporters.
• ESM/CJS edges: keep tsconfig and package.json module fields consistent; stop mixing import and require in hot paths.
• OpenSSL/V8 bumps: measure TLS handshake CPU and heap churn on long‑lived processes like SSR.
• Serverless cold starts: build separate layers per Node version to cache the right binaries.

Budgeting for the new cadence

The shift to one annual major smooths capacity planning. Treat April–June as discovery and October–December as adoption every year. Allocate a recurring “runtime line item”: two engineer‑weeks for analysis, one for CI/runners, one for rollout. For larger estates, schedule one product line per quarter so you’re never doing a company‑wide lift at once.

Benchmarks and dates you can plan around

Anchor your roadmap to these near‑term dates:

• April 30, 2026: Node 20 EOL—security fixes stop.
• April 2026: Node 26 initial release; enters LTS in October 2026; EOL April 2029.
• April 30, 2027: Node 22 EOL.
• April 30, 2028: Node 24 EOL.
• October 2026: New model begins; Alpha for Node 27 runs Oct 2026–Mar 2027; 27.0.0 in April 2027.

A fast compatibility checklist you can copy

Print this and check it off as you go:

• Engines: set "engines.node" and fail CI when out of range.
• Lockfiles: regenerate with the target Node and your chosen package manager.
• Native deps: prebuild or rebuild in CI for linux‑x64‑gllib/musl, darwin‑arm64/x64, and windows‑x64.
• TypeScript: align module, moduleResolution, and target to framework defaults; no mixed ESM/CJS.
• Test runner: run on both old and new Node for one week; compare flake rates.
• Observability: create a version tag on metrics and alerts so you can segment regressions.
• Containers: base image pinned by digest, not tag; rebuild to capture correct libstdc++/openssl.
• Feature flags: prepare a quick kill switch for runtime‑sensitive features like SSR streaming.
• Backout: keep the last good image and DB migration rollback handy.

What to do next (this week)

1) Pick your target: prefer Node 24 unless a platform block forces 22.
2) Stand up a weekly Alpha CI job so October doesn’t surprise you.
3) Run a two‑service canary on the target Node and publish graphs for latency, memory, and error budgets.
4) Book the rollout slots between April 10–24. Keep April 25–30 for verification and contingency.
5) Decide whether to self‑ship or bring in help. If you want a fixed‑scope engagement, browse our services for upgrades and CI hardening or just contact us.

Zooming out: better cadence, fewer surprises

I’ve shipped Node.js upgrades in companies that treat runtime changes as black swans and in teams that budget for them like taxes. The latter always win: smaller diffs, calmer releases, and fewer Friday night incidents. The new schedule makes that easier—one major a year, a predictable LTS handoff in October, and an Alpha runway that surfaces risk months earlier. Use it.

If you’re already on 24, pencil in an Alpha pipeline for 27 this October and plan your 26 LTS adoption opportunistically if a feature or perf gain makes it worth it. If you’re on 20, the clock is loud—follow the six‑week triage, lean on our 22 vs. 24 decision guide, and ship.