Node.js 20 EOL: Your 30‑Day Upgrade Plan

Node.js 20 EOL is on April 30, 2026. After that date, you won’t get upstream security patches, and vendors will begin turning the screws—deprecating images, warning in dashboards, and eventually blocking deploys. If you’re still shipping production traffic on v20 in March 2026, this is your window to move—without scrambling at quarter end.

Here’s the thing: EOL isn’t a theoretical risk. It’s a hard stop for community fixes and the start of real operational drag. The good news is you don’t need a moonshot. With a focused 30‑day plan, you can land on a supported LTS, preserve velocity, and make your compliance folks happy.

What Node.js 20 EOL means for your stack

On April 30, 2026, Node 20 (codename Iron) exits Maintenance LTS. That ends security updates from the project. New CVEs won’t be backported. In practice, that creates three fast‑moving risks: your security posture drifts, your platform images age out, and your build chain starts failing as ecosystem packages target newer baselines.

Cloud platforms typically follow the upstream clock: they start by displaying deprecation notices, then restrict creation of new functions or apps on the old runtime, and later block updates or cold starts. The exact cadence varies by provider, but the direction is consistent. If your roadmap includes new regions, new accounts, or auto‑scaling with cold starts, “we’ll pin Node 20 for a while” stops being a plan.

Which version should you upgrade to in March 2026?

Short answer: prefer Node 24 LTS (Krypton) if your platform supports it. Node 24 entered Active LTS on October 28, 2025 and is covered through April 30, 2028. That buys you two full years of predictable support. If your provider or critical dependency isn’t ready for v24 yet, target Node 22 (Maintenance LTS through April 30, 2027) as a stepping stone—then schedule a smaller hop to v24 once your stack is compatible.

Decision guardrails I use with teams:

• If you run containers you control, go straight to v24 LTS. Test and ship.
• If you’re serverless or on managed builds, adopt the newest LTS your platform supports today. Set a reminder to revisit v24 within one quarter if you must land on v22 now.
• If you maintain native add‑ons, plan extra time to rebuild and validate under the new V8 toolchain; Node‑API helps, but it’s not a silver bullet for every edge case.

Node.js 20 EOL: a 30‑day, four‑week upgrade plan

This playbook assumes you’re on v20 today, with CI, staging, and reasonable test coverage. If you don’t have all three, follow the same outline and expand the testing parts.

Week 1 — Inventory, risk triage, and a clean test matrix

Start with truth: list every service, Lambda/function, worker, job, and CLI package using Node 20. Capture runtime, region, base image, and maintainer. Treat this as a living spreadsheet.

Next, turn on a three‑version CI matrix for the affected repos: target “20, 22, 24” and fail fast. This will surface transitive dependency gaps early. If the matrix is noisy, pin to latest patch (for example, 24.x latest) to avoid chasing old bugs.

Then bump the low‑risk stuff: pure JS libraries, internal CLIs, and services without native dependencies. Cut releases behind feature flags. If you use GitHub Actions or a similar runner, pin your Node setup action to the exact LTS line you’re validating; don’t let your CI default change under you. If your Actions bill has been creeping up, our 2026 pricing playbook can help you model costs while you scale the matrix.

Week 2 — Dependencies, images, and native modules

Now the heavy lifting. Update core dependencies: your web framework (Next.js, NestJS, Express middleware), ORM, test runner, and TypeScript. Watch for deprecations like built‑ins moved to standards‑based APIs. If you rely on CommonJS in tooling, verify that any ESM‑only packages are transpiled or shimmed correctly.

Rebuild native modules. Add‑ons using Node‑API (N‑API) often recompile cleanly across majors, but modules tied to old node‑gyp chains or OpenSSL internals may need code or flags changes. If you see ABI errors at startup, rebuild from scratch in a toolchain that matches your target image.

Align your base images. If you run Debian or Ubuntu images, ensure your glibc and OpenSSL versions match your target Node LTS images. Alpine (musl) users: expect more native add‑on rebuilds and verify DNS and crypto behavior under musl. Ship a pre‑built layer cache for CI to keep pipeline times sane.

Week 3 — Staging canaries, observability, and performance

Promote services that passed CI to staging on Node 24 (or 22 as a temporary landing). Turn on verbose logs for GC pauses and event loop delays. Add synthetic checks for cold start latency, TLS handshakes, and common database queries. If you run serverless, canary at 10–20% traffic for at least 24 hours of peak patterns.

Measure the deltas that matter to customers: p95/p99 latency, error rates, and memory footprint. It’s common to see neutral or modestly better CPU performance moving from 20 to 24, but memory ceilings can shift due to V8 changes. Don’t chase microbenchmarks; validate business SLOs.

Week 4 — Production rollout, rollback, and closeout

Roll out with progressive deployments. For containers, use blue‑green or weighted canary. For serverless, use traffic shifting with alarms. Keep a one‑click rollback to the last known‑good v20 build for 7–14 days, but plan to remove it before providers enforce blocks.

Close with documentation and a diary entry: capture the upgrade decisions, tricky dependencies, flags used, and post‑deploy metrics. That institutional memory pays off during your next LTS hop.

People also ask

Will my app stop working after Node.js 20 EOL?

Not immediately. Your app won’t crash on May 1 because of EOL alone. But you’ll stop receiving community security patches, and vendors will phase out v20 runtimes. That’s when you’ll feel friction: blocked rollouts, failing cold starts, or policy exceptions you need to justify in audits.

Which Node.js version should I upgrade to right now?

