Nvm vs fnm on a Mac — and the question version managers don't ask

The nvm-versus-fnm question has a short answer — fnm does what nvm does, faster — and a longer one worth two more minutes, because the five Node version managers worth using on a Mac in 2026 make genuinely different bets. All of them are actively maintained; none of them is a wrong choice. The interesting split is what they manage: your shell, or your project.

nvm: the standard

nvm install 22
nvm use 18      # this terminal only
echo "22" > .nvmrc && nvm use   # per directory

nvm (94k GitHub stars, still shipping — v0.40.5) is the default answer and the reason .nvmrcfiles exist. Its honest costs: it's a sourced shell script, so it adds noticeable startup time to every new terminal (the lazy-loading workarounds are a genre of blog post unto themselves), switching is per-shell, and nothing switches automatically unless you wire up a hook yourself.

fnm: same model, Rust speed

brew install fnm
eval "$(fnm env --use-on-cd)"   # auto-switch on cd
fnm install 22

fnm (26k stars, v1.39.0) is the upgrade most nvm users eventually make: a single Rust binary, effectively instant shell startup, reads the same .nvmrc (and .node-version) files, and ships --use-on-cdso entering a project directory switches versions without a command. If your workflow is nvm-shaped and your only complaint is speed, switch to fnm and be done — that part of the comparison isn't close.

The other three: Volta, mise, n

Volta (13k stars) moves the pin into package.json: a "volta" key records the Node (and npm/yarn) version, and its shims make the right version run for everyone on the team automatically — the strongest choice when version drift between teammates is the actual problem. mise (29k stars, releasing monthly) is the polyglot successor to asdf: one fast tool managing Node next to Python, Ruby, Go and a hundred other runtimes, happy to read .nvmrc on the way in — the choice if Node is one of many runtimes you juggle. n (19k stars) is the minimalist: n 22 swaps the global Node, no per-project anything — fine on a machine that genuinely needs one version.

The question version managers don't ask

Every tool above manages which node your terminalgets. That's the right abstraction for scripts and one-off commands — and the wrong one for the projects you actually serve. A dev server doesn't care what your shell has linked; it cares what version it was started with, and it needs starting, every time, in the right directory, with the right version, alongside the database and the HTTPS proxy. The shell tools leave all of that to you.

That's the job a managed environment does instead. PortBay (free, open source, macOS) detects each project's Node version, pins it to the project, and runs it as part of the project's stack — start the project and the right Node serves it at https://yourapp.test, next to the per-project database and mail capture; different projects run different versions simultaneously with no shell state involved. It's also what lets an AI coding agent work on the project without inheriting your terminal's version roulette. The honest boundary: PortBay manages projects, not your shell — for ad-hoc npx work in a terminal, keep fnm; the two compose fine. Worth noting while comparing: Laravel Herd gates multi-version Node behind its $99/yr Pro tier, FlyEnv detects package.json versions like PortBay does, and ServBay bundles Node in its polyglot matrix.

How to choose

Happy with nvm but tired of slow shells: fnm, today. Team version drift: Volta. Polyglot runtime juggling: mise. One global version: n. Projects that should just serve with their own pinned version — and maybe have a coding agent working in them: PortBay is a free download, and the PHP version manager guide tells the same story for the other half of your stack.