Why are installations limited to %LOCALAPPDATA% in v2?

[coreybutler]

Several issues (#1383, #1402, #1413, #1420) have been opened around this topic, so I wanted to address it.

[coreybutler]

Yes, NVM for Windows community build installations are limited to %LOCALAPPDATA%. The Node.js installation directory (where your versions are stored) is still configurable.

Why did this change from v1?

Basically, a high concentration of v1 issues were opened due to custom installation paths. Many of these issues were filed with a sense of urgency (i.e. demand) for using NVM for Windows in controlled (corporate) environments. The issues were almost always environment related, not actual bugs. Most fell in the realm of "free enterprise support", which simply isn't sustainable at the scale of this project. These types of issues are why I started Author Software and why we've "separated concerns" between community and commercial certified builds.

Version 2 implements far stronger security mechanisms to combat exploitable areas of v1. This includes managed DACL and ABI guarantees related to the installation root. These are not practical with custom installation directories.

Note

The v1 guidance for installing to custom directories was to avoid protected directories. Symlink creation is often blocked in protected directories. v2 doesn't use symlinks, except in one documented edge case. The old guidance is not relevant to v2.

How is this being addressed going forward?

Users still have control over most aspects of the installation. We've just separated concerns and clarified the scope.

NVM for Windows v2 is available in two different builds.

1. Community Builds: User-controlled installations (free/MIT)
2. Certified Builds: IT-managed installations (commercial/EULA)

The main difference is the architecture. Community build installations are limited to %LOCALAPPDATA% (a user-isolated directory). Certified builds are installed to C:\Program Files (a system protected directory), with user-specific files located in %LOCALAPPDATA%. This allows for machine-level installations with per-user configurations on the same machine. It's also the foundation for applying custom policies for managing and monitoring Node.js usage in controlled environments (corporate, enterprise, government, military, etc.).

Why aren't user-specified directories appropriate installation roots?

It's not that nvm.exe couldn't run from some other directory, it's that there's permission work users would have to do to make it secure. If a random directory like C:\nvm is chosen, there are no inherent protections on that directory by default. Anyone logged into the PC can access it. Windows has the ability to restrict permissions on directories, but many users don't have the rights required (admin) to do it themselves. Many aren't aware this is even a thing. In my opinion, it's not something you should have to worry about.

Rather than fight Windows native permissions, we designed v2 to work within it. The LOCALAPPDATA directory already provides the proper scope of permissions for user installations. C:\Program Files provides the proper scope of permissions for machine-level installations. It's already there. We don't need to recreate a proven guardrail.

How does it work in v2?

The main installation files, like nvm.exe, proxy.exe (module shim), reshim.exe, node.exe (node shim), and sync.exe (optional) are stored in the installation root. proxy.exe is hardlinked into the user .shim directory for each global module when it is installed. node.exe is hardlinked similarly. These are granted appropriate permissions for the user. The shims, which provide modern workflow features, are aware of the Node.js version installation root and their hardlink source. More importantly, they include integrity checks (like digital signature verification) to assure they're actually running the version of Node/module you intend to run. Bottom line: these end-to-end integrity checks assure you "run what you intend to run". This was a critical design goal. It allows modern workflows to run securely, which is especially important as AI agents and vibe-coded tooling are increasingly used autonomously.

Note

In simple terms, nvm-windows makes sure nobody messes with your Node stuff. No malware or errant agent can change your node executable or npm modules without NVM for Windows knowing about it (and making you aware of it). Here's a simplistic example:

Important

BOTTOM LINE: the installation root is part of the overall security posture nvm-windows provides.