Prefer Node 24 LTS for its runway through April 2028. If your cloud or framework isn’t ready, land on Node 22 (supported through April 2027) and book the second hop to 24. Don’t choose 22 because “it’s easier to test” unless a hard platform constraint forces it.

How long does a safe upgrade take?

If your test coverage is decent and you don’t have exotic native add‑ons, a 2–4 week push is typical for mid‑sized services. Mono‑repos and large orgs need coordination overhead; use the weekly milestones above and move in waves.

How do I find the dependencies blocking my upgrade?

Run a three‑version CI matrix and use dependency graphs to spot laggards. In practice, one or two packages (crypto, image processing, headless browsers) cause most of the pain. For those, check for ESM‑only releases, Node‑API support, or maintained forks. If there’s no path forward, isolate the feature behind a service boundary or replace the lib.

Does Node‑API mean I never have to rebuild native add‑ons?

Node‑API is ABI‑stable across Node majors, which greatly reduces rebuild churn. But add‑ons that bypass Node‑API, rely on internal headers, or indirectly bind to OpenSSL may still need changes. Treat “works once” as “needs validation in CI for every major baseline.”

A practical checklist you can copy

Use this as your daily standup driver during the migration.

Runtime and OS

• Pick target: Node 24 LTS first, Node 22 if blocked; create a follow‑up issue for the second hop if you land on 22.
• Standardize base images and OS (Debian/Ubuntu vs Alpine). Align glibc/OpenSSL with official Node images.
• Audit serverless runtimes and regions; note any that lack Node 24 today.

CI/CD and build

• Add a 20/22/24 test matrix; fail on warnings you care about (type errors, deprecations).
• Pin your Node setup action in CI to exact majors; avoid floating tags.
• Rebuild native add‑ons; prefer Node‑API over node‑gyp when options exist.

App behavior

• Verify ESM/CJS boundaries; ensure tsconfig and bundlers target your Node baseline.
• Test TLS connections and crypto; watch for algorithms or defaults that changed between majors.
• Load test p95/p99 and memory with production‑like data.

Security and compliance

• Run dependency audits after the upgrade and fix the real issues, not just the noise.
• Document the upgrade decision and coverage period (to April 2028 on Node 24) in your risk register.
• Schedule quarterly LTS posture reviews to avoid last‑minute scrambles next time.

Data and dates that matter

Mark these on your calendar so you’re arguing from facts, not vibes:

• Node 20 (Iron): Initial release April 18, 2023; Maintenance LTS ended April 30, 2026.
• Node 22 (Jod): Enters Maintenance LTS on October 29, 2024; support through April 30, 2027.
• Node 24 (Krypton): Active LTS since October 28, 2025; support through April 30, 2028.

Providers will stagger enforcement. Expect deprecation warnings first, then creation blocks for new functions or environments, and later restrictions on updates. If you’re in a regulated environment, expect auditors to flag “unsupported runtime” findings shortly after April 30, 2026.

Let’s get practical: migration patterns that work

Containers first? Bake a fresh image with Node 24 LTS and your exact OS base. Rebuild native modules in that image to avoid ABI mismatches. If you use multi‑arch images, verify arm64 builds—don’t assume amd64 behavior carries over.

Serverless? Stand up a parallel function on the new runtime and mirror traffic with canaries or shadow reads. Keep environment parity: Node options, memory/timeout settings, and layer versions. Watch cold starts—sometimes the runtime change interacts with your bundler output or dependency graph in surprising ways.

Mono‑repo with dozens of packages? Upgrade the build toolchain first (TypeScript, ts‑node/tsx, test runner, eslint). Then cut a “compatibility” release across shared libs, and finally bump app packages. Don’t tie everything to one mega‑PR; use capability flags and ship iteratively.

Have a vendor SDK that lags? Talk to support with a concrete ask and dates. In parallel, spike a shim or fork to unblock your path; plan to replace it once the official package lands.

Common footguns to avoid

• Letting CI float to a new Node major and then backporting failures into your codebase. Pin majors.
• Assuming Node‑API eliminates rebuild risk. Validate native modules in the target image.
• Shipping on Alpine without testing native add‑ons. Musl libc differences still bite.
• Ignoring TLS and OpenSSL defaults. If your upstreams are strict, tiny changes break handshakes.
• Forgetting cron jobs and CLIs. They’re part of production too.

What to do next

• Today (March 9, 2026): create the inventory, add the CI matrix, and pick your target (24 if possible).
• This week: upgrade low‑risk services, rebuild native add‑ons, and align base images.
• Next week: canary in staging, watch p95/p99, and fix the last mile issues.
• Before April 30, 2026: complete production rollout and remove Node 20 create/update paths.

If you want a deeper dive into risks and tactics, we’ve covered specifics like breakage patterns and fast upgrades in our focused write‑ups: see what breaks and how to upgrade fast and the sprint‑oriented “ship your upgrade now” guide. If you’re overhauling CI at the same time, our GitHub Actions 2026 playbook helps you keep pipeline costs under control during multi‑version testing.

Need a hand running this at scale or under a board‑level deadline? Our engineering team ships these migrations for startups and enterprises alike. Explore our Node and platform engineering services or reach out—we’ll build a plan that fits your stack and calendar.

Zooming out

This won’t be the last time you ride the LTS cycle. Treat the Node.js 20 EOL push as a rehearsal for painless, predictable migrations. Standardize your images, pin majors in CI, keep a live inventory, and rehearse rollbacks. Do that, and the next upgrade is just another sprint—without the drama.