How to choose a Node.js version and manage it with nvm

TL;DR: Installing Node.js directly, system-wide, means every project on your machine is locked to that one specific version, and switching between projects with genuinely different Node version requirements (an older project pinned to an earlier LTS release, a newer project needing the current version) becomes a manual, error-prone reinstallation process each time. nvm (Node Version Manager) solves this directly by letting you install and switch between multiple Node.js versions on the same machine with a single command, and, combined with a per-project .nvmrc file specifying the exact required version, ensures you and any collaborator are always running the correct version for whichever specific project you are currently working in.

Why a single, system-wide Node install causes problems

Installing Node.js the straightforward way, downloading and installing it directly from the official source, gives you exactly one Node.js version available system-wide on your machine at any given time, which works fine as long as you only ever work on projects that all genuinely need that same version. In practice, most developers eventually work across multiple projects with different Node.js version requirements, an older, established project that was built against and tested with an earlier version, and a newer project using the latest current release, and switching between them under a single system-wide install means manually uninstalling and reinstalling Node.js each time you switch projects, a genuinely tedious, error-prone, and easy-to-forget process that frequently results in someone accidentally running a project against the wrong Node version without immediately realizing it, sometimes producing subtle, confusing bugs that only manifest due to the version mismatch rather than any actual problem with the project's own code.

What nvm actually does

nvm (Node Version Manager) is a command-line tool that manages multiple, separately installed Node.js versions on the same machine, allowing you to install several specific versions side by side and switch between them with a simple command (nvm use 20, for example, switching your active Node version to version 20), without needing to uninstall or reinstall anything each time. This directly solves the multi-project version conflict problem: each project can specify and use its own genuinely correct, required Node version, and switching between projects becomes a quick, deliberate command rather than a disruptive, manual reinstallation process.

Choosing which Node.js version to actually use

For a new project with no existing version constraint, the general, reasonable default is the current active LTS (Long-Term Support) release, covered in more detail next, which balances having reasonably current features and performance improvements against the stability and extended support LTS releases specifically provide. For an existing project, the correct version is whatever that specific project actually requires, ideally documented directly in the project itself (via a .nvmrc file or in its package.json, covered below) rather than needing to guess or assume based on general current recommendations, since an existing project's actual tested, compatible version may reasonably differ from whatever the current latest recommendation happens to be at any given time.

LTS vs Current: what the distinction means

Node.js maintains two parallel release tracks worth understanding directly. LTS (Long-Term Support) releases receive extended support and stability guarantees over a longer period, specifically positioned and recommended for production use and for most typical application development, prioritizing stability and long-term compatibility over having the very latest features immediately available. Current releases receive the newest features and improvements first but with a shorter support window and generally less emphasis on long-term production stability, more suited to experimentation with new features or for projects that specifically need capability only available in a more recent release not yet included in the current LTS line.

For the large majority of typical WordPress-adjacent Node.js use cases (a custom Node application, build tooling, or a headless frontend covered in our dedicated guide), the current LTS release is the reasonable, standard default choice, with Current releases reserved for situations with a specific, genuine need for very recent features not yet available in LTS.

Setting up nvm and a basic workflow

