Share

A Node.js application can continue starting, accepting traffic, and passing health checks long after the runtime underneath it has become unsupported.

That creates a dangerous assumption:

If the application is still running, the Node.js version must still be safe.

In reality, “running” and “supported” are two very different states.

A Node.js release is more than a JavaScript executable. It includes the V8 engine, OpenSSL, libuv, Undici, npm, HTTP parsers, compression libraries, DNS components, native module interfaces, and platform-specific build requirements.

When a Node.js version becomes outdated, the problem is therefore not limited to missing language features. Teams begin losing security fixes, ecosystem compatibility, operating system support, deployment platform support, and access to newer tooling.

Understanding the Node.js release lifecycle is essential for making informed architectural, security, and infrastructure decisions.

Understanding Node.js Version Numbers

Node.js uses semantic versioning:

MAJOR.MINOR.PATCH

For example:

24.18.0

In this version:

• 24 is the major release line.
• 18 represents a minor release containing backward-compatible functionality.
• 0 represents a patch release containing fixes and smaller updates.

Major versions are important because they may introduce breaking changes, remove deprecated APIs, update native interfaces, or change runtime behavior.

However, selecting the correct major version is only part of the decision. Teams must also keep that release line updated.

Running Node.js 22.0.0, for example, is not equivalent to running the latest available Node.js 22 patch. Security fixes are delivered through new patch and minor releases, not retroactively applied to every installation.

The Node.js Release Lifecycle

Historically, Node.js major versions began in the Current phase. Even-numbered versions later moved into Long-Term Support, while odd-numbered releases became unsupported after approximately six months.

The Node.js project recommends that production applications use versions in either the Active LTS or Maintenance LTS phases.

Each phase serves a different purpose.

Current

The Current release line contains the latest platform capabilities, JavaScript engine updates, and runtime improvements.

It is primarily intended for:

• Early adopters.
• Library and framework maintainers.
• Teams testing future compatibility.
• Applications that specifically require new runtime capabilities.

Current releases receive active development, but they can also introduce more frequent changes than an established LTS release.

Active LTS

Active LTS is generally the best default for new production deployments.

During this phase, a release can receive:

• Security updates.
• Bug fixes.
• Dependency updates.
• Selected backward-compatible features.
• Performance and stability improvements.

The release line has already completed its initial Current phase, giving the broader ecosystem time to test compatibility.

Maintenance LTS

Maintenance LTS releases remain officially supported but receive a more limited set of changes.

Updates typically focus on:

• Security vulnerabilities.
• Critical bugs.
• Required dependency updates.
• Changes that help users migrate to newer versions.

A Maintenance LTS version can remain a valid production option, but it offers less remaining support time than an Active LTS release.

End-of-Life

Once a Node.js release reaches End-of-Life, the Node.js project stops publishing updates for that release line, including security patches.

The runtime does not immediately stop working. Instead, it becomes permanently frozen while the software, infrastructure, and threat landscape around it continue changing.

Current Node.js Version Status

At the time of writing in July 2026, the main Node.js release lines relevant to production teams are:

Release	Lifecycle status	Latest release at time of writing	Next milestone	End-of-Life
Node.js 26	Current	26.5.0	LTS on October 28, 2026	April 30, 2029
Node.js 24, Krypton	Active LTS	24.18.0	Maintenance on October 20, 2026	April 30, 2028
Node.js 22, Jod	Maintenance LTS	22.23.1	—	April 30, 2027
Node.js 20, Iron	End-of-Life	20.20.2	No further community releases	April 30, 2026
Node.js 18 and earlier	End-of-Life	—	No further community releases	Ended

The official release schedule defines Node.js 22 support through April 2027, Node.js 24 through April 2028, and Node.js 26 through April 2029. Node.js 20 reached End-of-Life on April 30, 2026.

What Actually Changes Between Node.js Versions?

The visible JavaScript APIs are only one part of a Node.js upgrade.

Each major version changes multiple layers of the runtime stack.

1. The V8 JavaScript Engine

Node.js uses Google’s V8 engine to parse, compile, optimize, and execute JavaScript.

A new V8 version may introduce:

