Node.js 20 EOL by April 30: What to Do Now

Node.js 20 EOL isn’t a distant rumor—it’s a hard stop on April 30, 2026. When a runtime reaches end‑of‑life, security fixes end upstream, vendors begin retiring support, and cloud platforms flip deprecation switches. If you’re still on 20.x, this is your last clean window to migrate with control instead of scrambling during an incident. This guide gives you the playbook—why the date matters, whether to target Node 22 or 24, and the exact checks to run so you can ship with confidence.

Calendar deadline concept beside a laptop showing code

Why Node.js 20 EOL on April 30 actually matters

Here’s the thing: EOL is more than a label. After April 30, 2026, the Node.js project stops issuing security patches for 20.x. Cloud providers and tooling follow suit. On AWS Lambda, for example, Node.js 20 goes into a staged retirement: you’ll stop receiving patches on April 30, creation of new 20.x functions is blocked on June 1, and updates to existing 20.x functions are blocked on July 1. Your functions may keep running, but you’ll be stuck on a runtime you can’t update, and you’ll carry the security and compliance risk.

Meanwhile, the platform you’re migrating to is stable. Node 22 is in Maintenance LTS through April 2027, and Node 24 was promoted to LTS in late October 2025 with support through April 2028. In other words, both are safe homes—you just need to pick the right one for your workload and run the play.

Should you upgrade to Node 22 LTS or Node 24 LTS?

You’ve got two solid options. Choosing well saves you rework later and minimizes dependency drama. Use this simple decision tree.

If you need the absolute longest runway

Pick Node 24 LTS. You’ll get support through April 2028, plus runtime improvements like the latest V8 (13.6), npm 11, URLPattern available globally, a more mature permission model (--permission without the experimental prefix), and newer Undici HTTP components baked in. That buys you time and closes some security gaps by design.

If you value minimal change for the least risk right now

Pick Node 22 LTS. It’s closer to Node 20 in behavior, it’s been widely deployed since 2024, and most popular packages have long since tested against it. You’ll still need to do your due diligence, but the upgrade tends to surface fewer surprises in older codebases. The tradeoff: you’ll need another major upgrade by April 2027.

Reality check: for serverless teams on AWS Lambda, either option is viable today (nodejs22.x and nodejs24.x are both available across regions). If you’re starting a new service or haven’t upgraded in a while, go to 24 and skip a hop. If you’re inside a regulated change window with strict blast‑radius controls, ship 22 now and schedule the next upgrade when your calendar is calmer.

Key differences you’ll actually feel moving off Node 20

When teams stall on upgrades, it’s usually not the major banner features—it’s the edge behaviors and toolchain mismatches that break CI. Here are the deltas that most often bite.

1) The permission model is usable now

Introduced as experimental in Node 20, the permission model is more mature by Node 24 and uses --permission rather than --experimental-permission. If you run untrusted scripts or want to sandbox build steps, you can lock down file, network, and environment access. In practice, this can surface hidden file or network access in test suites. Expect to tweak permissions in CI and reevaluate a few helper scripts.

2) Async context changes affect tracing

Node 24 switches AsyncLocalStorage to use AsyncContextFrame under the hood. It’s a better default, but it can change how context propagates in custom instrumentation and some APM libraries. If you rely on request‑scoped logging, correlation IDs, or OpenTelemetry spans, inspect your traces closely after the bump.

3) Streams and memory pressure feel different on 22

Node 22 increased the default high water mark on streams, which can boost throughput—but at the cost of more memory. If you run in memory‑constrained containers or serverless functions, watch your usage. You can tune the default via setDefaultHighWaterMark() or override at the specific stream.

4) HTTP stack upgrades via Undici

Newer Undici versions are bundled, bringing performance and spec compliance improvements. Most apps won’t notice, but if you have custom agents, proxy setups, or strict header handling, regression‑test all critical outbound calls (especially to older enterprise proxies or mTLS gateways).

5) Tooling and native builds on Windows

Node 24 tightened the Windows build chain. If you build Node or native modules from source in Windows CI, check that your toolchain matches current requirements. Most teams using prebuilt binaries or Linux containers won’t feel this, but monorepos with mixed native addons often do.

6) npm 11 in Node 24

Node 24 ships npm 11, which can alter install performance and lockfile behavior in large repos. If your CI pipeline depends on deterministic installs, regenerate lockfiles in a branch and validate cache behavior and build times before merging.

Migration checklist: a 10‑step sprint you can run this week

Let’s get practical. This is the exact sequence we use when we take clients from Node 20 to 22/24 with minimal downtime. Adapt it to your stack, but keep the order—it avoids dead ends.

