Node 20 end of life: which line to target now

Node 20 end of life was 30 April 2026, which means the Brotli remote code execution bug fixed on 21 October will never be patched there — not late, not eventually. If you are still running it, you do not have a patching problem, you have a migration, and the line you migrate to is worth ten minutes of thought because the support calendar moved three days ago and moves again in five.

Here are the real dates from the project's own schedule, what each line costs you in forced migrations, and the part of the work that is never the runtime.

What Node 20 end of life actually means for the Brotli fix

The October release shipped for the 26.x, 24.x and 22.x lines only. Node.js states the rule plainly in the advisory: "End-of-Life versions are always affected when a security release occurs." Not "may be affected" — are.

CVE-2026-111497 is an out-of-bounds write in the Brotli decoder Node.js bundles, rated High, and it is reachable from node:zlib, from Express 5 and body-parser request bodies, and from the built-in fetch() when it decompresses a response. There is no upstream workaround. On a supported line you install 22.23.4, 24.22.1 or 26.12.1. On Node 20 there is nothing to install.

Vercel's bulletin is the clearest statement of the practical consequence for anyone on a managed platform: projects on Node.js 20.x must "change version to 22.x or 24.x and redeploy", because Node 20 "reached end of life and will not receive this fix". Projects already on 22.x or 24.x need no action, since Vercel manages patch versions for those runtimes.

The support calendar, with the dates that matter

These come from the nodejs/Release schedule, which is the only place the full set is published — the website's release table gives codenames and status labels but no LTS or end-of-life dates at all.

Line	Codename	Status	Maintenance from	End of life
20.x	Iron	End-of-Life	2024-10-22	2026-04-30
22.x	Jod	Maintenance LTS	2025-10-21	2027-04-30
24.x	Krypton	Active LTS	2026-10-20	2028-04-30
26.x	—	Current	2027-10-20	2029-04-30

Read the end-of-life column as the only number that matters for planning, and the obvious move becomes the wrong one. Jumping from 20 to 22 — the smallest diff, the least testing, the version most upgrade guides still default to — buys you until April 2027. That is roughly eighteen months, and 22.x has already been in Maintenance LTS since October 2025, meaning it gets fixes but no features and no further attention.

Two timing details are live this week. Node 24 entered Maintenance on 20 October 2026, three days ago. And Node 26 becomes Active LTS on 28 October 2026, five days from now, with an end-of-life of April 2029.

One honest wrinkle: the schedule lists 24.x's Maintenance start as 2026-10-20 while still labelling the line "Active LTS". The date has passed and the label has not caught up. We read that as 24.x now being in maintenance in practice, but if your compliance process cares about the distinction, screenshot the page rather than quoting us.

Active LTS and Maintenance LTS are not the same promise

This distinction decides how much runway a line really gives you, and the labels do a poor job of advertising it. For lines up to Node.js 26, the project's policy is that "Every even (LTS) major version is actively maintained for 12 months from the date it enters LTS coverage", after which "the major version transitions into 'maintenance' mode for 18 months".

In practice: Active LTS is where backported features, performance work and the bulk of the project's attention go. Maintenance is security and critical bug fixes only. Both receive security patches — that is the part that matters for CVE-2026-111497, and it is why 22.x got the Brotli fix despite being in maintenance since October 2025.

So a line in Maintenance is safe to run and a poor thing to migrate onto. You inherit the remaining months of the 30-month window rather than the whole of it, and you spend the same testing effort either way. Node.js is explicit that "Production applications should only use Active LTS or Maintenance LTS releases" — but choosing between the two is yours, and the end-of-life column is the only honest way to compare them.

So which line should you target?

If you are migrating off Node 20 this quarter, target 24.x. It has an April 2028 end of life, two and a half years of runway, and it is the line the ecosystem has had a year to stabilise against — nodejs.org lists v24.22.1 as the Latest LTS.

Target 26.x instead if your migration will not land before December and you can absorb being an early adopter. It becomes Active LTS on 28 October and runs to April 2029, so it saves you one forced migration compared with 24.x. Against that, native-module and tooling support for a line that has only just left Current is thinner, and you will meet that friction rather than reading about it.

Target 22.x only if something genuinely pins you there, and write the April 2027 date into the ticket when you do. A migration you have to repeat in eighteen months is a migration you are doing twice.

This is the same shape as picking between .NET 10 and .NET 11: the cost of choosing the nearer version is never the upgrade itself, it is the second upgrade you have now scheduled for yourself.

The policy change that affects your next decision, not this one

From Node.js 27 onwards the cadence changes, and it is worth knowing before you build a three-year roadmap on the current pattern. Node.js states that "the release cycle will be annual and every major version will move to LTS status after its six-month Current phase (and six additional months of Alpha phase)", with "30 months of Long Term Support, for a total of 36 months from its first Current release to End-of-Life".

Two consequences. Odd-numbered lines stop being throwaway — under the old scheme they were never promoted to LTS and died after about six months, which is why 23.x and 25.x both reached end of life inside a year. And 36 months total is more predictable than the current 30-month LTS window, so the annual rhythm makes "upgrade every other year" a defensible policy rather than a gamble.

Node 27 enters its Alpha phase on 28 October 2026, the same day 26 becomes Active LTS, and the project notes those dates are subject to change.

The work is not the runtime

Here is where estimates go wrong. Moving the runtime is a line in a Dockerfile and a CI matrix entry. What actually consumes the weeks:

• Native modules. Anything compiled against V8 needs a version that supports the new ABI. This is where a two-week estimate becomes six, usually because of one unmaintained dependency three levels down.
• The things that are not your app. Vercel's own list is a good checklist: external backends, self-hosted Next.js, self-built containers, CI runners and local development. The CI runner image is the one teams forget, and it is the one that will keep building against a dead runtime after production has moved.
• Behaviour that changed quietly. Not breaking changes in the release notes, but TLS defaults, DNS resolution order and error shapes. This release alone fixed three High-severity TLS and DNS hostname-verification bugs, which tells you that layer is moving.
• The test suite you will not trust. If your coverage cannot tell you whether a route still behaves identically, the migration is a rewrite with extra steps.

The unavoidable version of this problem is the one Windows Server 2016's end of support illustrates: the platform date is fixed and public, and the application is what makes it expensive. The same was true of php2shell landing on PHP 8.1 estates the same week — an unpatched RCE on a dead runtime converts a deferred upgrade into an unplanned one at the worst possible moment.

What to do this week

Inventory first, and inventory the things that are not production: CI images, build containers, Lambda and Cloud Run runtimes, developer machines, that one ops box. Anything on 20.x or earlier is carrying an unpatched High-severity RCE today, and anything on 23.x or 25.x has been end-of-life since 2025 and June 2026 respectively.

Then pick one target line for the whole estate rather than per service, because a fleet on three runtimes means three times the forced migrations. Target 24.x unless you have a reason to wait for 26.x, and put the April 2028 date in the roadmap where someone will see it.

If the inventory itself is the hard part — and in estates that grew over a decade it usually is — that is the work we are typically brought in for. Legacy modernisation engagements almost always start here, because you cannot plan a migration off a runtime until you know every place it runs.

Then sequence it so that the risky part is early and reversible. Move the CI runner image first and let the test suite run on the target line for a week before any production change — that surfaces native-module breakage while nothing is at stake. Then one low-traffic service, held for a few days with TLS and DNS behaviour under real traffic rather than in a test. Then the fleet. The order matters more than the pace: the common failure is upgrading production in one window, meeting an ABI problem at 2am, and rolling back onto a runtime with an unpatched remote code execution bug in it.