How Does NVM Manage Multiple Node.js Versions? Methods for Switching Development Environments Between Node 18, 20, 22, and 24, and Common Issues

As of October 15, 2026, the official Node.js release table lists Node 18 and Node 20 as End-of-Life, and Node 22 and Node 24 as LTS. The practical choice is to install the versions each project requires, switch the current shell to the right one, and verify both node -v and the executable path. Use the NVM implementation built for the operating system in use; commands and project-file behavior differ between implementations. (Node.js release table)

This guide is for developers who maintain projects on different Node.js versions, test compatibility across Node 18, 20, 22, and 24, or need to configure a remote Mac terminal. It also covers what to check when a shell still finds an old Node.js installation or does not recognize nvm.

Status check: Node 18 and Node 20 may still be needed for legacy compatibility tests, but the official release table marks both EOL. A successful installation does not mean a release line still receives security fixes. Check the status again before selecting a runtime for production.

Last updated October 15, 2026; release status was checked against the official Node.js release table, and command behavior against the POSIX NVM project documentation.

Choose the NVM implementation for the operating system

“NVM” can refer to different tools. The POSIX shell project is commonly used on macOS, Linux, and Windows Subsystem for Linux. Its nvm command is a shell function, so the active shell must load it. Native Windows users typically need a Windows-specific implementation instead. Do not paste a POSIX shell installation command into a Windows command prompt and expect the same setup or project-file behavior. The Windows-specific NVM documentation describes a separate implementation and setup.

The comparison below is an editorial fit rating for these workflows, not a performance benchmark:

For macOS development, the commands below use POSIX nvm. Its documented platforms include macOS, Unix-like systems, and WSL; that does not make it a native Windows command-line tool. The Windows-specific documentation describes a separate setup and switching model. Use that implementation’s instructions if the terminal is running native Windows.

Install and inspect Node 18, 20, 22, and 24

On macOS, first make sure the POSIX NVM function loads in the shell you actually use. The official setup adds NVM initialization to a shell profile such as ~/.zshrc or ~/.bash_profile. After installation, open a new terminal or load the matching profile, then check NVM with command -v nvm. The command which nvm is not a reliable check for this implementation because NVM is a shell function, not a standalone executable.

Once NVM is available, install the required major lines. In a POSIX shell, a major number selects the latest available release matching that line:

nvm install 18
nvm install 20
nvm install 22
nvm install 24

Installing all four is optional. If a project only needs Node 20, install that line first and add others when another project or a compatibility test requires them. For a repeatable setup, pin a full version, such as 22.x.y, in the project file or team documentation rather than relying on a moving major-version selector.

Use nvm ls-remote 22 to inspect remote releases, nvm ls to list locally installed versions, and node -v and npm -v to inspect the active runtime and package manager. These commands and version-selection behavior are covered in the POSIX NVM usage guide.

If a version appears in nvm ls-remote but not in nvm ls, it is available remotely but is not installed locally. Install it before trying to switch to it. Keep that distinction in mind when a command reports that a version is unavailable: a remote listing is not proof that the current shell can already use that runtime.

Switch a shell version without changing the default

To use a version only in the current terminal session, run:

nvm use 18
node -v
command -v node

Replace 18 with 20, 22, or 24 as required. In POSIX NVM, nvm use updates the shell’s PATH; another terminal that was already open can retain its own active selection. This is useful for running a legacy test suite without changing the default version used in newly opened shells.

A default version serves a different purpose. It is the version POSIX NVM selects when a new shell starts, unless project-specific instructions or shell customization change that behavior:

nvm alias default 22

After setting it, open a fresh terminal and run:

nvm current
node -v
command -v node

Do not rely only on the current terminal as proof that the default changed: an earlier nvm use 18 may still be active in that shell. To identify the executable NVM expects for the selected version, run nvm which current. Check the new terminal as well as the current one, because that is where the default alias should be applied.

Bind each project to its required Node.js release

A project version file reduces accidental switching between repositories. In a POSIX NVM setup, create .nvmrc in the project root with the chosen version:

cd path/to/project
printf '22\n' > .nvmrc
nvm install
nvm use
node -v

For a project that needs a specific patch release, put that full version in .nvmrc instead. Commit the file so teammates and automation can select the same version. POSIX NVM searches from the current directory upward for .nvmrc; nvm use reads it when no version is supplied. If the requested release is not installed, nvm install can install and activate the version specified by the file.