Create a runtime inventory. List every service, job, Lambda function, container, and CLI tool still on 20.x. Include OS base images, Node version pins, and any custom layers or AMIs.
Choose your target (22 or 24) by service. Monoliths benefit from a single target; microservices can mix. Document the rationale to avoid back‑and‑forth later.
Unpin legacy transitive deps. Upgrade your package manager (npm 10+/11 or pnpm 9+), clear overrides you no longer need, and run a clean install. Update vulnerable packages flagged by npm audit and check changelogs for engines requirements.
Enable a two‑version CI matrix. Run your full test suite on both the current 20.x and your target (22 or 24). This isolates runtime regressions from general test flakiness.
Exercise the HTTP edges. Add explicit tests for proxies, mTLS, custom agents, and long‑lived connections. Validate headers, redirects, and timeouts to catch Undici‑related differences early.
Trace and APM validation. If you use OpenTelemetry or an APM agent, upgrade the agent first, then verify span continuity and context propagation. Pay special attention to AsyncLocalStorage‑based context.
Rehearse permissioned runs. On Node 24, run tests or scripts with --permission in CI and selectively grant access. You’ll discover surprising file reads and network calls in helper scripts—fix or whitelist intentionally.
Containers and base images. Update Dockerfiles to node:22-alpine or node:24-alpine, then measure start‑up time and memory. Consider --init and NODE_OPTIONS=--max-old-space-size= tuning for memory‑sensitive services.
Serverless specifics. For AWS Lambda, shift runtime identifiers to nodejs22.x or nodejs24.x. If you move to 24, rewrite any callback‑style handlers to async functions, as callbacks aren’t supported in the new 24.x runtime.
Canary and cutover. Roll out to a small percentage, watch p95 latency, error budgets, and memory. Only then scale up and decommission 20.x images and layers.

AWS Lambda specifics you shouldn’t miss

Two practical notes if you’re serverless‑heavy:

First, both nodejs22.x and nodejs24.x are available as managed runtimes and container base images across regions. The 24 runtime removes callback‑style handlers—your functions must export async handlers that return a promise. This is a good thing: it reduces footguns around double‑invocation and dangling callbacks, and it nudges you toward clearer code.

Second, align your layers. If you use Lambda layers for OpenTelemetry, headless Chromium, ffmpeg, or model assets, rebuild each against the new runtime and Amazon Linux 2023. Mismatched GLIBC or OpenSSL versions are a top source of mysterious cold‑start failures during upgrades.

Risk register: what can still go wrong?

Be candid about risks so you can mitigate them:

Native addons. If you depend on native modules via node-gyp, make sure prebuilt binaries exist for your target runtime and OS. Otherwise, your CI will try to build from source and fail due to toolchain or header changes.
Lockfile churn in monorepos. Moving to npm 11 (Node 24) can cause larger lockfile diffs, which then break cache keys and slow builds. Regenerate lockfiles and revisit cache strategy.
Memory budgets. The streams defaults and V8 updates can change memory profiles. In containers and serverless, set alerts on RSS and heap usage; don’t wait for an OOM kill to tell you.
Legacy TLS. If you still talk to endpoints with old TLS policies, test early; newer Node lines have tighter defaults and may require explicit ciphers or TLS renegotiation settings.

A simple framework to pick 22 vs 24 (and stick to it)

Use this 2×2 and document the decision in your repo’s /docs/architecture folder:

Optimization goal: Minimize change now vs. Maximize runway later.

Runtime target: Node 22 for “minimize change,” Node 24 for “maximize runway.”

Deployment style: For serverless‑heavy teams, prefer Node 24 to standardize async handlers and reduce future breaking changes. For containerized services with heavy native addons, consider Node 22 first if your vendors aren’t yet publishing 24‑tested builds.

Commitment: Whichever you choose, create a calendar entry for quarterly runtime reviews. Runtimes aren’t a one‑and‑done decision; they’re hygiene.

Whiteboard migration plan with service sticky notes and arrows

What about other platforms and policies this month?

January is a busy shipping window. If your team also owns mobile apps, slot time for compliance updates alongside your Node upgrade. For guidance on App Store rating changes due January 31, 2026, see our ship‑ready age rating guide. Android teams should also review our January 2026 Android security update playbook so your mobile releases and backend upgrades don’t collide.

Realistic timeline if you start today

Today is January 7, 2026. You have roughly 16 weeks until the April 30 EOL date. Here’s a workable cadence many teams follow without heroics:

Week 1–2: Inventory, target selection, dependency upgrades, and CI matrix for 20/22 or 20/24.
Week 3–4: Fix test failures, validate HTTP edges, tune memory, and rehearse permissioned runs.
Week 5–6: Staging cutover, APM/telemetry validation, load tests, and canaries for the first service.
Week 7–10: Rollout across services in waves; update Docker bases, Lambda runtimes, and layers.
Week 11–12: Decommission Node 20 artifacts and images; lock CI to 22/24; archive rollback images.
Week 13–16: Buffer for stragglers and low‑risk cleanup. Treat this as contingency—you’ll use it.

What to do next

Decide 22 vs 24 today. Don’t split the difference—pick by service and write it down.
Open one upgrade PR per service. Include runtime bump, base image change, dependency updates, and CI matrix.
Schedule a canary window. Pick a quiet period for the first production cutover and put SREs on point.
Track completion publicly. A UPGRADE.md per service with status keeps everyone aligned.
Need help? We do this routinely. Explore our platform upgrade services, see our recent backend and cloud work, or grab our deeper Node.js 20 EOL migration playbook. If you need to move fast, talk to an engineer.

Final thought

Upgrading runtimes isn’t glamorous, but it’s one of the cleanest forms of risk you can retire. Node.js 20 EOL on April 30, 2026 is a clear line in the sand—and a great forcing function. Pick your target, run the checklist, and ship. Your future self (and your incident log) will thank you.

Node.js 20 EOL by April 30: What to Do Now

Node.js 20 EOL by April 30: What to Do Now

Why Node.js 20 EOL on April 30 actually matters