• New ECMAScript features.
• Changes to the optimizing compiler.
• Different garbage collection behavior.
• Performance improvements or regressions for specific workloads.
• Updated WebAssembly capabilities.
• Changes in memory usage.
• Removed or changed V8 APIs used by native addons.

As a result, upgrading Node.js can change application performance even when the application code does not change.

This is why mature upgrade processes include load testing and runtime benchmarking rather than relying exclusively on unit tests.

2. Cryptography and TLS

Node.js bundles OpenSSL, which provides much of its TLS and cryptographic functionality.

Updating Node.js may change:

• Supported encryption algorithms.
• TLS behavior.
• Certificate validation.
• Root certificate handling.
• Cryptographic defaults.
• Exposure to OpenSSL vulnerabilities.

An application can therefore have fully updated npm dependencies and still be vulnerable because the Node.js runtime itself contains an outdated OpenSSL version.

3. HTTP and Networking Components

Node.js also includes components such as:

• Undici for modern HTTP client functionality and fetch().
• llhttp for HTTP parsing.
• nghttp2 for HTTP/2.
• libuv for asynchronous I/O, networking, and the event loop.
• c-ares for asynchronous DNS resolution.

These components receive independent security and stability fixes that are distributed through Node.js releases.

The June 2026 Node.js security release, for example, updated OpenSSL, Undici, llhttp, and nghttp2 while addressing vulnerabilities involving TLS verification, WebCrypto, HTTP/2 memory growth, proxy credentials, the Permission Model, and HTTP response handling.

4. Node.js APIs and Runtime Behavior

New major versions can introduce APIs, change defaults, mark existing behavior as deprecated, or remove functionality entirely.

Node.js classifies deprecations into several levels:

• Documentation-only.
• Application deprecations.
• Runtime deprecations.
• End-of-Life APIs.

An API may continue working for multiple versions after being deprecated. That does not guarantee it will survive the next major upgrade.

Node.js specifically uses deprecations when an API is unsafe, when a better alternative exists, or when future breaking changes are expected.

This delayed removal is useful for migration planning, but it can also hide technical debt. Applications may accumulate deprecated APIs for years without failing—until a future runtime finally removes them.

5. npm and Package Compatibility

Each Node.js release includes a version of npm, and modern packages frequently specify supported Node.js versions through the engines field in package.json.

For example:

{
  "engines": {
    "node": ">=22"
  }
}

As package maintainers adopt newer platform capabilities, they commonly stop testing or supporting EOL Node.js releases.

This creates an ecosystem ceiling:

1. The application cannot upgrade a dependency because the new package requires a newer Node.js version.
2. The team pins the dependency to an older release.
3. That dependency eventually stops receiving fixes.
4. The application accumulates both runtime and package-level risk.

Over time, an outdated Node.js version forces more of the application stack to remain outdated with it. npm officially supports declaring runtime compatibility through the engines field, allowing packages to communicate which Node.js releases they expect.

6. Native Addons and ABI Compatibility

Applications that depend on native C or C++ modules require additional attention during upgrades.

Node-API provides ABI stability across Node.js versions, allowing compatible native modules to work across major releases without recompilation.

However, that guarantee only applies when an addon uses Node-API exclusively. Direct use of Node.js C++ APIs, V8 APIs, or libuv APIs does not receive the same cross-major ABI guarantee.

This distinction may become even more important in future Node.js releases. In April 2026, a discussion was opened within the Node.js Technical Steering Committee to reconsider whether ABI compatibility changes should continue to block V8 updates in major Node.js releases.

The discussion highlights an ongoing challenge: preserving ABI stability can delay the integration of newer V8 versions. Node.js 26 was delayed while waiting for V8 14.6, which was already behind the V8 version used by the latest stable Chrome release shortly afterward.

One proposal under discussion is to stop guaranteeing ABI stability across major releases and encourage the native addon ecosystem to rely more heavily on Node-API or Foreign Function Interfaces.

This is an open discussion, not an approved change. However, it illustrates the long-term risk of native addons that depend directly on V8 or internal Node.js APIs rather than stable interfaces.

For additional context, see the Node.js TSC discussion:

Reconsider ABI stability requirement for V8 updates in majors

