Estoy usando n8n como self host en una imagen de Docker en un producto de ingeniería de software. Siempre que necesito pasar del entorno de desarrollo a SIT, ¿hay alguna forma que no sea ejecutar una nueva imagen de Docker y copiar todos los flujos de trabajo de un entorno a otro cada vez? El número de flujos de trabajo es grande
@Mohamed8 no los copies a mano, usa la exportación/importación de la CLI de n8n, mueve toda tu biblioteca de una vez. en el contenedor de desarrollo exporta todos los workflows a una carpeta, copia esa carpeta a la caja de SIT, luego importa:
# en dev
docker exec -u node <dev-container> n8n export:workflow --backup --output=/tmp/wf/
# copia /tmp/wf al otro lado, luego en SIT
docker exec -u node <sit-container> n8n import:workflow --separate --input=/tmp/wf/
hay un par correspondiente export:credentials / import:credentials si necesitas mover credenciales también. es mejor que crear una imagen nueva y copiar cada vez.
Gracias. Estoy usando autenticación básica en mis flujos de trabajo, las añadí en Credenciales y selecciono la apropiada para cada solicitud HTTP. Cuando copio el flujo de trabajo, se reinicia y elige la primera autenticación básica para todos los nodos HTTP de forma predeterminada y necesito corregirlos.
¿Enfrentaré el mismo problema con este enfoque?
@Mohamed8 el reinicio ocurre porque los nodos hacen referencia a las credenciales por id y una copia simple no conserva esos ids, por lo que recurre a la primera coincidencia. La CLI lo evita siempre y cuando muevas las credenciales también, no solo los flujos de trabajo: export:credentials --backup en dev, import:credentials en SIT. Ese import hace upsert por id, así que cada credencial mantiene su id original y las referencias del flujo de trabajo se resuelven automáticamente a la autenticación básica correcta.
una advertencia, las credenciales se cifran con N8N_ENCRYPTION_KEY, así que SIT necesita la misma clave que dev o no se descifrarán. Si las claves son diferentes, exporta con --decrypted y se re-encriptarán en la importación.
¡Excelente! ¿Tienes idea de cómo puedo acceder a esa clave de cifrado? ¿Se puede exportar también o no?
@Mohamed8 no se exporta con los workflows. es la variable de entorno N8N_ENCRYPTION_KEY si estableces una, o si nunca lo hiciste, n8n la generó automáticamente y la guardó en el archivo de configuración. léela en dev con:
docker exec -u node <dev-container> cat /home/node/.n8n/config
verás un valor encryptionKey allí. el camino más fácil es establecer ese mismo valor como N8N_ENCRYPTION_KEY en SIT (en tu compose/run env), luego ambos comparten la clave y las credenciales importadas se descifran. establecerlo explícitamente en ambos es mejor que confiar en el archivo generado automáticamente de todas formas.
Oye @Mohamed8, el enfoque CLI de @achamm es la solución correcta para lo que tienes ahora. Una cosa que vale la pena considerar a largo plazo, ya que esto suena como una promoción recurrente de dev→SIT en una canalización de productos real, n8n admite control de versiones mediante Git (Configuración → Source Control, disponible en ciertos planes) que convierte esto en un flujo de estilo CI/CD adecuado: envía workflows desde dev a un repositorio de Git, luego extrae/despliega a SIT automáticamente. También versiona tus workflows correctamente, por lo que obtienes diffs y reversión de forma gratuita en lugar de exportar/importar manualmente cada vez.
Si el control de versiones basado en Git no está disponible en tu plan/edición, la exportación/importación CLI de @achamm es el equivalente manual correcto, solo vale la pena saber que la opción automatizada existe si esto se convierte en un paso frecuente de la canalización en lugar de una migración única.
Tengo un problema cuando intento importar mis flujos de trabajo a mi nuevo entorno.
Recibo un error
Active version not found for workflow
Error: Active version not found for workflow
at ActiveWorkflowManager.clearWebhooks (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:248:10)
at ActiveWorkflowManager.remove (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:872:4)
at ImportService.importWorkflows (/usr/local/lib/node_modules/n8n/src/services/import.service.ts:84:5)
at ImportWorkflowsCommand.run (/usr/local/lib/node_modules/n8n/src/commands/import/workflow.ts:104:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Could not remove webhooks of workflow "0YdMxcy7MAjVkwy2" because of error: "Active version not found for workflow"
Could not find workflow
Error: Could not find workflow
at ActiveWorkflowManager.clearWebhooks (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:244:10)
at ActiveWorkflowManager.remove (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:872:4)
at ImportService.importWorkflows (/usr/local/lib/node_modules/n8n/src/services/import.service.ts:84:5)
at ImportWorkflowsCommand.run (/usr/local/lib/node_modules/n8n/src/commands/import/workflow.ts:104:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Considerando que mis flujos de trabajo tienen disparadores de webhooks y algunos de ellos están activos, y mi versión de n8n es la 2.1.4
¿tienes alguna idea?
@ShawnWilliams @achamm
@Mohamed8 ese es el import intentando gestionar el estado activo de los workflows, las versiones más nuevas de n8n rastrean los workflows activos por un id de versión e importar un workflow activo cuyo registro active-version no existe aún en SIT hace que clearWebhooks falle con eso. la solución más limpia es traerlos inactivos, desactivar los workflows en dev antes de exportar para que se importen como active:false, luego activarlos en SIT después de que se carguen. y si la ejecución fallida dejó copias semiimportadas atrapadas activas en SIT, desactívalas o elimínalas primero para que el siguiente import no intente limpiar webhooks para ellas.
¿hay una manera de activarlos/desactivarlos usando CLI?
@Mohamed8 sí, el comando n8n update:workflow lo hace:
docker exec -u node <container> n8n update:workflow --all --active=false
cambia --active=true para activar, o usa --id= en lugar de --all para dirigirse a uno específico. así que tu flujo se convierte en desactivar en dev, exportar, importar a SIT, y luego ejecutarlo con --active=true en SIT. si no quieres que dev se desconecte, solo desactiva las copias atrapadas en SIT con --all --active=false, reimporta, y luego reactiva allí.
Muchas gracias por tu ayuda. @achamm
cuando intento publicar uno por uno me da un error
Publishing workflow with ID: Error tracking disabled because this release is older than 6 weeks. (current version)
Error updating database. See log messages for details.
GOT ERROR
Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
Error: Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
at WorkflowRepository.publishVersion (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/
+db@file+packages+
+db_@opentelemetry+api@1.9.0_@opentelemetry+sdk-trace-base@1._ab22bba05a964211b9fe14bf4b841570/node_modules/
/db/src/repositories/workflow.repository.ts:894:11)
at PublishWorkflowCommand.run (/usr/local/lib/node_modules/n8n/src/commands/publish/workflow.ts:43:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
Publishing 0YdMxcy7MAjVkwy2
Error tracking disabled because this release is older than 6 weeks.
Publishing workflow with ID: 0YdMxcy7MAjVkwy2 (current version)
Error updating database. See log messages for details.
también cuando intento publicar desde la interfaz, dice No se pudo publicar el flujo de trabajo:
Versión no encontrada
@Mohamed8 no los hagas uno por uno, ese publish por id es donde se está atascando, el workflow id no se está resolviendo así que n8n no puede encontrarlo. simplemente ejecuta la activación en lote:
docker exec -u node <container> n8n update:workflow --all --active=true
eso los activa todos de una sola vez sin que tengas que pasar ids individuales. si incluso --all falla, probablemente sea una particularidad en la compilación que estés usando (esa línea de 6 semanas significa que es una versión más antigua), y vale la pena intentar actualizar a una versión actual de n8n.
El consejo de exportación/importación de CLI es la base correcta. Si tienes muchos flujos de trabajo, también trataría dev → SIT como un proceso de lanzamiento en lugar de una operación de copia.
Los puntos que añadiría:
- Mantén las exportaciones en control de versiones para saber qué cambió entre promociones.
- Separa la estructura del flujo de trabajo de los valores específicos del entorno.
- No muevas ciegamente las credenciales de producción a menos que tengas un modelo claro de propiedad de credenciales.
- Ejecuta pruebas de humo después de la importación para los flujos de trabajo que importan.
- Registra qué flujos de trabajo fueron promocionados, cuáles fallaron y qué necesita seguimiento manual.
- Mantén una ruta de reversión, aunque sea solo reimportando la exportación anterior conocida como buena.
El paso de copia generalmente no es lo que duele después. La parte difícil es cuando nadie sabe qué versión tiene cada entorno, si SIT fue realmente probado, o qué flujo de trabajo se rompió después del movimiento. Ese registro de promoción se vuelve especialmente importante una vez que los flujos de trabajo son accesibles a clientes.
@achamm pero siempre que uso
docker exec -u node n8n update:workflow --all --active=true
me dice
⚠️ WARNING: The "update:workflow" command is deprecated.
Workflow publishing via "update:workflow --all" is no longer supported.
Please publish workflows individually using: publish:workflow --id=<workflow-id>
@Mohamed8 sí, --all quedó deprecado y el nuevo publish:workflow es donde obtuviste ese error de versión anteriormente, así que salta el CLI de publish y usa la API REST pública en su lugar, tiene un endpoint activate dedicado que evita el versionado por completo:
POST /api/v1/workflows/{id}/activate
genera una clave de API en Settings > n8n API, lista tus workflows con GET /api/v1/workflows para obtener los ids, luego recorre esa llamada activate sobre cada uno. esa es tu activación en masa sin tocar el comando publish roto.
@achamm ¿podrías consultar los ids de flujos de trabajo desde sqlite e iterar sobre ellos como una alternativa?
@Mohamed8 sí, leer los ids desde sqlite funciona bien, la tabla es workflow_entity así que SELECT id FROM workflow_entity te obtiene la lista (el api GET /api/v1/workflows hace lo mismo y no está vinculado al esquema de la bd, pero cualquiera funciona). solo mantenlo en lectura, no actives escribiendo active=1 directamente en sqlite, eso omite el trigger/webhook que n8n registra al activar, que es exactamente lo que deja los workflows en ese estado activo-versión roto. extrae los ids como prefieras, pero ejecuta la activación a través del endpoint de la api para que n8n conecte los triggers correctamente.
Gracias por tu ayuda @achamm. ¿Crees que replicar el volumen de n8n de DEV para usarlo en SIT mantendría los IDs de credenciales y los nodos asociados correctamente?
Veo que todos los detalles se almacenan en SQLite, que reside en el volumen de n8n.
@Mohamed8 sí, clonar todo el volumen funciona y es lo más limpio para mantener todo conectado — es una copia byte a byte de la misma bd sqlite, así que los ids de credenciales, ids de workflow y cada referencia de nodo permanecen idénticos, nada que revinculer. la clave de encriptación también va incluida ya que está en .n8n/config dentro de ese volumen, así que las creds se desencriptan en SIT, solo no establezcas una variable de entorno N8N_ENCRYPTION_KEY diferente en SIT o causará conflicto.
dos inconvenientes aunque: es una sobrescritura completa, reemplaza todo en SIT y lleva la configuración específica del entorno de DEV (urls, webhook base, valores de cred dev-vs-prod), así que es genial si SIT está diseñado para reflejar DEV, menos si SIT necesita sus propias configuraciones. y detén n8n antes de copiar el archivo sqlite, copiarlo en vivo puede corromperlo, o usa el .backup de sqlite para una snapshot limpia. si SIT necesita su propia configuración, la exportación/importación selectiva sigue siendo la mejor ruta.