Node.js 24 reaches LTS: the migration checklist for teams with an API in production

Node.js 24, codename Krypton, is listed as LTS on the project's official releases page (nodejs.org/en/about/previous-releases), after going through the mandatory six months as Current since May 2025. This changes the risk calculus for teams running services in production: the project's explicit recommendation is that production applications should only use releases in Active LTS or Maintenance LTS, never Current. With version 24 now in that tier, it stops being "the new version to test" and becomes "the version you can put in the Dockerfile of the service that pays the bills."

The calendar behind this decision

Node's release cycle is predictable by design: every version is born as Current for six months (a window for library maintainers to add support before real traffic arrives), and then even-numbered versions (20, 22, 24...) move up to Active LTS, while odd-numbered ones (21, 23, 25) die right there, with no further life. The official page confirms this pattern in practice: v25 was born in October 2025 and is already at EOL status, while v22 (Jod) and v24 (Krypton) remain as LTS.

The project's own text also flags a rule change: starting with v27, the cycle becomes annual, and every major will become LTS after the six months as Current plus another six months in the Alpha phase. It's worth noting this now, because it changes the selection mechanism, not the release pace: today the interval between LTS versions is already about a year (v20 came out in April 2023, v22 in April 2024, v24 in May 2025), but only even-numbered versions reach that status, odd ones (21, 23, 25) are born and die without ever becoming LTS. Starting with v27, that even/odd filter disappears: every major will become LTS, not just half of them.

As for the support guarantee, the page is direct: LTS "typically guarantees that critical bugs will be fixed for a total of 30 months." It's not a fixed date published per version in that table, but it does give the size of the window: whoever migrates to 24 now gets active maintenance for a good while, which justifies the effort of porting build scripts and CI images.

What actually changes in the runtime, not just in the changelog

Three changes in the 22/24 series carry more weight than cosmetics for teams running an API in production:

Permission model. The --experimental-permission flag, which restricts what the Node process can access on disk, network, and child processes, has matured over the last few majors and arrives more stable in 24. For teams running multi-tenant services or exposing execution of third-party code (workers, plugin sandboxes), this is a security piece that used to exist only via container or seccomp, and now can be declared right in the process invocation.

Native require(esm). The historical pain of a mixed ecosystem (a package published only in ESM, legacy code in CommonJS) shrinks: the runtime accepts loading an ESM module via require() without the dynamic-import-inside-a-wrapper hack. This doesn't eliminate the work of deciding whether the project migrates to ESM for good, but it removes the obligation to do that migration all at once just to install a new dependency.

Updated V8. Every Node major ships a newer version of the V8 engine, which usually means support for more recent ECMAScript syntax and internal performance tweaks to the parser and garbage collector. This is the kind of change that rarely breaks code, but can alter timing behavior in a hot path if the service depends on fine-grained GC heuristics, it's the category of thing that only shows up when testing under real load, not when reading the changelog.

Checklist for teams migrating a real service

Before switching the base image from node:22 to node:24 in the production Dockerfile:

• Native addons first. Any dependency that compiles C++ via node-gyp or uses Node-API needs to be tested against the new version before anything else. It's historically the point of greatest friction in a Node major upgrade, far more than pure JavaScript.
• CI with a matrix, not just a direct swap. Running the test suite on 22 and 24 in parallel for a full deploy cycle, before retiring 22, is cheaper than discovering a regression in production.
• Audit experimental flags in use. If the service already runs with --experimental-permission or another flag that became default or changed names between versions, check the version-24-specific breaking changes list in the official changelog, don't rely on memory of how it was in 20.
• Review the lockfile and npm. Every new Node major usually bumps the default npm version along with it; it's worth checking whether the project's lockfile is still compatible or needs a clean npm install.
• Measure, don't assume. A new V8 can change GC timing under high-allocation workloads. Before declaring victory, run the service under load comparable to production for a while, not just pass the unit test suite.

What this costs compared to a major upgrade in Rails or Java

This is where the comparison matters more than new-version hype. In Rails, the cost of a Ruby major migration is dominated by the gem chain: bundle update can eat up a whole afternoon when some critical gem (Devise, Sidekiq, a database driver) doesn't yet support the new interpreter version, and the fix usually means waiting for the gem's maintainer, not something the team controls. Node has its equivalent in native addons, but the pure-JS ecosystem tends to react faster: a package that only uses JavaScript rarely breaks between runtime majors.

In Java, the scenario is almost the opposite: the JVM has a very strong track record of binary compatibility between LTS versions (Java 17 to 21, for example), so the runtime is rarely the problem, the team spends more time reviewing changes to the default garbage collector or deprecated APIs removed after years of warning. Node doesn't have that same decades-long commitment, but the lifecycle documented on the official page (30 months of LTS) gives similar predictability at a smaller scale.

The practical conclusion: if the service is 100% JavaScript/TypeScript without a heavy native addon, going from 22 to 24 tends to be cheaper than an equivalent migration from Rails 6 to 7 with outdated gems, and comparable to a Java 17 to 21 bump in testing effort. If the service depends on a specific native module (a compiled database driver, a custom cryptography library), it's worth running the full checklist before promising a deadline to the team.

When to wait for the next cycle

If the service is already stable on Node 22 (Jod), which remains LTS, there's no technical urgency to migrate now just because 24 became LTS: the real pressure arrives when 22 enters maintenance and later EOL, following the same pattern that already took 20 (Iron) out of circulation. The actual moment to migrate is usually dictated by an external dependency losing support for the old version, not by Node's calendar alone. But with the announced switch to an annual cycle starting with v27, it's worth already treating this CI matrix testing as a permanent routine, rather than a one-off migration project.