Node.js 24 LTS: What’s New and How to Upgrade

Node.js 24 LTS is now the recommended line for production, and it brings real changes you’ll feel in day‑to‑day engineering: a newer V8, npm 11, runtime deprecations, a more practical permission model flag, and subtle test runner behavior that can make your CI greener—or flakier—depending on how you migrate. Below, I’ll unpack what’s new in Node.js 24 LTS, why the timing matters, and how to upgrade without surprises.

Why Node.js 24 LTS matters right now

Version 24 moved from Current to Active LTS on October 28, 2025, with a support runway to April 30, 2028. That’s a full 30‑month window to stabilize and plan larger platform moves. The release codename is “Krypton,” and it’s now the default LTS line most cloud providers are rolling into images and managed runtimes. (github.com)

If you’ve been sitting on Node 22 LTS to avoid churn, this is your green light. New fixes and vetted backports target v24 first; Node 22 is already in Maintenance LTS. Treat the date change as your cue to run org‑wide compatibility checks and lock a migration window on the calendar. (github.com)

What’s actually new in Node 24 (the shortlist)

Here’s the thing: the headline features aren’t flashy syntax fireworks; they’re foundations that make apps simpler and safer.

V8 13.6 and npm 11 ship standard

Node 24 bundles V8 13.6 and npm 11. That surfaces modern JavaScript like Float16Array, RegExp.escape, explicit resource management, and better WebAssembly (Memory64). In practice, you’ll drop polyfills, lean less on userland shims, and see tighter memory behavior in compute‑heavy code. (openjsf.org)

AsyncLocalStorage defaults to AsyncContextFrame

Context tracking got sturdier: AsyncLocalStorage uses AsyncContextFrame by default, reducing edge‑case leaks in complex async graphs (think queues, background jobs, or request correlation). Expect fewer “context vanished under load” bugs once your dependencies catch up. (openjsf.org)

URLPattern is global

URLPattern is now a global, making route‑like URL matching easier without imports. It’s small, but it cleans up routing, request filters, and proxy logic sprinkled across services. (openjsf.org)

A permission model you might actually turn on

The permission model—introduced back in 20—continues maturing. The flag is now simply --permission and, in the LTS branch, you’ll see ongoing improvements (including backports like --allow-inspector) that make it viable for sandboxing builds, scripts, and even parts of production workloads. It’s not a silver bullet, but it is finally usable. (nodejs.org)

HTTP gets a lift via Undici 7

The runtime’s HTTP client stack is upgraded with Undici 7. If you maintain SDKs or high‑throughput fetch‑heavy services, re‑test connection pooling and timeouts—you may pick up stability and throughput benefits for free. (openjsf.org)

Windows build toolchain change: hello, ClangCL

If you compile Node on Windows (or ship native add‑ons), note the toolchain shift: MSVC support was removed for building Node itself, and ClangCL is required. Most teams won’t build Node from source, but this change ripples into some native module build setups and enterprise images. Audit your builders. (nodejs.org)

Deprecations that finally have teeth

Long‑standing deprecations are enforced more strongly at runtime in 24: url.parse(), SlowBuffer, and several historical APIs are now loudly discouraged or disabled paths. Scan your logs in staging to catch stale transitive deps that still touch them. (nodejs.org)

“People also ask”

Should you upgrade to Node.js 24 LTS now?

Yes—start the migration now, ship to a subset of production in two to four weeks, and finish before the holidays freeze or your next quarterly change window. The LTS clock is already ticking and providers are moving images to 24.x. The longer you wait, the more you stack risky deltas into a single sprint. (azure.github.io)

Will native TypeScript in Node replace ts‑node or build steps?

Node’s built‑in TypeScript “type stripping” means you can run many .ts files directly, no transpile step, and it’s on by default in recent 22/23 lines (and thus present in 24). But it intentionally ignores tsconfig and only supports erasable syntax unless you opt into --experimental-transform-types. Keep your tsc for type‑checking and transforms; treat native TS as a fast path for tools, scripts, and simple services. (nodejs.org)

What breaks if you jump from 20/22 to 24?

Three common snags: 1) native add‑ons need rebuilds because the Node module ABI bumped (24 uses a newer module version); 2) test suites relying on subtest timing need a small refactor; and 3) Windows build images tied to MSVC may need ClangCL for local builds. None are showstoppers if you test early. (nodejs.org)

Node.js 24 LTS, by the numbers

Here are the dates that should be on your roadmap and release checklist: v24.0.0 landed on May 6, 2025; Active LTS started on October 28, 2025; the 24.x line receives support through April 30, 2028. Keep these in your internal upgrade policy so product teams don’t slip past LTS windows. (nodejs.org)

Upgrade playbook: a 7‑step path you can run this sprint

1) Inventory and baseline

List service versions, Docker base images, AWS/Azure/GCP runtime versions, and any native add‑ons (look for node-gyp in build logs). Capture current perf and error budgets so you can prove no regressions after the switch. If you’re on Next.js, note your framework version; caching and proxy behavior in newer builds pairs well with Node 24’s modern web APIs. See our guidance on production caching in Next.js 16 cache and proxy.

