Saltar al contenido principal

Cambios importantes en n8n v2.0

Se lanzará próximamente n8n v2.0. Este documento destaca los cambios más relevantes y las acciones que debes tomar para prepararte para la transición. Estas actualizaciones mejoran la seguridad, simplifican la configuración y eliminan funcionalidades obsoletas.

El lanzamiento de n8n 2.0 refuerza el compromiso de n8n de ofrecer una plataforma de automatización segura, fiable y lista para producción. Esta versión principal incluye mejoras importantes de seguridad y la eliminación de funciones obsoletas.

Cambios de comportamiento​

Devolución de datos esperados al reanudar subflujos de trabajo desde estado de espera​

Anteriormente, cuando una ejecución padre llamaba a una ejecución hija que contenía un nodo que ponía a la ejecución hija en estado de espera, y la ejecución padre estaba configurada para esperar a que finalizara la ejecución hija, la ejecución padre recibía resultados incorrectos.

Por ejemplo, esto ocurría cuando la ejecución hija incluía un nodo Wait con un tiempo de espera superior a 65 segundos, llamadas a webhooks, envíos de formularios o nodos de revisión manual (como el nodo de Slack).

Flujo de trabajo padre:
Flujo de trabajo padre

Subflujo de trabajo:
Subflujo de trabajo

v1: La ejecución padre devolvía la entrada de la ejecución hija en lugar de su resultado:
v1: La ejecución padre no recibe el resultado de la ejecución hija

v2: La ejecución padre recibe el resultado de la ejecución hija:
v2: La ejecución padre recibirá el resultado de la ejecución hija

Esto permite usar nodos de revisión manual en subflujos de trabajo y utilizar los resultados del subflujo en el flujo de trabajo padre (por ejemplo, aprobar o rechazar una acción).

Ruta de migración: Revisa todos los flujos de trabajo que llaman a subflujos y esperan recibir la entrada del subflujo. Actualiza estos flujos para adaptarlos al nuevo comportamiento: el flujo de trabajo padre recibirá la salida del subflujo (es decir, los datos al final del subflujo), no su entrada.

Eliminación del nodo Start​

El nodo Start ya no es compatible. Este nodo era la forma original de iniciar flujos de trabajo, pero ha sido reemplazado por nodos disparadores más específicos.

Ruta de migración: Reemplaza el nodo Start según el uso de tu flujo de trabajo:

  • Ejecución manual: Sustituye el nodo Start por el nodo Manual Trigger.
  • Subflujo de trabajo: Si otro flujo de trabajo llama a este como subflujo, reemplaza el nodo Start por el nodo Execute Workflow Trigger y publícalo.
  • Nodo Start desactivado: Si el nodo Start ya estaba desactivado, elimínalo del flujo de trabajo.

Guardar y publicar flujos de trabajo​

El nuevo sistema de publicación de flujos de trabajo reemplaza el antiguo interruptor de activación/desactivación. El interruptor «Activar/Desactivar» se convierte ahora en los nuevos botones «Publicar/Cancelar publicación». Este cambio te permite controlar mejor cuándo se aplican los cambios a producción, reduciendo el riesgo de desplegar accidentalmente modificaciones en curso. Para obtener más información, consulta la sección sobre guardar y publicar flujos de trabajo.

Eliminación de nodos de servicios descontinuados​

Se han eliminado los siguientes nodos porque los servicios externos a los que se conectaban ya no están disponibles:

  • Nodo Spontit
  • Nodo crowd.dev
  • Nodo Kitemaker
  • Nodo Automizy

Ruta de migración: Si tus flujos de trabajo utilizan alguno de estos nodos, actualízalos o elimínalos para evitar errores.

Seguridad​

Bloqueo predeterminado del acceso a variables de entorno desde nodos Code​

Para mejorar la seguridad, n8n bloqueará por defecto el acceso a variables de entorno desde nodos Code. El valor predeterminado de N8N_BLOCK_ENV_ACCESS_IN_NODE será ahora true.

Ruta de migración: Si tus flujos de trabajo necesitan acceder a variables de entorno desde un nodo Code, configura N8N_BLOCK_ENV_ACCESS_IN_NODE=false en tu entorno. Para datos sensibles, se recomienda usar credenciales u otros métodos seguros en lugar de variables de entorno.

Requisito obligatorio de permisos estrictos en archivos de configuración​

n8n exigirá permisos estrictos en los archivos de configuración para mejorar la seguridad. Por defecto, los archivos de configuración deben tener permisos 0600, lo que significa que solo el propietario del archivo puede leer y escribir. Este enfoque es similar al que usa SSH para proteger claves privadas.

Ruta de migración: Para probar este comportamiento antes de v2.0, establece N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true. Si tu entorno no admite permisos de archivo (por ejemplo, en Windows), desactiva este requisito con N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false.

Habilitación predeterminada del ejecutor de tareas​

n8n habilitará por defecto el ejecutor de tareas para mejorar la seguridad y el aislamiento. Todas las ejecuciones de nodos Code se realizarán en el ejecutor de tareas.