An upgrade may expose:

• Modules that no longer compile.
• Missing prebuilt binaries.
• Incompatible compiler requirements.
• Deprecated or changed V8 APIs.
• Unsupported node-gyp configurations.
• Abandoned native dependencies.
• Addons that depend on ABI behavior that changes between major releases.

Native addons are one of the most important blockers to identify before beginning a major Node.js migration.

Teams should prioritize dependencies built with Node-API and carefully evaluate addons that interact directly with V8, libuv, or internal Node.js APIs.

Comparing Node.js 22, 24, and 26

The correct version depends on the application’s stability requirements, upgrade timeline, dependencies, and remaining support runway.

Node.js 22: Supported, but Already in Maintenance

Node.js 22 introduced and stabilized several important capabilities, including:

• A built-in WebSocket client enabled by default.
• Stable Watch Mode.
• The node --run command.
• Improvements to loading ESM through require().
• Updates to V8.
• Performance improvements across multiple runtime components.

Node.js 22 remains supported until April 30, 2027, but it entered Maintenance in October 2025.

It can be a practical transitional target for applications migrating from Node.js 18 or 20. However, teams beginning a new long-lived production project should consider whether the remaining support window is sufficient.

Node.js 24: The Current LTS Default

Node.js 24 includes:

• V8 13.6.
• npm 11.
• Undici 7.
• Global URLPattern.
• RegExp.escape().
• Float16Array.
• Explicit Resource Management.
• Improvements to AsyncLocalStorage.
• Further development of the Permission Model.
• Test Runner improvements.

It also introduced deprecations and removals that may affect legacy code, including changes related to url.parse(), SlowBuffer, TLS APIs, Zlib construction, and child process arguments.

Node.js 24 is the Active LTS line until October 2026 and remains supported until April 2028. For most new production deployments in mid-2026, it provides the strongest balance between ecosystem maturity and remaining support time.

Node.js 26: The Current Release

Node.js 26 includes:

• V8 14.6.
• Temporal enabled by default.
• Undici 8.
• New JavaScript collection and iterator capabilities.
• Continued modernization of platform APIs.
• Additional deprecations and removals.

Temporal provides a modern alternative to the legacy JavaScript Date API, with stronger support for time zones, calendar operations, and unambiguous date-time calculations.

Node.js 26 is currently in the Current phase and is scheduled to enter LTS on October 28, 2026. It is a valuable target for compatibility testing today and will become an increasingly relevant production option after its LTS promotion.

The Risks of Running an Outdated Node.js Version

1. Known Vulnerabilities Remain Unpatched

The most direct risk of an EOL runtime is the absence of security fixes.

When a vulnerability affects supported versions, the Node.js project can release patched versions for those active lines. If the same vulnerable code exists in an EOL release, no community patch is published for it.

The vulnerability also becomes publicly documented, meaning attackers can analyze the disclosure while systems on EOL releases remain exposed.

The Node.js project explicitly states that EOL versions should be considered affected when security releases occur.

The official EOL dashboard currently associates Node.js 20 with dozens of high-, medium-, and low-severity vulnerabilities. These counts can continue increasing because the release line no longer receives community fixes.

2. Security Scanners May Underestimate the Risk

Security analysis becomes less precise after End-of-Life.

The Node.js project does not have the resources to evaluate every new vulnerability against every historical release line, each of which may contain different versions of OpenSSL, V8, and other dependencies.

The project therefore treats EOL releases as affected by new CVEs unless evidence shows otherwise.

This is an important distinction for security teams: the absence of a highly specific vulnerability result for an old release does not prove the runtime is safe.

It may simply mean the release is no longer being evaluated.

3. Dependency Updates Become Increasingly Difficult

As frameworks, SDKs, test tools, and libraries stop supporting old Node.js versions, teams must choose between upgrading the runtime or freezing their dependency tree.

Freezing dependencies postpones the migration but creates additional risk:

• Security patches become unavailable.
• New platform integrations cannot be adopted.
• Bug fixes require manual backports.
• Unsupported transitive dependencies accumulate.
• Future migrations become larger and less predictable.

The longer the runtime remains unchanged, the more tightly the entire application becomes coupled to a historical ecosystem.