2) Light up CI for dual‑runtime testing

Add a Node 24 job to CI alongside your current LTS to surface incompatibilities early. Run the built‑in test runner with node --test and ensure suites don’t rely on implicit subtest completion. While you’re in CI, revisit your token hygiene; our npm token hardening checklist is still relevant and prevents a surprising number of supply‑chain issues.

3) Rebuild native add‑ons

Any module that compiles C/C++/Rust will need a rebuild against 24’s ABI. Pin known‑good versions in package locks and verify prebuild binaries exist for your target OS/arch. If you maintain a native module, publish prebuilds for 24 to spare downstream teams pain. (nodejs.org)

4) Validate the Windows story

For shops on Windows, confirm your dev and CI images have ClangCL available and that your node-gyp toolchain resolves correctly. This is especially important where InfoSec limits tool installation. Document the change so your help desk isn’t flooded next week. (nodejs.org)

5) Flip on the permission model where it helps

Start with scripts and one small service. Run with --permission and grant only what’s required (filesystem paths, env, network targets). Use it to prove least‑privilege in build steps and cron jobs. As confidence grows, consider applying it to edge workers or internal admin tools rather than your hottest path first. (nodejs.org)

6) Embrace native web APIs

Refactor url.parse() to the WHATWG URL API, adopt URLPattern for route matching, and drop userland polyfills now covered by V8 13.6. You’ll ship less code and reduce maintenance debt. (nodejs.org)

7) Plan the cutover

Create a staged rollout (10% → 50% → 100%) and watch p95/p99 latency, memory, and GC pause time. Lock a rollback toggle in your orchestrator. If you’re a product leader, budget two sprints for the full migration across services—most time sinks are dependency bumps and image updates, not code changes.

TypeScript without the build step: where it fits

Let’s get practical. Native TS in Node (type stripping) is great for scripts, CLIs, and services that avoid TS constructs requiring transforms. It keeps feedback loops fast and simplifies container images. But most production apps still want a compile step: tsc type‑checking, path/alias transforms, JSX, and decorators aren’t handled by the runtime. If you want to lean into native TS, enforce verbatimModuleSyntax and import type hygiene, and keep --experimental-transform-types behind a script until your codebase is ready. (nodejs.org)

Common migration pitfalls (and quick fixes)

“Our tests started hanging.”

Node’s test runner now waits on nested subtests. If you inadvertently returned promises without awaiting them, the runner won’t exit. Make subtests explicit or restructure suites to avoid long‑lived handles. (openjsf.org)

“Why did our Windows builds fail overnight?”

Because your images or developer VMs expect MSVC when compiling dependencies. Update toolchains to ClangCL and document the change in your team’s onboarding wiki. (nodejs.org)

“We still use url.parse()—is that bad?”

It won’t crash your app immediately, but you’ll see runtime deprecation warnings and possibly stricter behavior later. Move to the WHATWG URL API. The rewrite is usually mechanical. (nodejs.org)

“Is Undici going to change our HTTP behavior?”

Possibly for the better. Test retry logic, DNS caching, and connection reuse. In high‑RPS services you may see fewer tail spikes. Make sure any custom agent or proxy settings you used with older stacks are still applied. (openjsf.org)

Security and CI: don’t ship risk with your runtime

New runtimes don’t fix sloppy pipelines. If you’re flipping major versions, pair it with CI hardening: rotate tokens, restrict pull_request_target usage, and lock dependency provenance. We’ve written practical how‑tos on both: see our guide to getting GitHub Actions pull_request_target right and the earlier npm token changes checklist. Use the migration as a forcing function to fix what you’ve postponed.

Quick comparison: Node 22 LTS vs 24 LTS (opinionated)

Node 22 was a solid landing spot with early native TS support and a predictable security cadence. Node 24 is the “clean up your stack” release: you drop more polyfills, rely more on web‑standard APIs, and can finally pilot the permission model in anger. Most production code moves with little refactor—your work is corralling dependencies and closing the final mile in CI. (nodejs.org)

What to do next

• Open one migration ticket per service; attach a checklist: image update, dependency bump, test run, permission model trial, native add‑on rebuild.
• Stage a canary rollout on Node 24 within two weeks. Measure p95 latency, memory, and error rates.
• Enable --permission for CI scripts and one low‑risk service to validate least‑privilege policies. (openjsf.org)
• Refactor away from deprecated APIs and adopt URL/URLPattern where it simplifies code. (nodejs.org)
• Document the Windows toolchain change for developers and CI. (nodejs.org)

Need a second set of hands?

If your team wants help planning or executing the upgrade, we do this work routinely—auditing build pipelines, hardening supply‑chain flows, and shipping incremental rollouts without drama. See what we do, browse a few project snapshots, or get in touch via a quick intro. If you’re evaluating broader platform updates alongside this move (say, your .NET services too), our take on long‑term support cycles in why LTS upgrades are worth doing on time still applies.