# Node.js: what the runtime actually is, and how to install it

> Node.js is an open source, cross-platform JavaScript runtime environment governed by the OpenJS Foundation. This article covers what it does, how releases are structured, how to verify a download, and where it is the wrong choice.

**nodejs/node** — Node.js is an open-source, cross-platform JavaScript runtime environment governed openly under the OpenJS Foundation.

- Repository: https://github.com/nodejs/node
- Website: https://nodejs.org
- Stars: 122,156 · Forks: 38,237
- Language: JavaScript
- License: not declared
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/nodejs-node

## The problem Node.js solves, and who ends up using it

The README opens with a single sentence: Node.js is an open-source, cross-platform JavaScript runtime environment. That sentence carries more weight than it looks. The problem it addresses is running JavaScript somewhere other than a browser tab, on more than one operating system, without writing a separate program per platform. The project is governed under an open governance model, and the OpenJS Foundation provides support for it.

The audience is narrower than the download numbers suggest. If you write JavaScript for a browser and never touch a server, Node.js is not the tool you are looking for; it does not provide a DOM. If you write services, build tooling, or scripts that need to run on a colleague's macOS laptop and a Linux CI runner from the same source, this is the runtime that makes that possible. The README points people who need help at .github/SUPPORT.md rather than at the README itself, which is a fair signal that the README is a project document, not a user manual. The user-facing documentation lives at nodejs.org/api/.

## How the release model works, and why the channel matters more than the version

Node.js does not ship one product. It ships three channels, and picking the wrong one is the most common operational mistake.

Current is where development happens. Code for a Current release lives in the branch for its major version number, for example v22.x. A new major version arrives every six months, in April and October, and those majors are allowed to contain breaking changes. Releases that appear in October carry eight months of support. Releases that appear in April convert to LTS the following October.

LTS is the stability channel. Every even-numbered major version becomes an LTS release. Each LTS line gets 12 months of Active LTS support and a further 18 months of Maintenance, for 30 months total. LTS lines carry alphabetically ordered code names beginning with v4 Argon, and the README states there are no breaking changes or feature additions except in some special circumstances.

Nightly is code from the Current branch built every 24 hours when there are changes. The README's own advice is to use it with caution. The directory naming encodes the provenance: version, then UTC date, then the short commit SHA of the release HEAD, so v22.0.0-nightly20240424ddd0a9e494 tells you exactly which commit you have. That is a useful property if you ever have to explain a nightly-only failure.

Current and LTS releases follow semantic versioning, and a member of the Release Team signs each one. The three most recent releases at the time of writing are v26.8.1 and v26.8.0 on the Current line, and v24.20.0 on the LTS line codenamed Krypton.

## Installing Node.js and running a first script

Binaries, installers and source tarballs are published at nodejs.org/en/download/. The README does not give per-platform installer commands, so the exact command depends on which installer you pick; what it does document is the directory layout and the verification path.

The latest directory is an alias for the latest Current release. The latest-codename directory is an alias for the latest release from a named LTS line, so latest-hydrogen points at the newest Node.js 18 release. If you want to pin a download URL rather than follow an alias, use the versioned directory under nodejs.org/download/release/.

Verification is the part worth doing properly. Download directories contain SHASUMS256.txt.asc, which holds SHA checksums for the files plus the releaser PGP signature. First fetch the trusted keyring from nodejs/release-keys:

```bash
curl -fsLo "/path/to/nodejs-keyring.kbx" "https://github.com/nodejs/release-keys/raw/HEAD/gpg/pubring.kbx"
```

Then verify the files you downloaded. The README gives this exact command, where VERSION is the release you fetched:

```bash
curl -fsO "https://nodejs.org/dist/${VERSION}/SHASUMS256.txt.asc" \
&& gpgv --keyring="/path/to/nodejs-keyring.kbx" --output SHASUMS256.txt < SHASUMS256.txt.asc \
&& shasum --check SHASUMS256.txt --ignore-missing
```

The chain is: fetch the signed checksum file, check its signature against the keyring, then check your local files against the checksums. If you imported the releaser keys into your default keyring instead, the README says to pass --keyring="${GNUPGHOME:-~/.gnupg}/pubring.kbx". A successful run ends with shasum reporting OK for each file. If gpgv fails, stop; do not install the binary.

Once Node.js is on the machine, a first script is a single file executed with the node binary. The README does not include a hello-world example, so the runtime's own API documentation at nodejs.org/api/ is the place to look for the module surface you need.

## Where Node.js is the wrong tool

The README is explicit that Node.js is a runtime environment, not a framework. If you want routing, middleware and a request lifecycle handed to you, you are looking for a framework layered on top; Node.js gives you the runtime and the standard library, and nothing else. Choosing it expecting batteries included is a mismatch you will discover on day one.

