Node.js Downloads Surge in 2026 as Node.js 24 Takes the Lead

by:

in Node.js on Aug 27 2026

Node.js

2026 is shaping up to be a remarkable year for Node.js download activity. Through July, downloads recorded through the official Node.js distribution infrastructure have already surpassed the total recorded during all of 2025: 4.61 billion downloads in the first seven months of 2026, compared with 4.48 billion across the entire previous year. That puts 2026 roughly 128 million downloads ahead of the 2025 total, with five months still left in the year.

Figure 1. Node.js recorded 4.61 billion downloads from January through July 2026, already surpassing the 4.48 billion recorded throughout all of 2025. Source: Node.js Download Metrics, aggregated by Matteo Collina’s Node.js Download Statistics project (https://github.com/mcollina/nodejs-download-stats/).

The growth is interesting on its own, but the version mix tells an even more useful story. In July, Node.js 24 was the most downloaded major version in the official Node.js download data, reaching approximately 358.8 million downloads. Node.js 22 followed with 283.9 million, while Node.js 20 still accounted for more than 103.7 million downloads despite reaching End-of-Life earlier this year.

Figure 2. Node.js 24 led major-version downloads in July 2026 with 358.8 million downloads, followed by Node.js 22 with 283.9 million. Source: Node.js Download Metrics, aggregated by Matteo Collina’s Node.js Download Statistics project (https://github.com/mcollina/nodejs-download-stats/).

Seeing Node.js 24 at the top is an encouraging signal. It is a currently supported LTS release, so its growing share of download activity suggests that a meaningful part of the ecosystem is moving toward a modern, actively maintained runtime baseline. The timing is particularly relevant as Node.js 26, currently the Current release, approaches its transition to LTS later this year.

N|Solid Runtime is showing similar momentum. From January 2024 through July 2026, NodeSource Distribution Stats recorded more than 2.23 million N|Solid Runtime downloads across 190 countries and territories, while 2025 download volume grew 229.4% compared with 2024. With only seven months of data, 2026 is already approaching the full N|Solid download volume recorded during 2025.

Figure 3. N|Solid Runtime download activity has accelerated significantly since 2024, with 2026 already approaching the full 2025 total through July. Source: NodeSource Distribution Stats (https://distributions.nodesource.io/?year=all&package=nsolid).

Taken together, these numbers show strong download activity across both Node.js and N|Solid Runtime, while supported LTS releases are gaining ground. But the data also reveals an important contrast: modernization is not happening everywhere at the same pace. But the data also reveals an important contrast: modernization is not happening everywhere at the same pace.

Older, unsupported Node.js versions continue to generate substantial download activity. That does not necessarily mean developers are consciously choosing an EOL runtime every day. In many cases, those versions are already embedded in Docker images, CI pipelines, build systems, version managers, and deployment infrastructure, where they can continue to be downloaded automatically long after the original version decision was made.

That is what makes the latest download data worth examining. It does not simply tell us that Node.js is growing; it gives us a view into how quickly the ecosystem is moving toward supported releases—and where legacy runtime decisions are still holding applications back.

What the 2026 Download Data Is Actually Telling Us

Before drawing conclusions from the numbers, it is worth clarifying what a “download” actually represents. A download does not necessarily map to a unique developer, a production server, or even a brand-new Node.js installation. Runtime packages can be pulled automatically by CI/CD pipelines, Docker builds, ephemeral runners, developer machines, version managers, cloud build systems, provisioning tools, and other parts of the software delivery process.

That makes the data useful in a different way. Rather than treating downloads as a proxy for the number of Node.js users, they are better understood as a signal of runtime activity across development and infrastructure workflows. If a release continues to generate large numbers of downloads month after month, that version may still be actively rebuilt, deployed, or provisioned throughout real software delivery systems.

This distinction becomes particularly important when looking at the version mix. A runtime can remain highly active even when nobody is consciously choosing it anymore. A Node.js version pinned years ago in a Dockerfile, CI configuration, base image, or version manager can continue generating downloads every time that environment is recreated.

So the interesting story behind the 2026 numbers is not simply that Node.js download activity is growing. It is that download activity is increasing while the runtime mix is changing, giving us a useful view into how quickly applications and infrastructure may be moving toward supported releases.

Why Node.js 24 Taking the Lead Matters

Node.js 24, codenamed Krypton, was released in May 2025 and is now an LTS release. Seeing it lead the July download data is therefore more meaningful than watching one version number overtake another: it suggests that a growing share of Node.js activity is landing on a modern, actively maintained runtime baseline.

There are meaningful technical changes behind that transition. Node.js 24 introduced V8 13.6, npm 11, URLPattern as a global API, improvements to the Permission Model and test runner, changes to AsyncLocalStorage, and Undici 7, alongside new platform requirements and deprecations. Moving to a supported release also means continuing to receive the security and maintenance updates provided throughout the Node.js release lifecycle.

Node.js 26 is already showing what comes next. Released in May 2026, it includes Temporal enabled by default, V8 14.6, Undici 8, and further runtime modernization. It is scheduled to transition to LTS in October 2026, giving application and library maintainers time to evaluate compatibility before broader production adoption.

The current pattern is therefore encouraging: Node.js 24 is seeing strong download activity while Node.js 26 is already available for testing. The challenge is that not every application is moving along that path at the same pace.

Modernization Is Growing, but Legacy Runtime Activity Has Not Disappeared

Node.js 20 reached End-of-Life on April 30, 2026, while Node.js 18 reached EOL a year earlier, on April 30, 2025. Yet both releases continue to appear prominently in download data. In July alone, Node.js 20 and 18 accounted for more than 136 million downloads combined in the official Node.js download data.

This does not necessarily mean millions of teams deliberately chose an unsupported runtime in July. In many cases, the choice may have been made months or years ago and then encoded into infrastructure.

A Dockerfile may still contain:

FROM node:20

A CI workflow may still specify:

- uses: actions/setup-node@v4
  with:
    node-version: 20

An .nvmrc, build image, Terraform configuration, or internal deployment template can preserve the same decision indefinitely. Every clean build or new CI runner can then request that runtime again, even though nobody actively revisited the version choice.

This is what makes EOL activity important from an engineering perspective. An old Node.js release can be legacy and highly active at the same time. It may be powering applications that are rebuilt every day, deployed hundreds of times per month, and continuously recreated in ephemeral infrastructure.

The Node.js project is very clear about what changes once a release reaches End-of-Life. EOL lines no longer receive updates, including security patches. Over time, they can also face toolchain breakage, ecosystem drift as packages remove support, and compliance issues in environments that prohibit unmaintained runtimes.

The risk is subtle because reaching EOL does not make an application immediately stop working. Tests may continue passing, health checks may remain green, and production traffic may look completely normal. What changes is the ability to rely on the upstream Node.js project when new bugs or vulnerabilities are discovered.

That difference becomes more important the longer an application stays behind.

The Cost of Waiting Is Usually Bigger Than the Version Change

For many engineering teams, postponing a runtime upgrade can feel safer than changing a stable production system. If the application works today, it is understandable to ask why the runtime needs attention now.

The problem is that the rest of the ecosystem does not stay still. Dependencies move to newer Node.js requirements, operating systems and container images evolve, native addons adopt newer toolchains, cloud platforms retire older runtimes, and deprecated Node.js APIs eventually become migration blockers.

What begins as a relatively contained runtime upgrade can gradually turn into a broader modernization project.

A team moving from Node.js 20 to Node.js 24, for example, may need to evaluate far more than the executable itself. Direct and transitive dependencies may have changed their supported engines. Native C or C++ modules may need to be rebuilt or replaced. Deprecated runtime APIs may need refactoring, and changes to V8, OpenSSL, networking behavior, build environments, or CI images can surface compatibility issues that application-level tests alone do not reveal.

This is why a production Node.js upgrade is rarely just:

node --version

The more useful question is: what stands between this application and a supported runtime?

Find the Upgrade Blockers Before Changing the Runtime

This is the problem the Node.js Upgrade Program, developed by NodeSource in partnership with the OpenJS Foundation, is designed to address. The goal is not simply to tell teams that they should upgrade; it is to make the path to a supported release easier to understand before changes reach production.

Node.js's own EOL documentation recognizes that organizations can be prevented from upgrading immediately by legacy applications, complex dependency chains, and other operational constraints. The project's official EOL page lists NodeSource as a commercial support provider through the OpenJS Ecosystem Sustainability Program and specifically describes the NodeSource Upgrade Program as providing risk analysis, migration-blocker identification, and upgrade roadmaps.

Teams can begin with the free Upgrade Discovery CLI:

npx @nodesource/upgrade

The scan runs in the application's environment and analyzes direct and transitive dependencies, native C/C++ addons, and static Node.js API usage to help identify potential migration blockers before the runtime is changed. The resulting discovery data can then be used to evaluate security and upgrade risk, deprecated APIs, native addon conflicts, vulnerable dependencies, and other compatibility concerns.

That changes the starting point of an upgrade. Instead of installing a new Node.js version and waiting to discover what breaks, teams can first understand where the risk is, what needs attention, and how much work the migration is likely to require.

Get your free Node.js Upgrade Assessment →

A Healthy Trend—and a Useful Reminder

The 2026 distribution numbers are encouraging. In the official Node.js download data, activity through July has already surpassed the total recorded during all of 2025, while Node.js 24 reached the top position for the first time. N|Solid Runtime download activity also continues to accelerate, and Node.js 26 is preparing for its LTS transition this fall.

Together, these trends show download activity increasingly concentrating around newer, actively maintained releases.

At the same time, continued activity around EOL runtimes is a reminder that modernization rarely happens everywhere at once. Node.js versions can remain embedded in Dockerfiles, CI pipelines, build infrastructure, dependencies, and production environments long after their official support window ends.

For teams already running Node.js 24, the current data is a good sign of where the ecosystem is heading. For teams still relying on Node.js 20, Node.js 18, or an even older release, it is an opportunity to understand the upgrade path before security pressure, infrastructure changes, or dependency incompatibilities make the decision for them.

The ecosystem is moving forward. The most important question is whether your applications have a clear path to move with it.

The NodeSource Blog