dev-tools 4 min read

nvm: Manage Multiple Node.js Versions the Bash Way

nvm is a POSIX-compliant bash script for switching between Node.js versions. What a 95,000-star, sixteen-year-old tool still does that package managers do not.

By
Share: X in
GitHub social preview card for nvm-sh/nvm

TL;DR: nvm is a POSIX-compliant bash script for managing multiple active Node.js versions. It has 95,467 stars, 10,518 forks and 382 open issues, it is MIT licensed, and it has been maintained continuously since April 2010.

What it is

The repository description is one sentence long and it is sufficient: a POSIX-compliant bash script to manage multiple active Node.js versions. That sentence is also the whole architecture. There is no daemon, no service, no system-level package manager. You source a shell function into your shell and you have a version switcher.

Sixteen years of continuous development is the first thing worth noticing. The repository was created on 2010-04-15 and last pushed code on 2026-10-10. A large share of the tooling from that era has since been replaced by something else. The default branch is still master.

$ curl -s https://api.github.com/repos/nvm-sh/nvm \
  | jq '{stars: .stargazers_count, language, license: .license.spdx_id, topics, created_at}'
{
  "stars": 95467,
  "language": "Shell",
  "license": "MIT",
  "topics": ["bash","install","lts","node","node-js","nodejs"],
  "created_at": "2010-04-15T17:47:47Z"
}

The lts topic is the tell. Node.js ships a long term support line that changes on a fixed schedule, and a tool whose entire job is tracking every version you might install has to be updated continuously or it quietly serves stale runtimes. Sixteen years of commits is that maintenance record, made visible.

It is also written in Shell, which stands out on a trending page otherwise dominated by Python and Rust. Version management is something most people configure once per machine, which is exactly the usage profile of a tool that accumulates stars slowly and then never gives them back.

How to try it

git clone https://github.com/nvm-sh/nvm.git
source nvm.sh          # load the shell function
nvm install 22         # install a specific Node.js version
nvm use 22             # switch the active version
nvm ls                 # list what is installed and available

Common subcommands worth knowing:

  • nvm install and nvm use for adding and selecting versions
  • nvm ls to see what is installed and what can be
  • nvm alias default 22 to pin what a new shell picks up
  • nvm which 22 to print the resolved binary path, which helps in CI logs

Because it is a shell function rather than an installed binary, the version switch only exists in shells where you have sourced it. That is simultaneously the design’s main constraint and its main advantage: nothing is installed system-wide, so removing it means deleting a directory.

What the numbers say

MetricValue
Stars95,467
Forks10,518
Open issues382
Primary languageShell
Created2010-04-15
Last push2026-10-10
LicenseMIT

Open issues sit at roughly 0.4 percent of stars. On a project this old that usually means the issue tracker is not where the ongoing work shows up. The work is in the commits.

When to use it

Reach for it when you genuinely move between more than one Node.js version in a normal week. A legacy service pinned to an older major, a library bug you need to reproduce on an older runtime, a CI matrix you want to run on your own laptop. Switching versions is the entire job, and it does that job without dragging a package manager into it.

It is also the cleanest fix for a machine where Node arrived through a system package manager or as a binary copied into a directory. nvm gives you one predictable place where runtimes live.

When not to use it

If you install Node once and never change it, nvm is extra shell configuration to debug for no benefit. The value only materialises at the moment you switch.

Shell function scoping is the other limit, and it catches people. A version change does not follow you into cron jobs, container builds, CI runners or IDE subprocesses unless each of those sources nvm itself. If you assumed nvm use changed the machine, it changed one shell.

Source and Accuracy Notes

  • Source repository: nvm-sh/nvm (verified via GitHub API html_url)
  • License: MIT (verified via GitHub API license.spdx_id)
  • Stars at time of writing: 95467