nvm vs fnm vs Volta: qué gestor de versiones de Node usar en 2026

Instalar Node.js descargando el binario de la web funciona… hasta que tienes dos proyectos que necesitan versiones distintas: uno atascado en Node 20 y otro en Node 24. Ahí es donde entra un gestor de versiones: te deja instalar varias versiones de Node y saltar entre ellas con un comando, o incluso de forma automática al cambiar de carpeta.

En 2026 hay tres opciones serias: nvm (el clásico), fnm (el rápido) y Volta (el que fija la versión por proyecto). En esta guía las comparamos para que elijas la que encaja con tu flujo. Si además quieres el paso a paso de instalar Node desde cero, lo tienes en cómo instalar Node.js y npm.

¿Por qué necesitas un gestor de versiones?

Sin un gestor, cambiar la versión de Node significa desinstalar y reinstalar el binario cada vez. Con uno obtienes:

• Varias versiones instaladas a la vez, aisladas entre sí.
• Cambio instantáneo con un comando (use 24).
• Cambio automático al entrar en un proyecto que declara su versión en un archivo .nvmrc o .node-version.
• Reproducibilidad en equipo: todos usan la misma versión de Node sin depender de la memoria de cada quien.

nvm — el clásico

nvm (Node Version Manager) es el más conocido y el que verás en la mayoría de tutoriales. Es un script de shell para macOS y Linux.

A favor: ubicuo, documentado hasta el infinito, estable. Si buscas algo en Google sobre versiones de Node, la respuesta casi siempre menciona nvm.

En contra: es relativamente lento (se ejecuta como función de shell y ralentiza el arranque de la terminal), y no funciona en Windows. En Windows existe un proyecto distinto y no oficialmente relacionado, nvm-windows (de coreybutler), con comandos parecidos pero base de código independiente.

nvm install 24     # instala Node 24
nvm use 24         # actívala en la sesión actual
nvm alias default 24

fnm — el rápido (mi recomendación)

fnm (Fast Node Manager) está escrito en Rust, es multiplataforma (Windows, macOS, Linux) y muchísimo más rápido que nvm. Lee .nvmrc y .node-version, y cambia de versión automáticamente al entrar en un directorio.

A favor: velocidad, funciona en los tres sistemas con la misma sintaxis, cambio automático por directorio, arranque de terminal casi sin penalización.

En contra: menos “famoso” que nvm, así que algún tutorial antiguo no lo mencionará.

fnm install 24        # instala Node 24 LTS
fnm use 24            # actívala aquí
fnm default 24        # versión por defecto
node --version        # v24.x.x

Para la mayoría de desarrolladores en 2026, fnm es la mejor opción: la experiencia de nvm pero sin la lentitud y con soporte real de Windows.

Volta — el que fija la versión por proyecto

Volta también está escrito en Rust y es multiplataforma, pero tiene una filosofía distinta: en vez de que tú cambies de versión, fija la herramienta al proyecto. Cuando ejecutas volta pin node@24, escribe la versión en el package.json y, a partir de ahí, cualquiera que abra el proyecto usa esa versión automáticamente, sin comandos.

A favor: reproducibilidad total en equipo (la versión viaja en el package.json), gestiona también npm/pnpm/Yarn y binarios globales, cambio 100% transparente.

En contra: el enfoque de “pinning” puede resultar menos flexible si prefieres controlar tú el cambio manualmente.

volta install node@24   # instala Node 24
volta pin node@24       # lo fija en package.json de este proyecto

Comparativa rápida

Cuánto más lento es nvm, en números reales

«nvm es lento» se repite mucho y sin cifras, así que lo medí en mi propia máquina. Condiciones: WSL2 (Ubuntu) sobre Linux 6.18, bash, seis versiones de Node instaladas bajo nvm, fnm 1.39. Cada cifra es la mediana de 20 corridas abriendo un shell nuevo:

Dos matices para que lo leas con honestidad: la cifra de cambio de versión incluye la carga del gestor, y el coste de nvm crece con cuántas versiones tengas instaladas — con seis tiene que recorrerlas todas, así que quien tenga una o dos verá un número menor. Aun así el orden de magnitud se sostiene: nvm añade unas cuatro décimas de segundo a cada terminal que abres, y cerca de un segundo cada vez que cambias de versión. Si abres muchas terminales al día, esa es la diferencia que de verdad se siente.

¿Cuál elijo?