Ruta de migración: Antes de actualizar a v2.0, configura N8N_RUNNERS_ENABLED=true para probar este comportamiento. Asegúrate de que tu infraestructura cumple los requisitos para ejecutar el ejecutor de tareas. Para mayor seguridad, considera usar el modo externo.

Eliminación del ejecutor de tareas de la imagen Docker n8nio/n8n​

A partir de v2.0, la imagen principal de Docker n8nio/n8n ya no incluirá el ejecutor de tareas para el modo externo. Deberás usar la imagen separada n8nio/runners para ejecutar el ejecutor de tareas en modo externo.

Ruta de migración: Si ejecutas el ejecutor de tareas en modo externo con Docker, actualiza tu configuración para usar la imagen n8nio/runners en lugar de n8nio/n8n.

Eliminación del nodo Python Code y herramientas basadas en Pyodide​

n8n eliminará el nodo Python Code y las herramientas basadas en Pyodide, reemplazándolos por una implementación basada en el ejecutor de tareas que utiliza Python nativo, lo que ofrece mejor seguridad y rendimiento. A partir de v2.0, solo podrás usar el nodo Python Code con el ejecutor de tareas en modo externo y con herramientas de Python nativo.

El nodo Python Code nativo no admite las variables integradas disponibles en la versión de Pyodide (como _input) ni la notación de punto. Consulta la documentación del nodo Code para más detalles.

Las herramientas de Python nativo sí admiten _query, que es la cadena de entrada que recibe la herramienta cuando es invocada por un agente de IA.

Ruta de migración: Para seguir usando Python en nodos Code, configura el ejecutor de tareas en modo externo y revisa si tus nodos y herramientas existentes de Python Code son compatibles.

Desactivación predeterminada de los nodos ExecuteCommand y LocalFileTrigger​

n8n desactivará por defecto los nodos ExecuteCommand y LocalFileTrigger debido a sus riesgos de seguridad. Estos nodos permiten la ejecución de comandos arbitrarios y el acceso al sistema de archivos.

Ruta de migración: Si necesitas usar estos nodos, elimínalos de la lista de nodos desactivados en la configuración de n8n mediante la variable de entorno NODES_EXCLUDE. Por ejemplo, establece NODES_EXCLUDE="[]" para habilitar todos los nodos, o elimina solo los nodos específicos que necesites.

Autenticación obligatoria predeterminada en URLs de callback de OAuth​

n8n requerirá autenticación por defecto en los endpoints de callback de OAuth. El valor predeterminado de N8N_SKIP_AUTH_ON_OAUTH_CALLBACK cambiará de true (sin autenticación) a false (con autenticación).

Ruta de migración: Antes de actualizar a v2.0, configura N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false y prueba tus integraciones de OAuth para asegurarte de que funcionan correctamente con autenticación habilitada.

Valor predeterminado para N8N_RESTRICT_FILE_ACCESS_TO​

n8n establecerá un valor predeterminado para N8N_RESTRICT_FILE_ACCESS_TO para controlar dónde pueden realizarse operaciones con archivos. Esto afecta a los nodos ReadWriteFile y ReadBinaryFiles. Por defecto, estos nodos solo podrán acceder a archivos en el directorio ~/.n8n-files.

Ruta de migración: Revisa los flujos de trabajo que usan nodos de archivos y asegúrate de que solo acceden a archivos en directorios permitidos. Si necesitas permitir el acceso a otros directorios, configura la variable de entorno N8N_RESTRICT_FILE_ACCESS_TO con las rutas deseadas.

Cambio del valor predeterminado de N8N_GIT_NODE_DISABLE_BARE_REPOS a true​

Por razones de seguridad, los nodos Git bloquearán por defecto los repositorios bare. El valor predeterminado de N8N_GIT_NODE_DISABLE_BARE_REPOS será true, lo que significa que los repositorios bare estarán deshabilitados a menos que cambies esta configuración.

Ruta de migración: Si tus flujos de trabajo necesitan usar repositorios bare, habilita esta funcionalidad configurando N8N_GIT_NODE_DISABLE_BARE_REPOS=false en tu entorno.

Datos​

Eliminación del soporte para MySQL/MariaDB​

n8n ya no admitirá MySQL ni MariaDB como backends de almacenamiento; este soporte fue descontinuado en v1.0. Para obtener la mejor compatibilidad y soporte a largo plazo, usa PostgreSQL. El nodo MySQL seguirá siendo compatible como antes.

Ruta de migración: Antes de actualizar a v2.0, migra tus datos de MySQL o MariaDB a PostgreSQL o SQLite usando herramientas de migración de bases de datos.

Eliminación del controlador heredado de SQLite​

Debido a problemas de fiabilidad, n8n eliminará el controlador heredado de SQLite. El controlador con pool de conexiones será el único disponible. Este controlador utiliza el modo WAL, una única conexión de escritura y un pool de conexiones de lectura. Nuestras pruebas indican que puede ser hasta 10 veces más rápido.

Ruta de migración: El controlador sqlite-pooled se convertirá automáticamente en el predeterminado. Puedes habilitar inmediatamente el pool de conexiones estableciendo DB_SQLITE_POOL_SIZE a un valor mayor que 0. El tamaño predeterminado del pool será 2.

