Cambios importantes de n8n v2.0 | Documentación de n8n

n8n v2.0 se publicará próximamente. Este documento destaca los cambios importantes que introducen incompatibilidades, así como las medidas que debes tomar para preparar la transición. Estas actualizaciones mejoran la seguridad, simplifican la configuración y eliminan funcionalidades heredadas.

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

Cambios de comportamiento

Devolver los datos esperados cuando un subflujo de trabajo se reanuda desde un estado de espera

Anteriormente, cuando la ejecución padre llamaba a un subflujo de trabajo que contenía un nodo que hacía que la ejecución hija entrara en estado de espera, y la ejecución padre estaba configurada para esperar a que terminara la ejecución hija, la ejecución padre recibía un resultado incorrecto.

Por ejemplo, la ejecución hija entra en estado de espera cuando incluye un nodo Wait con un tiempo de espera superior a 65 segundos, una llamada Webhook, un envío de formulario o un nodo de revisión humana (como un nodo Slack).

Flujo de trabajo padre:

Subflujo de trabajo:

v1: la ejecución padre reproducía como salida la entrada del subflujo de trabajo:

v2: la ejecución padre recibe el resultado del subflujo de trabajo:

Esto permite usar nodos de revisión humana en subflujos de trabajo y utilizar sus resultados en el flujo de trabajo padre, por ejemplo, para aprobar o rechazar una acción.

Ruta de migración: revisa todos los flujos de trabajo que llamen a subflujos de trabajo y esperen recibir la entrada del subflujo. Actualízalos para adaptarlos al nuevo comportamiento: el flujo de trabajo padre recibirá la salida final del subflujo de trabajo, no su entrada.

Eliminar el nodo Start

El nodo Start deja de ser compatible. Este nodo era la forma original de iniciar un flujo de trabajo, pero ahora ha sido sustituido por nodos de activación más específicos.

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

• Ejecución manual: sustituye el nodo Start por un nodo Manual Trigger.
• Subflujo de trabajo: si otro flujo de trabajo llama a este flujo de trabajo como subflujo, sustituye el nodo Start por un nodo Execute Workflow Trigger y activa el flujo de trabajo.
• Nodo Start deshabilitado: si el nodo Start ya estaba deshabilitado, elimínalo del flujo de trabajo.

Guardar y publicar flujos de trabajo

El nuevo sistema de publicación de flujos de trabajo sustituye al anterior interruptor de activación/desactivación. El antiguo interruptor de "activar/desactivar" pasa a ser el nuevo botón de "publicar/retirar la publicación". Este cambio te permite controlar mejor cuándo se publican los cambios de los flujos de trabajo y reduce el riesgo de desplegar accidentalmente cambios en curso en el entorno de producción. Para más información, consulta: guardar y publicar flujos de trabajo.

Eliminar nodos de servicios retirados

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 usan alguno de los nodos anteriores, actualízalos o elimínalos para evitar errores.

Seguridad

Bloquear por defecto el acceso a variables de entorno desde el nodo Code

Para mejorar la seguridad, n8n bloqueará por defecto el acceso del nodo Code a las variables de entorno. El valor predeterminado de N8N_BLOCK_ENV_ACCESS_IN_NODE pasará a ser 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 configuración de entorno. Para datos sensibles, se recomienda usar credenciales u otros métodos seguros en lugar de variables de entorno.

Exigir permisos estrictos en los archivos de configuración

n8n exigirá permisos estrictos para los archivos de configuración con el fin de mejorar la seguridad. Por defecto, los archivos de configuración deberán tener permisos 0600, lo que significa que solo el propietario del archivo podrá leerlos y escribirlos. Este enfoque es similar a cómo SSH protege las claves privadas.

Ruta de migración: para probar este comportamiento antes de v2.0, configura N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true. Si tu entorno no admite permisos de archivo, por ejemplo en Windows, configura N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false para desactivar este requisito.

Activar por defecto el ejecutor de tareas

n8n activará por defecto el ejecutor de tareas para mejorar la seguridad y el aislamiento. Todas las ejecuciones de nodos Code se ejecutará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 una protección adicional, puedes considerar el uso del modo externo.

Eliminar el ejecutor de tareas de la imagen Docker n8nio/n8n

A partir de la v2.0, la imagen Docker principal n8nio/n8n ya no incluirá el ejecutor de tareas para el modo externo. Deberás usar la imagen Docker independiente 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.

Eliminar el nodo Python Code y las herramientas basados en Pyodide

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

El nodo Python Code nativo no admite las variables integradas que ofrecía la versión con Pyodide, como _input, ni la notación de acceso por punto. Consulta la documentación del nodo Code para obtener más información.

Las herramientas de Python nativo admiten _query, que corresponde a la cadena de entrada que recibe la herramienta cuando la llama un agente de IA.

Ruta de migración: para seguir usando Python en el nodo Code, configura el ejecutor de tareas en modo externo y comprueba si tus nodos y herramientas Python Code actuales son compatibles.

Desactivar por defecto los nodos ExecuteCommand y LocalFileTrigger

n8n desactivará por defecto los nodos ExecuteCommand y LocalFileTrigger debido a sus riesgos de seguridad. Estos nodos permiten a los usuarios ejecutar comandos arbitrarios y acceder al sistema de archivos.

Ruta de migración: si necesitas usar estos nodos, elimínalos de la lista de nodos deshabilitados en la configuración de n8n actualizando la variable de entorno NODES_EXCLUDE. Por ejemplo, configura NODES_EXCLUDE="[]" para activar todos los nodos, o elimina solo los nodos concretos que necesites.

Requerir por defecto autenticación en la URL de devolución de llamada de OAuth

