Node.js 20 EOL: A Zero‑Downtime Upgrade Plan

Node.js 20 EOL lands on April 30, 2026. After that date, you’re off the security train, and the cloud providers you rely on will start flipping deprecation switches. If you still have production workloads, serverless functions, or CI actions tied to 20.x, use this as your field guide to move with confidence—fast—without breaking customer traffic.

The Node.js 20 EOL timeline at a glance

Different platforms enforce deprecation differently. Here are the dates that matter so you can plan rollouts with real constraints instead of wishful thinking:

Core runtime: Node.js 20 reaches end of life on April 30, 2026. That’s the last call for official security fixes on the 20.x line.

AWS Lambda: Node.js 20 deprecates along with the upstream EOL (April 30, 2026). After that, AWS stages blocks: you won’t be able to create functions with 20.x after late summer 2026 and won’t be able to update them by early fall 2026. Translate that: your code might still run for a short window, but your hands will be tied for new deploys and fixes.

Google Cloud: App Engine standard marks Node.js 20 end of support on April 30, 2026, and Cloud Run functions start the deprecation clock the same day, with decommission deadlines that follow later in 2026. If you’re using gen‑1 functions or older stacks, check your runtime IDs and cutovers now.

Azure Functions: Node.js 20 support aligns to April 30, 2026, with Node 22 already available. If you’re on Linux Consumption and planning to jump to Node 24 later, note the plan’s version ceilings and consider Flex Consumption if you need newer runtimes.

GitHub Actions: Actions are shifting their JavaScript runner default from Node 20 to Node 24 in June 2026, with opt‑outs only for a limited time. If your private or third‑party actions hard‑pin Node 20, budget time to bump toolchains and retest before your CI silently changes underneath you.

Why this EOL is different

Two reasons. First, the cloud vendors have standardized tougher, clearer deprecation gates—create and update blocks—so “we’ll sneak a patch next week” doesn’t fly. Second, the ecosystem has moved: popular SDKs and toolchains are already declaring Node 22 or 24 as their minimum. Waiting increases the blast radius and shortens your burn‑in time in staging.

Your Node.js 20 EOL upgrade playbook

Here’s the 10‑step path we’ve used to upgrade critical services with zero downtime. Treat it like a sprint plan; most teams can complete it in 1–3 weeks per service depending on dependencies.

1) Set the target and freeze scope

Pick one target per workload: Node 22 LTS (safe and widely supported) or Node 24 LTS (performance headroom and newer platform features). Don’t chase both unless you truly need to. Freezing scope keeps you from bikeshedding on optional refactors.

2) Bump engines and toolchains together

Update "engines": { "node": "22.x" } (or 24.x) in package.json, then align package managers (npm@10/11, pnpm, or yarn) to versions officially compatible with your Node target. Lock the version in CI so local and pipeline installs are consistent.

3) Expand your CI test matrix early

Add parallel jobs for Node 22 and Node 24 in your pipeline whether or not you’ll fully move to 24 now. This surfaces transitive dependency issues—especially native modules—before you touch production. For GitHub Actions, pre‑test using runner images that support Node 24 so you’re not surprised when it becomes default later in 2026.

4) Rebuild anything using Node‑API or native binaries

Libraries that bind to C/C++ (bcrypt, sharp, sqlite, grpc, bindings under the hood) often need a clean rebuild on the new major. Force source builds in CI, or upgrade to prebuilt releases compiled against your target Node ABI. If you ship Docker images, don’t forget the node:22‑alpine vs node:24‑alpine base image choice—it changes libc and SSL details, which can alter behavior.

5) Audit and replace deprecated APIs

Scan your code and dependencies for APIs that changed semantics across versions: URL parsing, streams backpressure, and fs edge cases are usual suspects. If you still rely on legacy behavior from early 18/20 days, isolate it behind an adapter so the rest of your app can move forward.

6) Decide your module strategy—ESM, CJS, or hybrid

Most modern frameworks assume ESM first. If your app is still CommonJS, you can upgrade Node without a wholesale rewrite by using dual‑package patterns or bundling tests with Vitest to avoid ESM/CJS friction. The main rule: make module resolution boring. It should never be the reason your rollout stalls.

7) Tighten runtime permissions where it makes sense

Node’s permission model has matured since 20.x and is now practical for isolating risky tasks. Start by denying network and file system access by default in non‑prod pipelines and allow only what tests need. For production, consider enabling it for worker processes that execute untrusted or user‑supplied content.

8) Rethink HTTP clients and TLS defaults

Modern Node bundles Undici and newer OpenSSL stacks. That unlocks better HTTP/2 behavior and new cipher defaults, but it also exposes out‑of‑date proxies and mTLS quirks. Test long‑lived connections, HTTP/2 push/streaming paths, and TLS handshake timeouts. If you see flakiness, pin client versions explicitly and capture pcap traces to debug.

9) Run load tests that look like your Tuesdays

Don’t chase synthetic throughput bragging rights. Reproduce a normal Tuesday: mixed read/write, cache hits and misses, short and long requests, and real third‑party calls. Look for tail latencies, connection reuse, and memory ceiling, not just RPS.

10) Ship a two‑phase canary

Phase one: route 1–5% traffic for two hours during normal load, compare SLOs, error taxonomy, and GC behavior against Node 20. Phase two: ramp to 25–30% for a full business day. Only flip 100% after you’ve observed a full cache warm/cold cycle and your background jobs have run.

Provider gotchas you’ll want to avoid

AWS Lambda: The managed runtimes track community EOL closely. Expect a deprecation date around April 30, 2026, then administrative blocks on creating and updating Node 20 functions across late summer and September 2026. Plan the cutover at the function level; layers and bundled SDKs might need updates too.