The version file does not make every terminal switch automatically when you enter the project folder. Automatic switching needs additional shell configuration or a compatible integration. Without that, run nvm use after entering the project directory. This explicit step is often safer in remote terminals and build scripts because it makes the selected version visible in the command history.

The POSIX project documentation includes optional shell recipes for automatic switching when changing directories. Treat those recipes as shell-specific customization, not a universal NVM default. Native Windows users should follow their selected Windows implementation’s documentation; a shared .nvmrc file is useful only if the local tooling reads it.

Troubleshoot an old version or an unrecognized command

If switching appears to succeed but node -v reports an unexpected version, work through these checks in order:

1. Confirm NVM is loaded in this shell. Run command -v nvm. If it prints nothing, check whether the active shell profile sources NVM. A terminal may start a different shell or read a different profile from the one edited. Open a fresh terminal or source the correct file, then test again.
2. Confirm the requested version is installed. Run nvm ls. If the required line is missing, install it before trying to use it. Do not confuse the remote release list with local installations.
3. Switch from the project directory. Run nvm use 22 for an explicit test, or nvm use if the project has an applicable .nvmrc. Then immediately run node -v.
4. Inspect command resolution. Run command -v node and nvm which current. If the results point to different locations, or the active path points to a separately installed Node.js, inspect the shell’s PATH order and remove or reorder conflicting initialization entries. POSIX NVM changes PATH; another setup can override that change if it runs later.
5. Check global tools after switching. Global npm packages should not be assumed to appear under every Node.js version managed separately. Run npm list -g --depth=0 under the selected runtime, then install only the tools that project needs. npm’s guide to installing packages globally explains how these command-line tools are installed for local use.

If nvm works in an interactive terminal but disappears in an IDE task, remote command, or script, compare how each process starts its shell. Non-interactive shells may not load the same profile files. Configure that process to load NVM explicitly, or pass a deliberate version and executable path instead of assuming it inherits the interactive terminal’s state.

Verify the setup in a remote Mac terminal

A remote Mac adds another boundary: NVM belongs to the user and shell environment where it was installed. A login shell, an IDE-integrated terminal, and a remote command can each initialize differently. A successful switch in one terminal does not prove that the project runner uses the same Node.js executable.

Use this repeatable verification sequence in the remote Mac session:

1. Open the project directory and read its .nvmrc, if present.
2. Run command -v nvm to confirm that the current shell loaded NVM.
3. Run nvm use to select the project version, or nvm use 24 when testing that release line.
4. Record node -v, npm -v, command -v node, and nvm which current.
5. Run the project’s install, build, or test command from that same terminal. Repeat the checks in any IDE or remote task that will run the project.

These checks establish what the shell selected; they do not prove application compatibility. Run the project’s own build and test commands on each required version, and record failures by version so an old runtime issue is not confused with a PATH problem.

As of October 15, 2026, Node.js lists Node 22 and Node 24 as LTS, while Node 18 and Node 20 are EOL. For maintained applications, use a currently supported release unless the project’s compatibility requirement says otherwise. Keep EOL versions for a specific legacy test or migration check, and document why they remain in the test matrix. Recheck the official release table when choosing versions because support status changes over time.

For remote setup details, review Zilmac’s Mac support information alongside the shell checks above. Environment details can vary by session, so verify NVM and Node.js in the actual terminal rather than assuming a particular runtime is preinstalled.

A short switch-and-verify checklist

Before running a project command, confirm:

• The project’s required version is written down or pinned in .nvmrc.
• The active terminal has loaded the intended NVM implementation.
• nvm current and node -v agree with the project requirement.
• command -v node resolves to the runtime selected by NVM.
• Required global tools exist under that version, or the project invokes its local dependencies.
• The project’s tests run in the same terminal where the version was verified.

If a local Mac already has a correctly configured shell and enough capacity for ongoing work, keeping development local may be simpler than introducing a remote environment. A fixed system Node.js installation can be harder to isolate between projects, and remote shells can expose profile or PATH mismatches that need deliberate setup. For temporary remote Mac development or a clean environment for validation, compare those trade-offs with the environment details Zilmac publishes on its remote Mac service page before choosing. Do not assume a remote Mac has NVM or a particular Node.js release preinstalled: verify the shell, project version file, and executable path in the session itself.