Install multiple Node.js versions on Windows with NVM for Windows 2

If you maintain more than one Node.js project on Windows, you will eventually need two Node.js versions on the same machine: an older service still on Node.js 22 and a new one on 24. NVM for Windows lets you install several versions side by side, switch between them with one command, and, since version 2, pick the right version automatically per project folder. This guide covers installing it, switching and pinning versions, keeping global packages straight, and fixing the errors people hit most often.

Updated for NVM for Windows 2.0.1 (released 2 October 2026) and the October 2026 Node.js release lines. Commands are taken from the official NVM for Windows documentation for v2; version numbers are from the nodejs.org release index, checked on 10 October 2026.

Which Node.js versions to install

As of 10 October 2026 the supported lines are:

For day-to-day work, install the current LTS line and whatever older line your existing projects still need. Our guide to which Node.js version to use in October 2026 explains the schedule and the move to one major release a year from Node.js 27.

What changed in NVM for Windows 2

NVM for Windows is a separate project from nvm (nvm-sh) for macOS and Linux; the two have different commands. Version 2.0.0 shipped on 2 September 2026 as a full rewrite, and the repository moved from coreybutler/nvm-windows to github.com/nvm-windows/nvm. The changes that matter most for developers:

• No administrator rights needed. v1 created a symlink, which often needed an elevated terminal. v2 installs per user under %LOCALAPPDATA%\Author Software\nvm, and the project says not to run the community installer as Administrator.
• Two operating modes. Shim mode (the default) puts small launchers in front of node, npm and npx. Link mode keeps a v1-style junction.
• Per-project versions. In shim mode, NVM reads .nvmrc, .node-version or the engines.node field of package.json and runs the matching version.
• New commands. nvm pin, nvm default, nvm alias add, nvm env and nvm doctor are new; the v1 command nvm list available is replaced by nvm list releases.

Step 1: Remove any existing Node.js installation

Microsoft's Node.js on Windows guide recommends removing existing Node.js and npm installations before installing a version manager. Uninstall Node.js from Settings > Apps > Installed apps, then check that C:\Program Files\nodejs is gone. The v2.0.1 installer also detects an official Node.js installation and offers to deal with it, but a clean start avoids the most common problem: an old node.exe earlier on PATH than NVM's.

Global npm packages from the old installation live in %APPDATA%\npm. Note what is there (npm ls -g --depth=0) before you uninstall, so you can reinstall the ones you need.

Step 2: Install NVM for Windows

1. Open the releases page and download the setup file for your processor: nvm-2.0.1-x64-setup.exe for most PCs, nvm-2.0.1-arm64-setup.exe for Windows on Arm. Prereleases are marked as such; use the latest stable release.
2. Run it as your normal user. It may show a UAC prompt to register an Event Viewer log source; declining that does not stop NVM working.
3. If you have v1 installed, the v2 setup program migrates it. The old v1 updater cannot upgrade to v2.
4. Open a new PowerShell or Command Prompt window so the updated PATH is loaded.

Step 3: Install Node.js versions

Version specifiers can be lts, latest, a named line such as lts/jod, a major (24), a major and minor (24.21) or an exact version. You can install several at once; v2 downloads them in parallel.

nvm --version
nvm install lts
nvm install 22
nvm list

nvm list marks the default with (default). To see what is available to download, use nvm list releases.

Step 4: Switch versions and set the default

nvm use sets the default version for your user. The old advice to run nvm alias default 18 comes from nvm-sh on macOS and Linux and never worked on Windows.

nvm use 24
node -v
nvm use 22
node -v
nvm default

nvm use last switches back to the previous default, which is handy when you alternate between two projects.

Step 5: Pin a version per project

Switching by hand is easy to forget. In shim mode, pin the version in the project instead, and NVM picks it whenever you run node or npm inside that folder:

cd C:\code\legacy-shop
nvm pin 22 --file=.nvmrc

cd C:\code\new-api
nvm pin 24 --file=package.json

nvm pin resolves the specifier and writes the exact version. For package.json it updates engines.node and engines.npm, and fails if there is no package.json in the current directory. If no pin file is found, the default version runs. The same .nvmrc also drives CI, so laptops and pipelines agree:

# GitHub Actions: read the same pin file the team uses locally
- uses: actions/setup-node@v4
  with:
    node-version-file: '.nvmrc'

Aliases are useful for names that mean something to your team:

nvm alias add legacy 22.23.3
nvm use legacy
nvm alias list

Global packages are per version

Each Node.js version has its own global node_modules. If you install a CLI globally on 22 and switch to 24, it is not there. You can carry the list across when installing a new version:

# Install 24 and reinstall the global modules you had on 22
nvm install 24 --from=22.23.3

# Or copy them across directly
nvm install 24 --copy-from=22.23.3

Also note that Node.js 25 and later no longer bundle Corepack, so on Node.js 26 install pnpm or Yarn explicitly (npm install -g pnpm) or through Corepack installed from npm. For project tools, prefer local devDependencies run with npx over global installs.

Common errors and fixes

For anything else, collect the project's own diagnostics before changing settings:

where.exe node
nvm env
nvm doctor

When not to use NVM for Windows

• Shared machines and build servers. Microsoft's guide notes that NVM is designed per user and per shell, and that several users or build agents on one box can interfere with each other. On CI, use the runner's own setup step (such as actions/setup-node) or a container image with a fixed Node.js version.
• When production runs on Linux. Developing in WSL 2 with nvm-sh, or in a Dev Container, keeps your tooling closer to the server. Our guide to a production Dockerfile for Node.js 24 shows how to pin the runtime in the image instead.
• Managed corporate fleets. The project sells separately licensed Certified Builds with MSI and Intune packages and central policy; use those, or your IT department's packaging, rather than per-user installs.

Alternatives: fnm, Volta and mise

• fnm (Fast Node Manager, 1.39.0) is cross-platform, reads .nvmrc and .node-version, and installs with winget. It needs one line in your PowerShell profile:

winget install Schniz.fnm
# then add this line to your PowerShell profile
fnm env --use-on-cd --shell powershell | Out-String | Invoke-Expression

• Volta is now marked unmaintained in its README; its maintainers recommend migrating to mise. Do not adopt Volta for new machines.
• mise manages Node.js alongside other runtimes and is a reasonable choice if your team also needs Python, Go or Java versions per project.

If your team is juggling several Node.js versions because older services are stuck on end-of-life releases, the real fix is upgrading them. Our application maintenance and support service plans and carries out Node.js upgrades with tests, so every project can run on a supported LTS line.