Google Cloud: App Engine standard tags Node 20 end‑of‑support as April 30, 2026, and Cloud Run functions list a decommission milestone in October 2026 for Node 20 runtimes. If you rely on older gen runtimes, confirm your runtime IDs (nodejs20 vs nodejs22) and base images. Rebuild with the newer google‑22/google‑24 stacks to avoid surprise rebuilds at deploy time.

Azure Functions: Node 22 is already GA and Node 20 aligns with the April 30, 2026 end. One wrinkle: Linux Consumption caps newer language versions sooner than Flex Consumption. If you’re planning for Node 24 later this year, make sure your plan supports it or budget a plan migration.

GitHub Actions: JavaScript actions default to Node 24 starting June 2026. If your workflows depend on specific Node 20 behavior, pin action versions that advertise Node 24 support, or you’ll get silent shifts in CI behavior mid‑year.

People also ask: what breaks, and how do I test it quickly?

Short answer: native modules, strict TLS/proxy edges, and ESM/CJS resolution are the big three. The fastest test loop I’ve used:

• CI matrix: 20.x vs 22.x vs 24.x.
• One integration test job that hits your real staging dependencies with production‑like config (feature flags off, real secrets in a secure vault).
• A 5‑minute Locust or k6 smoke that exercises the slowest five endpoints.

If you find incompatibilities, you’ll move faster by bumping transitive deps (via overrides/resolutions) than forking libraries. Only drop to a shim when the maintainer is truly inactive.

Do I need Node 24, or is Node 22 fine?

Most companies should standardize on Node 22 today to simplify support, then schedule a measured move to 24 in H2 if you want the newer V8 and npm 11 improvements or you’re starting to adopt runtime permissioning and URLPattern globally. If you’re on serverless and the provider already encourages 24, go straight there—just reserve extra time for dependency testing.

What happens if I miss the April 30 date?

Your app won’t turn into a pumpkin at midnight, but you’ll lose security updates immediately. On managed platforms, you’ll also run into administrative limits quickly: you won’t be able to create or update Node 20 functions after the provider’s stated block dates. And when your CI defaults shift to Node 24, you’ll be forced to react under pressure. That’s when outages happen.

Let’s get practical: a 1‑week upgrade sprint plan

If you have a small team and a medium‑sized service, this is doable in five working days:

1. Day 1: Set target version (22 or 24). Bump engines, lock package manager, expand CI matrix. Inventory native deps.
2. Day 2: Rebuild native deps, bump transitive packages, fix TypeScript config if you bundle. Resolve ESM/CJS quirks.
3. Day 3: Run smoke + integration tests on 22/24. Fix TLS and proxy issues, especially if you use corporate CA bundles or mTLS.
4. Day 4: Stage deploy. Run 1–5% canary for two hours. Compare tail latency (p95/p99) and memory to Node 20.
5. Day 5: Ramp to 25–30% for a full business day. If clean, flip 100% with a quick rollback lever ready (traffic split or previous image tag).

A quick dependency risk checklist

Before you merge the upgrade PR, confirm these are boxed:

• Binary add‑ons rebuilt: No prebuilds pinned to 20.x ABIs.
• HTTP client behavior validated: Retries, timeouts, and connection reuse under load (Undici changes can be subtle).
• Node permissions strategy decided: At least in CI or worker pools handling untrusted code.
• CI runner stability: Your Actions or runners won’t silently bump Node under you; you either pinned or tested Node 24 paths.
• Log/metrics parity: Same fields, same cardinality, same SLO checks—alert fatigue is real during upgrades.

Where to dig deeper

If you want a blow‑by‑blow of edge cases and migration patterns, we’ve published deep dives you can skim and apply immediately: a breakdown of what breaks and how to upgrade fast and a shipping checklist for Node.js 20 EOL by April 30. If you prefer expert help to hit a date with confidence, see our Node upgrade services or just drop us a note on the contact form.

What to do next (today)

Don’t overthink it. Do this now:

• Create an issue called “Migrate to Node 22 LTS (or 24 LTS)” and assign a DRI.
• Add Node 22/24 to your CI matrix and fix the first red build.
• Pick one non‑critical service; run the 1–5% two‑hour canary during normal traffic.
• Schedule your customer‑facing service for next week’s sprint once the first one is clean.
• Document the steps while they’re fresh. Future‑you will thank you.

Zooming out: the business case

Upgrading isn’t just about compliance with a date on a page. It’s a chance to reduce tail latencies, flatten memory spikes, and shrink your container footprints by adopting newer base images. Teams that upgraded early in 2025 already reported smoother CI (npm 11 improvements), fewer flaky HTTP tests (Undici updates), and easier sandboxing of risky workloads. In a year when everyone is asked to do more with the same infra budget, these percentage points count.

FAQ for the last‑mile questions

Can I jump straight from Node 18 to 24?

Yes. Treat it as a fresh major upgrade and follow the same matrix/canary plan. You’ll often fix the same class of issues once instead of twice.

Will providers auto‑upgrade me?

No. Most will block new creates/updates after their deadlines, but they won’t secretly rewrite your runtime. That’s your call—and your outage if you wait too long.

Is there a case to stay on 22 for the long run?

Absolutely. If your org values maximum ecosystem stability, 22 is a great standard. Plan one more uplift to 24 later in the year if you want its specific improvements.

Final word

Here’s the thing: Node.js 20 EOL isn’t a crisis; it’s a forcing function. Make one service your pilot this week, ship the upgrade with a measured canary, then templatize the process for the rest. By the time the April 30, 2026 deadline hits, you’ll be on supported ground with better performance and less operational risk. That’s how you turn an EOL date into a free reliability upgrade.