npm, Docker o app de escritorio: como probar n8n en local, que diferencias hay en persistencia y esfuerzo, y por que la app de escritorio ya no existe.
Quien quiera probar n8n en local puede elegir hoy entre dos vias oficialmente compatibles: la instalacion mediante npm o el funcionamiento mediante Docker. Ya no existe una app de escritorio independiente, n8n ha descontinuado esta aplicacion y recomienda en su lugar la via de npm. Para una prueba rapida sin una configuracion fija, npm es la mejor opcion; para una configuracion que mas adelante tambien deba servir de base para un funcionamiento permanente, Docker es la opcion mas robusta. A fecha de: julio de 2026.
La instalacion con npm es la forma mas directa de poner n8n en marcha en local. Se requiere una version de Node.js entre 20.19 y 24.x. Con el comando npx n8n se puede probar n8n sin una instalacion permanente, accesible despues en http://localhost:5678. Si desea configurar n8n de forma permanente, instalelo globalmente con npm install n8n -g y luego iniciela con el comando n8n o n8n start. Las actualizaciones se realizan mediante npm update -g n8n, y un downgrade reinstalando una version determinada, complementado en su caso con n8n db:revert en caso de cambios en la base de datos. Por defecto, esta variante almacena credenciales, workflows y ejecuciones pasadas en una base de datos SQLite bajo ~/.n8n/database.sqlite, junto con la clave de cifrado y los archivos de registro en la misma carpeta. Esto es suficiente para una primera impresion o para desarrollar workflows individuales, pero para un funcionamiento permanente con varios usuarios esta carpeta no es una base fiable.
La via de Docker encapsula n8n junto con su entorno de ejecucion en un contenedor y monta un volumen con nombre, de modo que los datos sobreviven a los reinicios. La instalacion basica documentada por n8n primero crea un volumen (docker volume create n8n_data) y luego inicia el contenedor con docker run, montando el volumen en /home/node/.n8n. Aqui tambien n8n usa SQLite por defecto para credenciales, ejecuciones y workflows; por tanto, los datos permanecen en el mismo formato de directorio que en la variante de npm, solo que containerizados y separados del host mediante el volumen. Para escenarios mas orientados a produccion, la base de datos se puede cambiar a PostgreSQL mediante variables de entorno (DB_TYPE, DB_POSTGRESDB_*). n8n senala explicitamente en su propia documentacion que el self-hosting requiere conocimientos tecnicos, por ejemplo para configurar servidores y contenedores, gestionar recursos y proteger el entorno. Si no desea asumir estas tareas usted mismo, n8n remite a su propia variante en la nube como alternativa al self-hosting.
Antes n8n ofrecia una aplicacion de escritorio con la que se podia iniciar n8n en local sin Node.js ni Docker. Esta variante ha sido descontinuada entretanto, el repositorio de GitHub correspondiente esta archivado. En el anuncio oficial, n8n justifica este paso senalando que el uso en la nube y self-hosted crece con fuerza, mientras que la version de escritorio se usaba comparativamente poco y por ello ya no se mantiene. A los usuarios de instalaciones de escritorio existentes se les remite a la via de npm; los workflows y credenciales existentes se pueden trasladar. El codigo fuente sigue siendo publico, por lo que un mantenimiento independiente por parte de la comunidad es al menos tecnicamente posible, pero ya no hay soporte oficial para ello.
Para una prueba breve de workflows individuales o para conocer la interfaz, npx n8n es la entrada mas rapida, sin ningun paso de instalacion. Para el desarrollo local regular, merece la pena la instalacion global con npm, porque los workflows y las credenciales se conservan entre sesiones. En cuanto el entorno deba funcionar durante mas tiempo, integrar varios servicios o crecer mas adelante hacia una configuracion de produccion, Docker es el punto de partida mas razonable, porque el entorno de ejecucion y los datos estan claramente separados y el cambio a una base de datos externa esta preparado. Si no esta seguro de cuantos conocimientos sobre servidores y contenedores hay realmente en su equipo, deberia aclarar esta cuestion antes de decidir, porque n8n deja claro en su propia documentacion que el self-hosting exige un mantenimiento continuo. Con nuestro servicio de automatizacion con n8n asumimos esta valoracion para clientes que quieren decidir por si mismos si una configuracion de prueba local o directamente un servidor en produccion tiene mas sentido.
No. n8n ha descontinuado la aplicacion de escritorio, el repositorio correspondiente esta archivado. Como sustituto, n8n recomienda la instalacion mediante npm.
Segun su propia documentacion, n8n requiere una version de Node.js entre 20.19 y 24.x.
Por defecto en una base de datos SQLite bajo ~/.n8n/database.sqlite, tanto en la instalacion con npm como con Docker, aunque en este caso dentro del volumen montado.
Tecnicamente si, pero n8n senala explicitamente que el self-hosting requiere conocimientos en las areas de operacion de servidores y contenedores, gestion de recursos y proteccion. Por eso, para un funcionamiento permanente suele recomendarse pasar a una base de datos externa como PostgreSQL y tomar una decision consciente a favor o en contra del self-hosting.
NordFlux crea empleados digitales para las organizaciones: automatizaciones y agentes KI que asumen el trabajo repetitivo. Usted mantiene el control.
Cómo probar agentes de IA con evaluaciones de n8n antes del despliegue con clientes: conjuntos de datos de prueba, métricas y LLM-as-a-Judge para workflows fiables.
Cómo instalar n8n con Docker Compose: Postgres en lugar de SQLite, .env, volúmenes y actualizaciones paso a paso.
Pin Data, Mock Data y modo Debug en n8n: cómo probar workflows con datos de prueba fijados en lugar de en vivo contra sistemas de producción.
Una instalación por npm, Docker o la app de escritorio ya descontinuada sirven para una primera prueba, pero ninguna sustituye a un entorno preparado para producción, con persistencia de datos y copias de seguridad. NordFlux acompaña el paso de la instancia de prueba local a una operación gestionada en producción. En una primera conversación determinamos qué opción encaja con su configuración objetivo.