• fnm — para la mayoría. Rápido, multiplataforma y con cambio automático. Si vienes de nvm, la migración es directa (misma idea, mismos .nvmrc).
• Volta — si trabajas en equipo y quieres que la versión de Node (y del package manager) sea idéntica para todos sin que nadie tenga que pensar en ello.
• nvm — si estás en macOS/Linux, ya lo tienes funcionando y no te molesta el pequeño coste de arranque. No hay razón urgente para cambiar, pero tampoco para empezar con él en 2026.

Migrar de un gestor a otro

Cambiar es sencillo porque todos leen el mismo archivo de versión. Desinstala el anterior (revisa que no queden líneas suyas en tu .bashrc/.zshrc), instala el nuevo y reinstala tus versiones de Node:

# Ejemplo: pasar a fnm
fnm install 20
fnm install 24
fnm default 24

Tus proyectos con .nvmrc seguirán funcionando igual, porque fnm y nvm comparten ese formato.

Lo que se rompe al migrar (y cómo arreglarlo)

Casi todos los problemas tras cambiar de gestor vienen del mismo sitio: dos gestores cargados a la vez, o un paquete global que no viajó contigo.

node --version no coincide con la que acabas de activar. Te quedaron restos del gestor anterior en tu .bashrc/.zshrc y gana el que se carga al final. Comprueba cuál se está usando de verdad y limpia el archivo:

which node          # te dice de qué gestor viene
grep -nE "nvm|fnm|volta" ~/.bashrc ~/.zshrc ~/.profile

Desaparecieron tus paquetes globales. Cada gestor mantiene su propio prefix global y no se comparten — ni siquiera entre versiones de Node del mismo gestor. Lístalos antes de migrar y reinstálalos después:

npm list -g --depth=0    # ejecuta esto ANTES de cambiar

La terminal del IDE usa un Node distinto al de tu terminal. Los editores suelen abrir un shell no-login que nunca lee tu configuración. En VS Code se arregla con "terminal.integrated.defaultProfile.linux": "bash" usando un shell de login (-l); en PhpStorm, revisa Settings → Tools → Terminal → Shell path.

En Windows estás siguiendo las instrucciones equivocadas. nvm y nvm-windows son proyectos distintos con comandos distintos (nvm-windows no soporta .nvmrc, por ejemplo). Si estás en Windows, fnm o Volta te ahorran todo el problema.

Volta ignora tu use. Es el comportamiento esperado: si package.json tiene una versión fijada, gana sobre lo que hagas manualmente. Cámbiala con volta pin node@<versión> en vez de intentar sobreescribirla desde el shell.

Conclusión

Un gestor de versiones deja de ser opcional en cuanto tienes más de un proyecto Node. En 2026 mi recomendación por defecto es fnm por su velocidad y soporte multiplataforma; Volta si priorizas la reproducibilidad en equipo; y nvm si ya vives cómodo con él en Mac o Linux.

Para el resto del setup de Node:

• Cómo instalar Node.js y npm en Windows, macOS y Linux — la guía completa, con instalador oficial y qué versión LTS elegir en 2026.
• Mejores frameworks JavaScript en 2026 — una vez tengas Node listo, elige tu stack.

Preguntas frecuentes

¿Cuál es la diferencia entre nvm, fnm y Volta? nvm es el clásico (script de shell, solo Mac/Linux, estable pero lento); fnm está en Rust, es multiplataforma y mucho más rápido, con cambio automático por directorio; Volta también es Rust y multiplataforma, pero fija la versión en el package.json para todo el equipo.

¿Cuál es el mejor gestor en 2026? Para la mayoría, fnm: rápido, multiplataforma (incluido Windows) y lee .nvmrc. Volta si priorizas reproducibilidad en equipo; nvm si ya lo usas cómodo en Mac o Linux.

¿nvm funciona en Windows? El nvm original no; es un script de shell para Mac y Linux. En Windows existe un proyecto separado, nvm-windows (de coreybutler). Si quieres una sola herramienta para los tres sistemas, elige fnm o Volta.

¿Puedo cambiar de nvm a fnm sin romper mis proyectos? Sí: comparten el formato .nvmrc, así que tus proyectos siguen declarando su versión igual. Desinstala nvm, instala fnm y reinstala las versiones de Node que uses.

¿Qué hace el pinning por proyecto de Volta? volta pin node@24 escribe la versión en el package.json; a partir de ahí cualquiera que abra el proyecto usa esa versión automáticamente, sin ejecutar nada.