n8n exigirá por defecto autenticación en el endpoint de devolución de llamada de OAuth. El valor predeterminado de N8N_SKIP_AUTH_ON_OAUTH_CALLBACK cambiará de true (no requiere autenticación) a false (requiere autenticación).

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

Establecer un valor predeterminado para N8N_RESTRICT_FILE_ACCESS_TO

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

Ruta de migración: revisa los flujos de trabajo que utilicen nodos de archivo y asegúrate de que solo acceden a archivos dentro de directorios permitidos. Si necesitas permitir el acceso a otros directorios, configura la variable de entorno N8N_RESTRICT_FILE_ACCESS_TO con la ruta que necesites.

Cambiar el valor predeterminado de N8N_GIT_NODE_DISABLE_BARE_REPOS a true

Por motivos de seguridad, el nodo Git bloqueará por defecto los repositorios bare. El valor predeterminado de N8N_GIT_NODE_DISABLE_BARE_REPOS pasa a ser true, lo que significa que los repositorios bare estarán desactivados salvo que cambies esta configuración.

Ruta de migración: si tus flujos de trabajo necesitan usar repositorios bare, configura N8N_GIT_NODE_DISABLE_BARE_REPOS=false en tu entorno para activarlos.

Datos

Fin del soporte para MySQL/MariaDB

n8n dejará de admitir MySQL y MariaDB como sistemas de almacenamiento. Este soporte ya se había marcado como obsoleto en la v1.0. Para obtener la mejor compatibilidad y soporte a largo plazo, utiliza PostgreSQL. El nodo MySQL seguirá siendo compatible como hasta ahora.

Ruta de migración: antes de actualizar a v2.0, utiliza una herramienta de migración de bases de datos para trasladar tus datos de MySQL o MariaDB a PostgreSQL o SQLite.

Eliminar el controlador SQLite heredado

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

Ruta de migración: el controlador sqlite-pooled pasará automáticamente a ser el predeterminado. Puedes activar el pool de conexiones de inmediato estableciendo DB_SQLITE_POOL_SIZE con un valor superior a 0. El tamaño predeterminado del pool será 2.

Eliminar el modo de datos binarios en memoria

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

• filesystem: los datos binarios se almacenan en el sistema de archivos (opción predeterminada en modo normal).
• database: los datos binarios se almacenan en la base de datos (opción predeterminada en modo de 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 quedará determinado únicamente por N8N_DEFAULT_BINARY_DATA_MODE.

Ruta de migración: se utilizará automáticamente el modo de sistema de archivos o de base de datos según la configuración. Asegúrate de que tu instancia de n8n dispone de suficiente espacio en disco para almacenar datos binarios. Consulta la configuración de datos binarios para obtener más información.

Configuración y entorno

Actualizar dotenv

n8n utiliza la biblioteca dotenv para cargar la configuración del entorno desde el archivo .env. Esta biblioteca se actualizará de la versión 8.6.0 a la versión más reciente, lo que puede cambiar la forma en que se interpreta el archivo .env. Los principales cambios incompatibles son:

• Compatibilidad con comillas invertidas (#615): si tus valores contienen comillas invertidas, enciérralos entre comillas simples o dobles.
• Compatibilidad con valores multilínea: ahora pueden utilizarse valores multilínea.
• # marca el inicio de un comentario: las líneas que empiezan por # se tratarán como comentarios.

Ruta de migración: revisa el registro de cambios de dotenv y actualiza tu archivo .env para garantizar la compatibilidad con la nueva versión.

Eliminar la opción n8n --tunnel

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

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

Eliminar QUEUE_WORKER_MAX_STALLED_COUNT

Se eliminarán la variable de entorno QUEUE_WORKER_MAX_STALLED_COUNT y el mecanismo de reintento de tareas bloqueadas de Bull, ya que a menudo generan confusión y no funcionan de forma fiable.

Ruta de migración: elimina esta variable de entorno de tu configuración. Después de la actualización, n8n ya no reintentará automáticamente las tareas bloqueadas. Si necesitas gestionar tareas bloqueadas, considera implementar tu propia lógica de reintento o supervisión.

Eliminar N8N_CONFIG_FILES

La variable de entorno N8N_CONFIG_FILES se eliminará.

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

Sustituir el comando CLI update:workflow

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

• publish:workflow, con los parámetros id y versionId (opcional)
• Se eliminará el parámetro --all para evitar la publicación accidental de flujos de trabajo en producción
• unpublish:workflow, con los parámetros id y all

Ruta de migración: usa el nuevo comando publish:workflow para publicar flujos de trabajo individualmente por ID, con la opción de especificar una versión. Para retirar la publicación, usa el nuevo comando unpublish:workflow. Esto ofrece mayor claridad y mejor control sobre el estado de publicación de los flujos de trabajo.

Hooks externos

Desuso de los hooks de flujos de trabajo del frontend

Las funciones hook workflow.activeChange y workflow.activeChangeCurrent quedarán obsoletas y serán sustituidas por el nuevo hook workflow.published. El nuevo hook se activará cuando 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 coherente y se activa cuando se publica una versión del flujo de trabajo.

Canales de lanzamiento

n8n ha cambiado el nombre de sus canales de lanzamiento: latest y next pasan a llamarse stable y beta, respectivamente.

La etiqueta stable indica la versión estable más reciente, y la etiqueta beta indica la versión experimental más reciente. Estas etiquetas están disponibles tanto en npm como en Docker Hub. Por ahora, n8n seguirá etiquetando las versiones publicadas también como latest y next. Estas etiquetas se eliminarán en una futura versión principal.

Recomendación: fija la versión de n8n a un número de versión concreto, por ejemplo 2.0.0.

Problemas y comentarios

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