4. Operating System and Toolchain Updates Can Break the Application

Node.js depends on operating system libraries, compilers, certificate stores, and platform-specific tooling.

An EOL release may not remain compatible with:

• New Linux distributions.
• Updated glibc versions.
• New compiler toolchains.
• New Python versions required by build tooling.
• Updated OpenSSL system libraries.
• New container base images.
• Current CPU architectures.

This can create a difficult operational conflict: the infrastructure must be updated for security, but updating it breaks the unsupported runtime.

Node.js identifies this as toolchain breakage—EOL releases may no longer work with the newer shared libraries required by system updates.

5. Cloud Platforms Eventually Block New Deployments

Cloud providers do not support outdated runtimes indefinitely.

Vercel, for example, announced that Node.js 20 will be disabled for new Builds and Functions deployments on October 1, 2026, following the release line’s End-of-Life on April 30. Existing deployments can continue running, but new deployments targeting Node.js 20 will fail.

This demonstrates an important operational reality:

An outdated runtime can become a deployment blocker even when the application itself has not changed.

Teams that wait until a platform enforcement deadline may be forced to perform a major migration under incident-level time pressure.

6. Compliance and Audit Findings Become More Likely

Many security frameworks and enterprise policies require supported software with an active source of security updates.

An EOL Node.js runtime can create findings related to:

• Unsupported software.
• Missing vulnerability remediation.
• Patch management failures.
• Inadequate lifecycle governance.
• Unresolved high-severity risk.
• Vendor or supply-chain requirements.

The Node.js project explicitly identifies unmaintained runtimes as a compliance red flag.

Even when an application has compensating controls, teams may need to document exceptions and demonstrate how security coverage will be maintained.

Why Delaying the Upgrade Makes It More Expensive

Node.js upgrades rarely become easier with time.

When teams upgrade regularly, the migration surface is relatively narrow:

• Fewer deprecated APIs have accumulated.
• More packages support both the old and new release.
• Maintainers still document relevant breaking changes.
• Native modules are more likely to offer compatible binaries.
• Engineers still understand the affected application architecture.

When teams skip several major versions, they must resolve multiple generations of changes simultaneously.

The migration may then include:

• Runtime breaking changes.
• Framework migrations.
• Dependency replacements.
• Module system changes.
• Native addon recompilation.
• Container and operating system changes.
• CI/CD updates.
• Performance revalidation.
• Cloud runtime migrations.

What initially looked like a way to avoid engineering work becomes a larger modernization project.

Which Node.js Version Should You Use?

For most production teams in July 2026:

Choose Node.js 24 for Most New Production Deployments

Node.js 24 is the current Active LTS release and offers a mature ecosystem with support through April 2028.

It is generally the strongest default when an application does not require Node.js 26-specific functionality.

Use Node.js 22 as a Transitional Target

Node.js 22 remains officially supported through April 2027.

It may be useful when migrating a legacy application in smaller steps, particularly when dependencies are not yet compatible with Node.js 24.

However, its shorter remaining support window should be included in the migration plan.

Test Node.js 26 Now

Libraries, frameworks, and platform teams should add Node.js 26 to CI and compatibility testing.

Application teams can also use it when they need its capabilities and are prepared to follow the Current release cadence. It is scheduled to become LTS in October 2026.

Migrate Away from Node.js 20

Node.js 20 reached End-of-Life on April 30, 2026.

It no longer receives community security updates, and hosting platforms have begun publishing dates for removing deployment support.

Continuing to use Node.js 20 should be treated as a documented exception with an active migration plan—not as a normal production baseline.

A Senior-Level Node.js Upgrade Strategy

A runtime upgrade should be managed as an engineering program, not as a single version change in package.json.

1. Inventory Every Node.js Runtime

Identify the Node.js version used in:

• Production servers.
• Containers and base images.
• Serverless functions.
• CI/CD pipelines.
• Local development environments.
• Build systems.
• Internal CLI tools.
• Scheduled jobs and workers.
• Test environments.

It is common for development and production to run different Node.js versions without the team realizing it.

2. Identify the Application’s Compatibility Surface

Review:

• Direct and transitive dependencies.
• The engines field.
• Native addons and node-gyp usage.
• Deprecated Node.js APIs.
• Framework support policies.
• Build and bundling tools.
• Test runners.
• APM and observability agents.
• Deployment platform runtime policies.

The goal is to identify blockers before changing the production runtime.

3. Upgrade to the Newest Patch Available

Before performing a major migration, move the application to the most recent patch or minor version available within its existing major release.

This separates ordinary patch-level fixes from major-version compatibility issues and provides a more stable migration baseline.

4. Move Through Supported Majors When Practical

For complex applications, migrating from Node.js 18 to 20, then 22, and then 24 can be easier to debug than jumping directly across several major versions.

The intermediate versions do not necessarily need to reach production, but testing each transition can help isolate breaking changes.

Node.js provides official migration guidance and codemods for transitions such as Node.js 20 to 22 and Node.js 22 to 24.

5. Add a Node.js Version Matrix to CI

Test both the current production version and the intended target version.

For example:

strategy:
  matrix:
    node-version:
      - 22
      - 24
      - 26

This helps teams identify incompatibilities before the existing production version approaches End-of-Life.

6. Treat Warnings as Future Failures

Run tests with deprecation visibility enabled:

node --pending-deprecation app.js

For stricter validation:

node --throw-deprecation app.js

Deprecation warnings provide an early opportunity to remove APIs that may become runtime errors in a future major release.

7. Benchmark Before and After

Measure:

• Throughput.
• Response latency.
• CPU utilization.
• Memory consumption.
• Garbage collection behavior.
• Event loop utilization.
• Startup time.
• Native module behavior.

A successful functional test does not prove that the new runtime behaves identically under production load.

8. Roll Out Progressively

Use:

• Canary deployments.
• Traffic splitting.
• Feature flags.
• Fast rollback procedures.
• Runtime observability.
• Error-rate and latency comparisons.

A controlled deployment reduces the impact of issues that only appear with real production traffic and data.

The Node.js Release Schedule Is Changing

Node.js 26 is the final release under the historical model in which even-numbered versions became LTS and odd-numbered versions were short-lived.

Starting with Node.js 27:

• One major version will be released each year.
• Every major version will move into LTS.
• Alpha releases will provide an early testing period.
• Current will run for approximately six months.
• LTS support will continue for approximately 30 months.
• Total support will be approximately 36 months from the initial Current release.

Node.js 27 Alpha is scheduled to begin in October 2026, with Node.js 27.0.0 planned for April 2027.

The new model simplifies the release lifecycle, but the operational requirement remains the same: organizations need a repeatable process for discovering, testing, and deploying new runtime versions.

Find Out What Is Blocking Your Node.js Upgrade

A Node.js upgrade can affect dependencies, native addons, deprecated APIs, security exposure, and deployment infrastructure.

NodeSource’s Node.js Upgrade Program helps teams identify those risks before beginning the migration.

You can start with the free Upgrade Discovery CLI:

npx @nodesource/upgrade

The tool analyzes the application’s dependencies, native C++ addons, deprecated API usage, and potential upgrade blockers locally. It generates a report that can be used to evaluate security and migration risk without sending the application source code.

The result is a clearer answer to the questions that often delay upgrades:

• Which dependencies will break?
• Which native modules need to be recompiled or replaced?
• Which deprecated APIs must be refactored?
• What security exposure exists today?
• What is the safest path to a supported LTS release?

Ready to plan your migration? Learn more about the NodeSource Node.js Upgrade Program: https://nodesource.com/upgrade

Final Thoughts

The risk of an outdated Node.js release is not that the application will suddenly stop running the day after End-of-Life.

The risk is that the application will keep running while:

• New vulnerabilities remain unpatched.
• Dependencies stop supporting it.
• Infrastructure moves beyond it.
• Cloud providers remove it.
• Compliance exposure increases.
• The eventual migration becomes more expensive.

A supported runtime does not eliminate application risk, but it preserves the ability to receive fixes and respond when new problems are discovered.

Running is not the same as supported.

The most effective upgrade strategy is not waiting for an EOL deadline. It is making runtime modernization a predictable part of the application lifecycle.