NVM for Windows v2: a Zig shim, three beta tags, and a commercial tier

The three newest tags are v2.0.1 betas, and the signing note stops at a hotfix of v2.0.0

Start with the release line, because that is where the risk sits. v2.0.1-beta.2 was published on 2026-09-24, beta.3 on 2026-09-25 and beta.4 on 2026-09-27, and the last push to the repository was on 2026-09-27. A stable v2.0.0 sits below them, and the one trust statement in the README is pinned tighter than that: Community Edition installers are code-signed as of v2.0.0-hotfix.2, a hotfix of the older line, with no mention of the betas above it.

Two consequences. An install script that resolves the newest tag gets a beta, not a stable point release, and the beta window is days wide, so behaviour can move under you between two runs of the same installer. And if your policy requires verifying a signature before executing, the tag you verify is not necessarily the tag the installer fetched. Pin an exact tag in any machine-provisioning path rather than following latest.

The release badges point at nvm-windows/nvm, not at the repository you cloned

The repository is coreybutler/nvm-windows on a default branch called master, but the two release badges in the README point at github.com/nvm-windows/nvm/releases/tag/v2.0.0 and at the same path for v2.0.1-beta.4. Announcements live in a third place, the discussions area of the nvm-windows organisation. So the source, the binaries and the announcements occupy three different locations, and only the source sits in the repository you cloned.

That split matters in practice. A build script that pins a git ref gets you Go source and an installer script, not a signed executable, and the repository carries nvm.iss and build.js at the top level without the README describing how to run either. The download you want lives on the releases path under the nvm-windows org, so that is the URL to bookmark and the one to monitor for new tags. For the other paperwork, the repository itself holds CONTRIBUTING.md, SUPPORT.md and a THANKS.md contributor list.

Shim mode is written in Zig while the project is Go, and no default is named

The compatibility row of the feature table holds three claims in one cell, and they pull in different directions. No mandatory administrator privileges. Shim mode, which uses no symlinks and is fast, written in Zig. Link mode, described as zero-latency, using junctions with a symlink fallback. The primary language of the repository is Go, which the project description calls ironic, so the piece of code most likely to sit between you and the node binary is the one component not written in the project's own language.

What is missing is the choice. The README names both modes and does not say which one you get, how to select the other, or what a failed junction falls back to. On a machine where the junction cannot be created, link mode descends to symlinks, and whether Windows allows that depends on policy the README never mentions. The no-administrator claim belongs to the install, not to the runtime path, so treat it as a statement about setup and go looking in the documentation for which mode you actually got.

Per-directory pinning with auto-install turns a checkout into a download

Per-directory version switching is the idea the project leads with under automation, and it is the feature that changes what happens when you open a folder. Alongside it sit auto-install of missing versions, auto-install of default global modules, user-defined aliases, user-defined default global modules, and configuration for local, air-gapped downloads. The speed row adds parallel simultaneous installations, smaller downloads through 7z, native extraction and caching.

Read together, these describe a switch that can hit the network. Enter a directory pinned to a version you do not have and the manager can start a download and an extraction on the spot, and the global-module default means a version switch can trigger package installs as well. On a locked-down or metered machine that is a surprise rather than a decision, and the stated escape is the local download configuration, which the README names without giving a key, a file path or a format for it. The only example file in the repository is examples/settings.txt, and its contents are not reproduced, so the practical route is the documentation site.

No install command in the README, and MSI deployment belongs to the paid build

The whole of the install guidance is three links: the website at nvm-windows.com, the documentation at docs.nvm-windows.com, and announcements in the nvm-windows organisation's discussions. The rewrite from v1 has its own page at docs.nvm-windows.com/features/newv2, and the README flags that the changes from v1 are significant. There is no command, no flag and no package manager line for the free edition anywhere in the file.

Here is where two readers with the same question get different answers. A developer on a laptop follows the website and is done. An administrator whose environment only accepts MSI-based deployment, or who deploys through Microsoft Intune, finds those installers listed exclusively under Certified Builds, the commercial product the README says is coming in September 2026. Nothing in the community edition section offers an MSI path, so an organisation that mandates one is being pointed at a purchase, not at a configuration. Check that constraint before you plan the rollout.

nvm on Mac and Linux is a different project, and its commands do not travel

The README puts this in a collapsed block right under the title: NVM for Windows is not the same thing as nvm. The original nvm, at github.com/nvm-sh/nvm, is a completely separate project for Mac and Linux only, and this one uses an entirely different philosophy and is not a clone of it.

That is a practical warning, not a legal footnote. Configuration, shell functions and the muscle memory that comes with a Mac or Linux setup do not transfer, and the name collision sends every search for nvm to the wrong project first. The same collision happens inside the project's own links: the repository is coreybutler/nvm-windows, while the release tags and announcements belong to the nvm-windows organisation. If you are deciding between tools for a mixed-fleet team, the question is not which nvm is newer but which one the operating system in front of you can run at all, and only this one claims Windows.

SBOM, provenance and VEX reports are add-on packages, and the licence is an unopened file

The commercial column of the feature table is where the governance features live, and the starred ones are sold as add-on packages rather than included. Supply chain artefacts: SBOM, SLSA provenance and VEX reports. Advanced logging: fully auditable, structured, with a dedicated Event Source and native SIEM integration. Policy enforcement: Active Directory and Entra integration, restrictions on which Node.js versions or ranges are allowed, control over nvm-windows, Node, npm and npx settings, proxy support through IWA, WPAD and PAC, and a private download mirror. On the free edition you get the code signature and none of the rest.

The consequence is a policy mismatch rather than a feature gap. A supply chain requirement that asks for provenance or a VEX report cannot be satisfied by the community edition at any version, so the answer to that requirement is a budget conversation. The licence sits in the same gap. A LICENSE file is committed at the top of the repository, but the README names no licence and links none, so what you may redistribute, vendor or ship inside a product is a question you answer by opening that file rather than by reading the project page.

Editorial conclusion

Choose nvm-windows if you are on Windows, want per-directory version switching, and cannot hand out administrator rights. Skip it on macOS or Linux, where the original nvm is the separate project this one is explicitly not a clone of. Before you install, read the v2 change list at docs.nvm-windows.com/features/newv2, confirm whether shim mode or link mode is in force on your machines, because the README names both and states no default, and pin a specific release tag rather than letting the installer take the newest beta.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes