2. Exportar con la CLI de n8n

Descripción

Al terminar esta lección vas a poder exportar cualquier workflow de tu instancia con un comando en la terminal, sin tocar el editor: uno solo por su identificador, o todos de una vez, cada uno en su propio archivo. Vas a saber qué es la CLI de n8n, cómo se corre según si tu instancia está instalada con npm o dentro de Docker, y qué hace cada una de las banderas de n8n export:workflow. Y vas a entender el error más silencioso de todos —exportar contra una instancia vacía y creer que no tienes workflows— y cómo evitarlo.

Esto importa porque la exportación es el primer eslabón de toda la cadena del módulo. Todo lo que viene después —separar credenciales, normalizar, estructurar, documentar, automatizar— opera sobre el archivo que produces aquí. Si este paso no es reproducible, nada de lo demás lo es. Y hay un detalle práctico: la exportación por comando es la única que se puede automatizar y meter en un script, que es a donde llegamos en la lección 7. El botón del editor no se puede automatizar; un comando, sí.

Conexión con el módulo: la lección 1 te mostró por qué el botón de descarga del editor produce servilletas. Esta te da la herramienta que produce recetarios: la CLI. Aquí exportas los workflows; la lección 3 exporta las credenciales, que son un caso aparte y peligroso. La lección 4 toma el JSON que sacas aquí y lo normaliza. Así que presta atención a la forma exacta de la salida, porque en la próxima lección la vamos a ensuciar a propósito para aprender a limpiarla.

Sobre las banderas y las versiones. Esta guía se escribió con n8n 2.x en julio de 2026. n8n publica versiones menores casi cada semana, y de vez en cuando ajusta el comportamiento de un comando. Todas las banderas que verás aquí las confirmé contra la documentación oficial en esa fecha, y te voy a decir cuáles. Aun así, adopta desde ya un hábito que vale oro: antes de confiar en una bandera, corre n8n export:workflow --help en tu propia instancia. Ese comando imprime la lista real de banderas de tu versión. Si algo de esta guía no coincide con lo que te muestra el --help, tu instancia manda. No es que la guía esté mal; es que el software se mueve.

Qué es la CLI de n8n

Empecemos por el nombre. CLI son las siglas de command-line interface, interfaz de línea de comandos. Es la forma de darle órdenes a un programa escribiendo texto en una terminal, en lugar de hacer clic en botones. Ya usaste una CLI en el Módulo 2 sin llamarla así: cada vez que escribiste git commit estabas usando la CLI de Git.

n8n, además de su editor visual en el navegador, trae su propia CLI. Es el mismo n8n, con las mismas capacidades, pero manejado por comandos. Mientras el editor es bueno para construir workflows —arrastrar nodos, conectar, probar—, la CLI es buena para operar sobre ellos en lote: exportarlos todos, importarlos, moverlos entre instancias. Son dos puertas a la misma casa.

Piénsalo como la diferencia entre el mostrador de una tienda y su almacén. En el mostrador (el editor) atiendes de a un cliente, con calma, viendo cada producto. En el almacén (la CLI) mueves cajas enteras de una vez con un montacargas. Nadie hace el inventario completo del almacén atendiendo cliente por cliente en el mostrador; para eso está el montacargas. La CLI es tu montacargas.

Anatomía de un comando de la CLI

Antes de correr nada, veamos cómo está armado un comando, porque una vez que reconoces las piezas, todos los comandos de la CLI se leen igual. Toma este, que es el que vas a correr en un momento:

n8n export:workflow --all --output=./workflows --separate --pretty

Cuatro tipos de pieza:

• n8n — el nombre del programa. Le dice a la terminal: "llama a n8n". Es como decir git para llamar a Git.
• export:workflow — el comando. Se lee como "tema : acción": el tema es export (exportar) y el objeto es workflow. Su gemelo, que verás en la lección 3, es export:credentials. La CLI de n8n tiene varios comandos con esta forma tema:objeto.
• --all, --separate, --pretty — las banderas (en inglés, flags). Son opciones que modifican cómo se comporta el comando. Empiezan con dos guiones. --all dice "exporta todos"; --pretty dice "con formato legible". Una bandera puede ir sola porque es un interruptor de sí/no.
• --output=./workflows — una bandera que toma un valor. Aquí --output no es sí/no: necesita saber dónde escribir, y ese "dónde" es ./workflows. El valor va después del signo igual (o, en algunas, separado por un espacio).

Ese ./workflows es una ruta: le dice a n8n en qué carpeta poner los archivos. El ./ significa "a partir de la carpeta donde estoy parado ahora mismo en la terminal". Si estás parado en /home/ana/cumbre-automations, entonces ./workflows es /home/ana/cumbre-automations/workflows. Es la misma lógica de rutas que usaste con Git.

Cuando veas un comando largo, no te asustes: siempre es esto. El programa, el comando, y una lista de banderas que lo afinan. Nada más.

Cómo correr la CLI: dos mundos

Aquí está el punto que más confunde y donde más gente pierde una tarde. La forma exacta de correr la CLI depende de cómo esté instalado n8n en tu máquina, y hay dos escenarios muy distintos. Antes de exportar nada, tienes que saber en cuál estás.

La razón de fondo es esta: la CLI de n8n necesita hablar con la misma base de datos donde viven tus workflows. Tus workflows no están en un archivo suelto; están guardados en la base de datos de tu instancia. El comando export:workflow los saca de esa base de datos y los escribe a archivos. Así que el comando tiene que correr en el mismo lugar que tu instancia, con acceso a la misma base de datos. Si lo corres en otro lado, va a leer una base de datos distinta —probablemente vacía— y no va a exportar nada.

Escenario A: n8n instalado con npm en tu máquina

Si instalaste n8n directamente en tu sistema con npm (npm install n8n -g) y lo arrancas escribiendo n8n en la terminal, entonces la CLI ya está a tu disposición. Corres los comandos tal cual:

n8n export:workflow --all --output=./workflows --separate

Directo. El programa n8n que ya tienes instalado incluye todos los comandos de la CLI.

Escenario B: n8n corriendo dentro de Docker

Este es el escenario más común hoy, y el que esta guía usa por defecto —el Módulo 4 monta los entornos justamente con Docker—. Si tu n8n corre dentro de un contenedor de Docker, la CLI también vive dentro de ese contenedor, no en tu máquina. Para correrla, tienes que "entrar" al contenedor y ejecutar el comando ahí adentro. La herramienta para eso es docker exec.

La forma oficial es esta:

docker exec -u node -it <nombre-del-contenedor> n8n export:workflow --all --output=./workflows --separate

Desármalo, porque cada pieza tiene una razón:

• docker exec — "ejecuta un comando dentro de un contenedor que ya está corriendo". Es la puerta de entrada al contenedor.
• -u node — la bandera -u (de user, usuario) dice con qué usuario ejecutar el comando adentro. La imagen oficial de n8n corre como un usuario llamado node, y los archivos de configuración le pertenecen a ese usuario. Si no pones -u node, es probable que el comando corra como root y te dé errores de permisos raros. Ponlo siempre.
• -it — dos banderas juntas: -i (interactivo) y -t (terminal). Le dan al comando una terminal de verdad adentro del contenedor, para que puedas ver la salida y responder si te pregunta algo. Es una combinación estándar; memorízala como un bloque: -it.
• <nombre-del-contenedor> — el nombre de tu contenedor de n8n. No es literal: tienes que reemplazarlo por el nombre real, que averiguas en un segundo.
• n8n export:workflow --all ... — a partir de aquí, es el mismo comando del escenario A. Todo lo que va después del nombre del contenedor se ejecuta adentro.

¿Cómo sabes el nombre de tu contenedor? Con este comando, que lista los contenedores que están corriendo:

docker ps

Qué esperar: una tabla con una fila por contenedor. La última columna, NAMES, tiene el nombre que necesitas. Si arrancaste n8n con un docker-compose.yml, el nombre suele ser algo como n8n o cumbre-automations-n8n-1. Copia ese nombre exacto y ponlo en el comando.

La trampa: npx contra una instancia que ya corre

Vas a encontrar tutoriales que dicen "corre npx n8n export:workflow". npx es una herramienta que descarga y ejecuta un programa de npm sin instalarlo permanentemente. Y aquí está la trampa: si tu n8n de verdad corre en Docker, y tú corres npx n8n export:workflow --all en tu máquina, npx va a arrancar un n8n nuevo, limpio y vacío, con su propia base de datos sin un solo workflow. El comando va a terminar sin error y va a exportar… nada. Cero archivos, o un archivo vacío. Y tú vas a pensar que perdiste tus workflows.

No los perdiste. Simplemente le preguntaste sus workflows al n8n equivocado —uno recién nacido— en vez de a tu instancia real.

La regla para no caer nunca en esto es simple: el comando de exportación tiene que correr en el mismo lugar donde vive tu instancia. Si tu n8n está en Docker, usa docker exec. Si lo instalaste con npm y ese mismo n8n es el que arrancas todos los días, corres el comando directo. npx solo sirve si no tienes una instancia persistente y estás haciendo una prueba desechable, que no es nuestro caso.

Exportar workflows: n8n export:workflow y sus banderas

Ahora sí, el comando central del módulo. Estas son sus banderas, todas confirmadas contra la documentación oficial de n8n a julio de 2026:

Bandera	Qué hace
--all	Exporta todos los workflows de la instancia.
--id=<id>	Exporta un solo workflow, el que tenga ese identificador.
--output=<ruta>, -o	Dónde escribir: un archivo (si es uno solo y junto) o una carpeta (si usas --separate).
--separate	Exporta un archivo por workflow. Requiere que --output sea una carpeta. Pensada justamente para versionar.
--pretty	Formatea el JSON de forma legible (con sangrías), en vez de todo en una línea.
--backup	Atajo: activa --all --pretty --separate de una vez. Opcionalmente le puedes poner --output.
--published	Exporta la versión publicada (la que corre en producción) en vez del borrador actual.
--version=<versionId>	Exporta una versión histórica específica. No se combina con --all ni --published.
--help	Imprime esta misma lista de banderas para tu versión.

Fíjate en algo antes de correr nada: por defecto, sin --pretty, el JSON sale comprimido en una sola línea gigante. Funciona igual, pero es ilegible y, peor, da diffs horribles en Git —todo el archivo es "una línea", así que cualquier cambio se ve como que cambió todo—. Para versionar, --pretty no es opcional. Lo vas a poner siempre. Y el atajo --backup te lo pone solo, junto con --all y --separate, que son la combinación estándar para un repositorio.

Ejemplo trabajado: exportar order-triage de Cumbre

Vamos a hacerlo completo. Voy a asumir el escenario B (Docker), que es el de la guía, y te voy a mostrar cada comando también en la forma directa del escenario A entre paréntesis. Si tienes una instancia a mano, síguelo; si no, léelo y hazlo después.

Paso 0 — Ubícate en tu repositorio. En la terminal, párate en la carpeta del repositorio de Cumbre, la que en el Módulo 2 pusiste bajo Git:

cd cumbre-automations

Es importante, porque las rutas --output=./algo son relativas a donde estás parado. Si no estás en el repositorio, los archivos van a caer en otro lado.

Paso 1 — Averigua el id de order-triage. Para exportar un solo workflow con --id, necesitas su identificador. La forma más rápida: abre order-triage en el editor y mira la barra de direcciones del navegador. La URL se ve parecida a https://tu-n8n/workflow/aBcD1234EfGh5678. Esa última parte, aBcD1234EfGh5678, es el id del workflow. Cópiala.

(Si prefieres no depender del navegador, en un momento vas a exportar todos con --separate y cada archivo va a llevar el id como nombre; de ahí también lo lees.)

Paso 2 — Exporta solo order-triage a un archivo. Con el id en mano:

docker exec -u node -it n8n n8n export:workflow --id=aBcD1234EfGh5678 --output=order-triage.json --pretty

(Escenario A, directo: n8n export:workflow --id=aBcD1234EfGh5678 --output=order-triage.json --pretty)

Qué esperar: la terminal imprime una línea de confirmación, algo como Successfully exported 1 workflow., y en tu carpeta aparece el archivo order-triage.json. Ábrelo: es el JSON de order-triage, con sangrías legibles gracias a --pretty, con su Webhook, su nodo AI Agent y su nodo HTTP Request. Es el mismo workflow que el botón del editor te daría, pero lo obtuviste con un comando repetible, no con clics.

Detente un segundo en el nombre order-triage. En el comando, el nombre del archivo lo elegiste tú (--output=order-triage.json). Eso es porque exportaste uno solo y le pudiste poner nombre. Cuando exportes todos de golpe, no vas a poder nombrarlos uno por uno, y ahí n8n usa los ids como nombres. Guárdate esa diferencia; la lección 5 se ocupa de darle nombres lindos al repositorio.

Paso 3 — Exporta la instancia completa, un archivo por workflow. Ahora la forma que de verdad vas a usar para el repositorio: todos los workflows, cada uno en su archivo, dentro de una carpeta workflows/.

docker exec -u node -it n8n n8n export:workflow --all --separate --output=./workflows --pretty

(Escenario A: n8n export:workflow --all --separate --output=./workflows --pretty)

Qué esperar: la terminal confirma algo como Successfully exported 4 workflows. —los cuatro de Cumbre— y dentro de workflows/ aparecen cuatro archivos. Sus nombres no son order-triage.json, sino los ids: algo como aBcD1234EfGh5678.json, Xy9Z...json, y así. Cada archivo es un workflow completo, con formato legible. Esos nombres feos los arreglamos en la lección 5; por ahora, lo que importa es que con un solo comando sacaste la instancia entera.

Fíjate en por qué --separate importa para versionar. Sin él, n8n mete los cuatro workflows en un solo archivo enorme. Con él, cada workflow es su propio archivo. ¿Por qué importa? Porque cuando cambies solo order-triage, quieres que el git diff toque solo el archivo de order-triage, no un archivo gigante que mezcla los cuatro. Un archivo por workflow es un diff por workflow. La documentación de n8n describe --separate exactamente así: "útil para versionar".

Paso 4 — El atajo --backup. Como --all --pretty --separate es la combinación que vas a usar siempre, n8n te da un atajo:

docker exec -u node -it n8n n8n export:workflow --backup --output=./workflows

Qué esperar: exactamente el mismo resultado que el paso 3 —cuatro archivos legibles, uno por workflow—. --backup es --all --pretty --separate escrito más corto. Úsalo cuando quieras el respaldo completo; usa --id cuando quieras uno específico.

Acabas de hacer, con cuatro comandos, lo que con el editor serían decenas de clics repartidos en cuatro sesiones. Y lo más importante: estos cuatro comandos se pueden pegar en un script y correr solos. Eso es la lección 7.

Un detalle de Docker: dónde caen los archivos

Si corres la CLI dentro de un contenedor con docker exec, hay una sutileza que confunde la primera vez y conviene tener clara: los archivos que exportas caen dentro del contenedor, no en tu máquina. Cuando escribes --output=./workflows, ese ./workflows es una carpeta adentro del contenedor, no la carpeta de tu repositorio en tu disco. Es lógico: el comando corre adentro, así que escribe adentro. Pero significa que exportar no es suficiente; después hay que sacar los archivos del contenedor a tu repositorio.

Hay dos formas de resolverlo, y depende de cómo montaste tu n8n.

Forma 1 — exportar a una carpeta que ya está compartida (volumen). Docker permite "compartir" una carpeta entre tu máquina y el contenedor: lo que se escribe de un lado aparece del otro. Eso se llama un volumen, y n8n casi siempre monta uno para guardar sus datos (típicamente la carpeta ~/.n8n del contenedor). Si exportas a una ruta que cae dentro de ese volumen compartido, los archivos aparecen automáticamente en tu máquina, sin pasos extra. Es la forma más limpia, y la que el script de la lección 7 va a preferir.

Forma 2 — copiar los archivos hacia afuera con docker cp. Si exportaste a una carpeta interna que no está compartida, usas docker cp para copiarlos a tu repositorio:

docker cp n8n:/home/node/workflows ./workflows

Desármalo: docker cp copia archivos entre el contenedor y tu máquina; n8n:/home/node/workflows es "la carpeta workflows dentro del contenedor llamado n8n"; y ./workflows es a dónde traerlos en tu disco. Es el mismo cp de siempre, pero cruzando la frontera del contenedor.

No te preocupes por dominar esto ahora mismo. Lo importante es que reconozcas el síntoma: si exportas con docker exec y no ves los archivos en tu repositorio, no fallaron —están adentro del contenedor—. El Módulo 4, cuando monte los entornos con Docker Compose, deja los volúmenes bien puestos para que este paso sea transparente. Por ahora, si estás practicando, la Forma 2 con docker cp siempre funciona.

Por qué la CLI le gana al botón del editor

Vale la pena poner lado a lado lo que ganaste, porque no es solo comodidad:

	Botón del editor	CLI de n8n
Cuántos a la vez	Uno por uno, a mano	Todos de un comando (--all)
Reproducible	No: depende de tus clics	Sí: el mismo comando, el mismo resultado
Automatizable	No	Sí: se mete en un script (lección 7)
Un archivo por workflow	Sí, pero uno por uno	Sí, todos de golpe (--separate)
Formato legible	Sí	Sí (--pretty)
Versión publicada vs borrador	No distingue fácil	Sí (--published)

La fila que más pesa es "automatizable". El botón del editor es un callejón sin salida: sirve para hoy, pero no se puede construir nada encima. La CLI es un cimiento: sobre ella se para la normalización, el script de exportación y, más adelante, la promoción entre entornos. Aprender la CLI no es aprender "otra forma de exportar"; es abrir la puerta a todo lo automatizable del resto de la guía.

Hay un matiz honesto que conviene reconocer: para exportar un solo workflow una vez, el botón del editor es más rápido —dos clics contra escribir un comando—. Nadie abre una terminal para bajar un workflow suelto. La CLI gana cuando el trabajo es repetido o en lote: respaldar los cuatro workflows cada semana, o exportar antes de cada commit, o correr el proceso sin nadie mirando. Es la misma diferencia que entre lavar un plato a mano (rápido, uno) y usar el lavavajillas (vale la pena cuando son muchos, y corre solo). No abandones el botón para tareas de un solo uso; adopta la CLI para todo lo que se repite. Y como versionar un repositorio es, por definición, algo que se repite en cada cambio, la CLI es la herramienta de este módulo.

Un vistazo al camino de vuelta: import:workflow

Exportar es sacar workflows de la instancia a archivos. La operación inversa —meter archivos de vuelta a una instancia— existe y se llama n8n import:workflow. No la vamos a usar a fondo en este módulo, pero conviene que sepas que está, porque es la mitad que el Módulo 6 usa para promover un workflow de un entorno a otro.

Su bandera principal es --input, que es el espejo de --output: dónde leer los archivos. Y también tiene --separate, para leer una carpeta llena de archivos individuales:

n8n import:workflow --separate --input=./workflows

Por ahora quédate solo con la idea de simetría: export saca a archivos con --output; import los mete desde archivos con --input. Cuando en el Módulo 6 promuevas order-triage de staging a prod, vas a estar exportando de una instancia e importando en la otra. La base es lo que aprendes hoy.

Errores comunes

Exportar contra una instancia vacía y creer que perdiste tus workflows (práctico, y el más frecuente). Qué pasa: tu n8n corre en Docker, pero corres npx n8n export:workflow --all en tu máquina. El comando termina sin quejarse y exporta cero workflows. Entras en pánico. Por qué pasa: npx arrancó un n8n nuevo y vacío, con su propia base de datos, y a ese le preguntaste. Tu instancia real, la de Docker, ni se enteró. Cómo detectarlo: si el comando dice Successfully exported 0 workflows pero tú sabes que tienes workflows, no exportaste contra tu instancia. Cómo corregirlo: usa docker exec -u node -it <contenedor> n8n export:workflow ... para exportar contra la instancia que de verdad corre. La regla: el comando va donde vive la base de datos.

Usar --separate sin darle una carpeta con --output (práctico). Qué pasa: corres n8n export:workflow --all --separate y obtienes un error o un resultado inesperado. Por qué pasa: --separate necesita saber en qué carpeta poner el archivo de cada workflow; sin --output apuntando a una carpeta, no tiene dónde escribirlos. Cómo detectarlo: si pusiste --separate y no pusiste --output=<una-carpeta>, ese es el problema. Cómo corregirlo: agrega --output=./workflows. La documentación es explícita: --separate obliga a fijar una carpeta con --output.

Olvidar --pretty y terminar con un diff ilegible (práctico). Qué pasa: exportas sin --pretty, todo sale comprimido en una sola línea, y cuando haces git diff para revisar un cambio chico, Git te marca "toda la línea" como modificada, es decir, todo el archivo. Por qué pasa: sin --pretty, n8n escribe el JSON en el formato más compacto, sin saltos de línea. Git compara línea por línea, y si el archivo entero es una línea, cualquier cambio parece un cambio total. Cómo detectarlo: abre el archivo exportado; si es una sola línea larguísima, te faltó --pretty. Cómo corregirlo: vuelve a exportar con --pretty (o con --backup, que ya lo incluye). Este hábito es la mitad del camino hacia los diffs limpios; la otra mitad es la normalización de la lección 4.

Correr el comando sin -u node dentro de Docker (práctico). Qué pasa: usas docker exec pero sin -u node, y obtienes errores de permisos, o los archivos quedan con un dueño equivocado y después no los puedes editar cómodo. Por qué pasa: sin -u node, el comando suele correr como root, que no es el usuario dueño de la configuración de n8n dentro del contenedor. Cómo detectarlo: si ves mensajes sobre "permission denied" o archivos que no puedes modificar, revisa si pusiste -u node. Cómo corregirlo: incluye siempre -u node en tus comandos docker exec de n8n. Memorízalo como parte del bloque fijo: docker exec -u node -it.

Ejercicios

Ejercicio 1 — Identifica tu escenario y corre --help. En tu propia máquina, averigua si tu n8n corre con npm o en Docker. Si es Docker, corre docker ps y anota el nombre exacto de tu contenedor. Después, corre n8n export:workflow --help (directo, o con docker exec -u node -it <contenedor> adelante) y compara la lista de banderas que imprime con la tabla de esta lección. Anota si hay alguna bandera de más o de menos.

Ver solución

No hay una respuesta única, porque depende de tu instalación y tu versión. Lo que la mayoría encuentra es que las banderas centrales —--all, --id, --output, --separate, --pretty, --backup— aparecen igual, y que puede haber una o dos banderas nuevas o con la descripción ligeramente distinta según la versión.

Por qué funciona: el objetivo real de este ejercicio no es exportar nada, es instalar el hábito de verificar contra tu propia instancia antes de confiar en un comando. La documentación —esta guía incluida— siempre va un paso atrás del software. El --help es la única fuente que está exactamente al día con la versión que tienes en las manos. Ese reflejo te va a servir cuando leas esta guía dentro de dos años con n8n 3.x en pantalla.

Ejercicio 2 — Arma el comando correcto para tres situaciones. Sin correr nada, escribe el comando completo de export:workflow (en la forma que corresponda a tu escenario) para cada caso: (a) respaldar toda la instancia, cada workflow en su archivo, legible, dentro de ./workflows; (b) exportar solo el workflow con id Xy9Z00Kw a un único archivo llamado order-triage.json con formato legible; (c) exportar todo, pero la versión publicada en producción, no los borradores.

Ver solución

(a) n8n export:workflow --backup --output=./workflows — --backup ya es --all --pretty --separate, que es exactamente lo pedido. También vale escribirlo largo: n8n export:workflow --all --separate --pretty --output=./workflows.

(b) n8n export:workflow --id=Xy9Z00Kw --output=order-triage.json --pretty — un solo workflow por --id, a un archivo con nombre elegido, con --pretty. Aquí --output es un archivo, no una carpeta, porque es uno solo.

(c) n8n export:workflow --all --published --separate --pretty --output=./workflows — --published cambia qué versión se exporta (la que corre en producción en vez del borrador). Ojo: --published no se combina con --version, porque son dos formas distintas de elegir qué versión sacar.

Si tu instancia es Docker, a los tres les va adelante docker exec -u node -it <contenedor>.

Por qué funciona: armar el comando de memoria te obliga a distinguir qué elige cuáles workflows (--all, --id, --published) de qué controla cómo se escriben (--separate, --pretty, --output). Son dos preguntas distintas, y todo comando de exportación es una respuesta a las dos.

Ejercicio 3 — Diagnostica una exportación vacía. Un compañero te escribe: "Corrí npx n8n export:workflow --all --output=./workflows en mi laptop, no dio ningún error, pero la carpeta workflows está vacía. ¿Se me borraron los workflows?" Su n8n corre en un contenedor de Docker. Explícale en dos o tres frases qué pasó y qué comando debería correr.

Ver solución

No se le borró nada; sus workflows están sanos en el contenedor. Lo que pasó es que npx n8n arrancó una instancia de n8n nueva y vacía en su laptop, con una base de datos propia sin ningún workflow, y le exportó esa —de ahí la carpeta vacía y el "cero errores"—. Nunca tocó su instancia real de Docker.

Lo que debería correr es el comando dentro de su contenedor: primero docker ps para ver el nombre del contenedor, y luego docker exec -u node -it <nombre> n8n export:workflow --all --separate --pretty --output=./workflows. Así el comando corre en el mismo lugar donde vive la base de datos con sus workflows de verdad.

Por qué funciona: este es, con diferencia, el tropiezo número uno con la CLI de n8n, y el más angustiante porque parece que perdiste tu trabajo. Tener clarísima la regla —"el comando corre donde vive la base de datos"— te ahorra el susto y te deja diagnosticarlo en segundos cuando le pase a alguien de tu equipo.

Resumen y siguiente paso

En esta lección conociste la CLI de n8n: la puerta de comandos a la misma instancia que manejas en el editor, buena para operar en lote lo que el editor hace de a uno. Aprendiste a leer un comando por sus piezas —el programa n8n, el comando export:workflow, las banderas --... y las que toman un valor como --output— y a correrlo en los dos mundos: directo si instalaste con npm, o con docker exec -u node -it <contenedor> si corre en Docker. Grabaste la regla que evita el susto más común: el comando de exportación tiene que correr donde vive la base de datos, así que npx en tu máquina contra una instancia de Docker exporta una instancia vacía. Y exportaste order-triage y la instancia completa de Cumbre con las banderas confirmadas contra la doc oficial: --all, --id, --separate, --pretty, --output, --backup, --published, --version, más el imprescindible --help para verificar contra tu versión.

Antes de avanzar deberías poder: decir en qué escenario está tu instancia y correr export:workflow --help; armar de memoria el comando para respaldar toda la instancia en archivos separados y legibles; y explicar por qué correr npx n8n export en tu laptop contra un n8n de Docker exporta nada.

La lección 3 es la más delicada del módulo. Vas a exportar lo que no se ve en el editor y lo que jamás puede tocar el repositorio: las credenciales. Vas a conocer export:credentials y su bandera --decrypted, que es un riesgo de seguridad real; vas a entender qué es la N8N_ENCRYPTION_KEY y por qué una credencial no se sube al repo ni siquiera cifrada; y vas a poner el .gitignore que blinda tus secretos desde el primer commit. Es la lección que separa a quien entrega un sistema seguro de quien, sin saberlo, publica la llave del CRM de su cliente.

Recursos

• Use the command line — n8n Docs — la referencia oficial de la CLI: todos los comandos, todas las banderas de export:workflow e import:workflow, y la forma de correrlos con docker exec. Es la fuente que confirmé para esta lección.
• Export and import workflows — n8n Docs — la comparación entre exportar desde el editor y desde la línea de comandos, con ejemplos de ambos.
• Docker installation — n8n Docs — cómo corre n8n dentro de Docker, útil para entender por qué la CLI vive dentro del contenedor y no en tu máquina.
• Release notes 2.x — n8n Docs — el historial de versiones, para confirmar cuál tienes y si alguna bandera cambió respecto de lo que dice esta lección.