nvm: Node.js Version Manager for Shells

What is Node Version Manager (nvm)?

Node Version Manager (nvm) is a POSIX-compliant shell script — not a compiled binary — that you source into bash, zsh, ksh, dash, or another POSIX shell to install and switch between Node.js versions. It runs per-user and per-shell: cloning itself into ~/.nvm (or your $XDG_CONFIG_HOME), then loading as a shell function, so commands like nvm use only change the active node in that one shell session.

Key Capabilities of nvm

• ✓Version switching in one line: `nvm install 24`, `nvm use 22`, and `nvm use 20` each swap the node on $PATH for that shell session, per the README's own example.
• ✓Built-in aliases beyond raw version numbers — node (latest), iojs (latest io.js), stable/unstable (legacy pre-1.0 aliases), and current (whatever's active right now, unaffected by .nvmrc).
• ✓LTS-line targeting with lts/* for the newest LTS or lts/argon for a specific codename release line, usable across install, uninstall, use, exec, run, and ls-remote.
• ✓Package migration flag --reinstall-packages-from=<version> reinstalls your global npm packages onto a freshly installed Node version without silently bumping npm itself.
• ✓nvm exec and nvm which let you run one command against a specific Node version in a subshell, or just print the path to that version's binary, without switching your whole shell.
• ✓Install script accepts NVM_SOURCE, NVM_DIR, PROFILE, and NODE_VERSION overrides, plus a --no-use flag to install without activating a version immediately.

Installing and Updating nvm

To install or update nvm, the README points to running its install script via a one-line curl or wget command. That script clones the nvm repository into ~/.nvm (or $XDG_CONFIG_HOME/nvm if that variable is set) and tries to append the right source lines to your profile file — ~/.bashrc, ~/.bash_profile, ~/.zshrc, or ~/.profile — falling back to whichever the $PROFILE env var points at if it picks the wrong one. You can override the install source, directory, profile, and version via NVM_SOURCE, NVM_DIR, PROFILE, and NODE_VERSION, add --no-use to skip auto-activating a version, or set PROFILE=/dev/null to stop it from touching your shell config at all. A manual git install works too, but the README sets a minimum required git version of v1.7.10 for cloning and tag checkout. Verify the install with `command -v nvm`, not `which nvm`, since nvm is a sourced shell function rather than an executable binary. The README also documents a Docker pattern that sources nvm via the BASH_ENV variable for non-interactive containers.

Managing Node.js Versions with nvm

Install a specific version with `nvm install <version>`, or use the node alias for the latest release — the first version you install becomes the default for new shells. `nvm use <version>` switches the active version in your current shell, `nvm run node --version` runs node directly, and `nvm exec <version> <command>` runs any command in a subshell against a chosen version without switching your shell's default. `nvm which <version>` prints the path to that version's installed binary. `nvm alias <name> <version>` sets a custom alias (no spaces or slashes allowed), and `nvm ls-remote` lists versions available to install. LTS flags (--lts, --lts=argon, 'lts/*', lts/argon) work across install, uninstall, use, exec, run, and ls-remote. To move to the latest LTS while carrying over your currently installed packages, the README gives `nvm install --reinstall-packages-from=current 'lts/*'`.

Alternatives for Specific Platforms and Shells

Frequently Asked Questions about nvm

The problem it solves

Different projects on the same machine often need different Node.js majors — one still pinned to an LTS line, another testing the latest release — but a single system-wide Node install (via apt, a Windows installer, or Homebrew) only gives you one version at a time, and switching it usually means sudo and manual reinstalls. nvm addresses this by installing Node under your home directory per-user and loading a specific version into each shell session, so `node -v` can report something different in two terminal tabs without touching the OS package manager.

Best use cases

• •Keeping several Node majors installed side by side on one dev machine and switching per terminal tab with nvm use <version>, per the README's own example.
• •Non-interactive Docker builds that need a pinned Node version — the README documents sourcing nvm via BASH_ENV since profile files aren't read in non-interactive shells.
• •Bumping a project to a new Node release while carrying over globally installed npm packages via --reinstall-packages-from.
• •Referring to LTS lines generically (lts/*, lts/argon) in scripts or .nvmrc files instead of hardcoding a version number that goes stale.

Who should try it — and who should skip

Reach for nvm if you're a developer on macOS, Linux, or WSL2 working across projects that pin different Node majors, and you want to switch versions per terminal without a system-wide reinstall or sudo. Skip it if you're on native Windows without WSL — use nvm-windows, nodist, or nvs instead — or if you use Fish shell, where the README points you to nvm.fish or fish-nvm; also skip a Homebrew-installed copy, since the README says that path isn't supported.

Related repositories