Installing nvm itself is typically a single command (running the official installation script for your operating system, following nvm's own current documentation for the exact, up-to-date command), after which a typical basic workflow looks like: nvm install 20 installs a specific Node.js version (here, version 20) if not already installed locally. nvm use 20 switches your currently active Node version to that specific installed version for your current terminal session. nvm alias default 20 sets a specific version as your default, so new terminal sessions start with that version active automatically unless a project-specific override (covered next) takes precedence. nvm list shows all versions currently installed locally, useful for confirming what you already have available without needing to reinstall unnecessarily.

Using .nvmrc for per-project version pinning

The genuinely valuable practice that makes nvm particularly effective for real project work: creating a .nvmrc file in a project's root directory containing simply the required version number (20, for example, or a more specific version like 20.11.0), which lets anyone working on that project, including your future self returning to it after working on other projects in between, simply run nvm use (without needing to specify the version manually) while in that project's directory, and nvm automatically reads the .nvmrc file and switches to the correct, project-specific version automatically. Committing this .nvmrc file to your project's version control ensures every collaborator, and any deployment or CI process configured to respect it, uses the genuinely correct, consistent Node.js version for that specific project, directly preventing the version-mismatch class of bugs and confusion that a purely manual, undocumented version convention would otherwise risk.

A comparison table

Factor	System-wide single Node install	nvm-managed multiple versions
Switching between projects with different Node needs	Manual uninstall/reinstall, error-prone	Single command, or automatic via .nvmrc
Setup effort	None, direct install	Small one-time setup, minimal ongoing effort
Risk of running wrong version unknowingly	Higher	Lower, especially with .nvmrc
Team/collaborator consistency	Relies on manual documentation and discipline	Enforced directly via committed .nvmrc file
Best suited for	A single, ongoing project with no version conflicts anticipated	Anyone working across multiple projects or expecting future version changes

FAQs

Does nvm work on Windows the same way as macOS/Linux?

There is a separate, dedicated tool (nvm-windows) providing similar functionality specifically for Windows, since the original nvm project is designed primarily for macOS and Linux shell environments; the core concept and general workflow are similar, though the specific installation and command syntax differ somewhat, worth using the Windows-specific tool rather than assuming the standard nvm installation instructions apply directly.

Does using nvm slow down my terminal or development environment?

Generally negligible impact; nvm adds a small amount of shell startup overhead to load its own functionality, not typically noticeable in practice for standard development use, and the convenience benefit for anyone working across multiple projects considerably outweighs this minor, generally imperceptible overhead.

Can I still install Node.js globally without nvm if I only ever work on one project?

Yes, if you genuinely only ever work on a single project with no anticipated need to switch between different Node.js versions, a direct, single system-wide install remains a perfectly reasonable, simpler choice; nvm's specific value proposition is centered on the multi-version, multi-project scenario, and is not strictly necessary if that scenario does not apply to your actual situation.

Does .nvmrc need to specify an exact patch version, or can it be more general?

Both approaches are valid and commonly used; specifying just a major version (20) gives more flexibility, automatically using whatever latest patch version of that major release you have installed, while specifying a full, exact version (20.11.0) provides more precise, guaranteed consistency across every environment, a reasonable trade-off to make based on how strictly your specific project needs exact version matching versus general major-version compatibility.

How do I know which Node.js version a specific project actually needs if there's no .nvmrc file?

Check the project's package.json file for an engines field, which sometimes specifies a required or recommended Node version range directly, or check the project's own documentation or README; if neither is present, the current LTS version is a reasonable default starting point, adjusted if you encounter specific compatibility issues suggesting a different version is actually required.

Does upgrading to a new Node.js LTS version ever break an existing project?

It can, particularly if the project relies on specific behavior or a dependency that has compatibility issues with the newer version, which is precisely why pinning a specific, tested version via .nvmrc for an established project, rather than always defaulting to whatever the current latest LTS happens to be, protects against this kind of unexpected, disruptive breakage from an environment change unrelated to your own project code.

Is there a similar tool for managing multiple PHP versions, relevant to WordPress development?

Yes, similar version management concepts and tools exist for PHP (and many other languages/runtimes), relevant if you are doing custom WordPress development work needing to test against multiple specific PHP versions, following the same general principle of avoiding a single, inflexible system-wide version constraint across multiple projects with potentially different requirements.

Conclusion

nvm solves a genuinely common, recurring friction point for anyone working across multiple Node.js projects with different version requirements, replacing a manual, error-prone reinstallation process with a quick, deliberate version switch, or, combined with a per-project .nvmrc file, an entirely automatic version match whenever you enter a given project's directory. The current LTS release is the reasonable default choice for most new projects, prioritizing stability and long-term support over having the very latest features immediately available.

Setting up nvm takes only a few minutes, and committing a .nvmrc file to each of your projects going forward is a small, low-effort practice that directly prevents an entire class of version-mismatch bugs and confusion for both your own future work and any collaborators.

HostCloud's VPS plans give you the full root access needed to install and manage nvm and multiple Node.js versions directly, supporting whatever specific version your project requires. See VPS plans at https://hostcloud.in.