The release cadence is the second constraint, and it is a real one. A new major version every six months on the Current channel, with breaking changes permitted, means anything pinned to Current needs a recurring upgrade budget. The LTS channel exists precisely to absorb that pressure, but LTS is not frozen forever: 12 months Active plus 18 months Maintenance, then the line is done. A service that cannot schedule an upgrade inside a 30-month window should not be on Node.js without someone owning that calendar.

Nightly builds are the third case. The README tells you to use them with caution, and it means it. They are built from the Current branch every 24 hours when there are changes, which makes them useful for reproducing a bug that only appears on main and unsuitable for anything a user depends on.

Finally, the README is a contributor and governance document. It documents release types, verification, the TSC and the collaborator list. It does not document rollback, installer behaviour per platform, or a migration path between major versions. If you need those, the README will not help you, and you should treat that as a gap rather than assume the information is somewhere obvious.

## How Node.js compares to Deno and Bun

The honest alternative set for a JavaScript runtime is Deno and Bun, and the difference is not speed, it is defaults.

Deno was built by Ryan Dahl, Node.js's original author, and its design starts from permissions: a script gets no filesystem, network or environment access unless it is granted explicitly. Node.js takes the opposite default, where a script runs with the full privileges of the process that started it. That single choice changes how you sandbox untrusted code, and it is the reason teams with a plugin-execution problem sometimes reach for Deno even when the rest of their stack is Node.js.

Bun bundles a runtime, a package manager, a bundler and a test runner into one binary. Node.js ships the runtime and a standard library, and leaves package management to npm, which is distributed alongside it. If you want one tool that does all four jobs, Bun is the closer fit; if you want the runtime to stay a runtime and the tooling to be replaceable, Node.js is the closer fit.

What neither alternative changes is the release discipline Node.js has built: signed releases, an LTS line with a published 30-month support window, and a governance model with a TSC. That structure is the actual reason a large organisation picks Node.js over a faster runtime, and it is the thing to weigh against any performance argument.

## Maintenance cost, upgrade path and licence status

The last push to the repository was on 2026-08-26, and the most recent releases landed the same day: v26.8.1 and v26.8.0 on Current, and v24.20.0 on the LTS line. The project is not archived.

The maintenance cost is set by the channel you choose, not by the project. On LTS you are committing to a line that receives 12 months of Active LTS and 18 months of Maintenance, with no breaking changes or feature additions except in special circumstances. That is a predictable, roughly two-and-a-half-year commitment per major version. On Current you are committing to a new major every April and October, and you should assume breaking changes are possible each time.

The upgrade mechanics themselves are not documented in the README. There is no rollback procedure and no version-to-version migration guide in it. The CHANGELOG.md file sits at the top level of the repository, and the release README linked from the README (github.com/nodejs/Release) is where the project's release information lives. Budget for reading those rather than expecting a single upgrade document.

On licensing: the repository has a top-level LICENSE file, and the README's table of contents ends with a License section, but the licence identifier is not stated in the README. Do not assume a licence from the fact that the project is open source and foundation-backed; read the LICENSE file in the repository before you rely on it. That is a factual gap rather than a legal opinion, and if the licence terms matter to your distribution model, that is a question for your own counsel.

## Conclusion

Adopt Node.js if you are building server-side JavaScript, command-line tooling, or a service that has to run on Windows, macOS and Linux from one codebase, and pick an LTS line rather than Current for anything with a support obligation. Do not adopt it if you need a browser DOM, or if your team cannot absorb a new major version every six months on the Current channel. Before you commit, verify the download against SHASUMS256.txt.asc with the keyring from nodejs/release-keys, and confirm which line your platform's installer puts you on, because the README does not spell that out.

## FAQ

### What is Node.js?

Node.js is an open-source, cross-platform JavaScript runtime environment, according to the project README. The OpenJS Foundation provides support for it, and it operates under an open governance model.

### What is the main purpose of Node.js?

It provides a runtime for executing JavaScript outside a browser, on multiple platforms. The README describes it only as a runtime environment, not a framework, so routing and middleware come from libraries layered on top.

### Is Node.js backend or frontend?

The README positions Node.js as a runtime environment, which is server-side and tooling territory rather than browser frontend work. It does not provide a DOM, so it is not a substitute for the browser runtime.

### Is Node the same as Node.js?

The README uses the name Node.js throughout and does not draw a distinction between the two spellings. The repository is nodejs/node and the homepage is nodejs.org.

### What is the difference between Node.js and Node-RED?

The README covers Node.js only, so it cannot describe Node-RED. What it does establish is that Node.js is a runtime environment with a six-month major release cadence and LTS lines, which is a different category of software from a flow-based tool.

## Sources

- [Official documentation](https://nodejs.org)
- [Official README](https://github.com/nodejs/node#readme)
- [Project repository](https://github.com/nodejs/node)
- [Release notes](https://github.com/nodejs/node/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nodejs-node