Eliminación del modo de datos binarios en memoria​

n8n eliminará el modo default de N8N_DEFAULT_BINARY_DATA_MODE, que guardaba los datos binarios en memoria durante la ejecución. A partir de v2, estarán disponibles las siguientes opciones para mejorar el rendimiento y la estabilidad:

  • filesystem: los datos binarios se almacenan en el sistema de archivos (opción predeterminada en modo regular).
  • database: los datos binarios se almacenan en la base de datos (opción predeterminada en modo cola).
  • s3: los datos binarios se almacenan en un almacenamiento compatible con S3.

También se eliminará la configuración N8N_AVAILABLE_BINARY_DATA_MODES, por lo que el modo se determinará únicamente mediante N8N_DEFAULT_BINARY_DATA_MODE.

Ruta de migración: Se usará automáticamente el modo de sistema de archivos o base de datos según la configuración. Asegúrate de que tu instancia de n8n tiene suficiente espacio en disco para almacenar datos binarios. Consulta la documentación sobre configuración de datos binarios para más detalles.

Configuración y entorno​

Actualización de dotenv​

n8n utiliza la biblioteca dotenv para cargar la configuración del entorno desde archivos .env. Esta biblioteca se actualizará de la versión 8.6.0 a la más reciente, lo que podría cambiar la forma en que se analizan los archivos .env. Los principales cambios incluyen:

  • Soporte para comillas invertidas (#615): si tus valores contienen comillas invertidas, enciérralos entre comillas simples o dobles.
  • Soporte para valores multilínea.
  • Las líneas que comienzan con # se tratan como comentarios.

Ruta de migración: Consulta el registro de cambios de dotenv y actualiza tus archivos .env para garantizar compatibilidad con la nueva versión.

Eliminación de la opción n8n --tunnel​

La opción de línea de comandos n8n --tunnel se eliminará en v2.0.

Ruta de migración: Si actualmente usas la opción --tunnel para desarrollo o pruebas, cambia a otras soluciones de túnel como ngrok, localtunnel o Cloudflare Tunnel. Actualiza tus flujos de trabajo y documentación para reflejar este cambio.

Eliminación de QUEUE_WORKER_MAX_STALLED_COUNT​

Se eliminará la variable de entorno QUEUE_WORKER_MAX_STALLED_COUNT y el mecanismo de reintentos de Bull para tareas estancadas, ya que a menudo causaban confusión y funcionaban de forma poco fiable.

Ruta de migración: Elimina esta variable de entorno de tu configuración. Tras la actualización, n8n ya no reintentará automáticamente tareas estancadas. Si necesitas gestionar tareas estancadas, considera implementar tu propia lógica de reintento o monitoreo.

Eliminación de N8N_CONFIG_FILES​

Se ha eliminado la variable de entorno N8N_CONFIG_FILES.

Ruta de migración: Elimina esta variable de entorno de tu configuración. Migra la configuración a variables de entorno, archivos .env o configuración basada en _FILE.

CLI y flujos de trabajo​

Reemplazo del comando CLI update:workflow​

El comando CLI update:workflow quedará obsoleto y será reemplazado por dos nuevos comandos que ofrecen funcionalidad similar y una semántica más clara:

  • publish:workflow, con parámetros id y versionId (opcional)
  • Se eliminará el parámetro --all para evitar publicaciones accidentales en entornos de producción
  • unpublish:workflow, con parámetros id y all

Ruta de migración: Usa el nuevo comando publish:workflow para publicar flujos de trabajo individualmente por ID, opcionalmente especificando una versión. Para cancelar la publicación, usa el nuevo comando unpublish:workflow. Esto proporciona mayor claridad y control sobre el estado de publicación de los flujos de trabajo.

Hooks externos (External Hooks)​

Obsolescencia de los hooks de frontend para flujos de trabajo​

Las funciones hook workflow.activeChange y workflow.activeChangeCurrent quedarán obsoletas y serán reemplazadas por el nuevo hook workflow.published. Este nuevo hook se activará cada vez que se publique cualquier versión de un flujo de trabajo.

Ruta de migración: Actualiza tu código para usar el nuevo hook workflow.published en lugar de workflow.activeChange y workflow.activeChangeCurrent. Este hook ofrece un comportamiento más consistente y se activa al publicar una versión de flujo de trabajo.

Canales de lanzamiento​

n8n ha renombrado los canales de lanzamiento de latest y next a stable y beta, respectivamente.

La etiqueta stable indica la última versión estable, y la etiqueta beta indica la última versión experimental. Estas etiquetas están disponibles tanto en npm como en Docker Hub. Actualmente, n8n seguirá aplicando las etiquetas latest y next a las versiones publicadas, pero estas se eliminarán en futuras versiones principales.

Recomendación: Te recomendamos usar una versión específica de n8n, como 2.0.0.

Informar problemas​

Si encuentras algún problema al actualizar a n8n 2.0, visita el foro de la comunidad para obtener ayuda y soporte.