n8n 2.0: cambios y contexto de la migración de 2025

Antes de migrar: prepara una copia de seguridad

Cambiar a una imagen anterior no revierte por sí solo las migraciones de la base de datos. La posibilidad de volver atrás depende de las versiones y migraciones implicadas. Prepara y comprueba una copia de seguridad antes de actualizar; no des por hecho que podrás deshacer el cambio. Documentación de reversión.

Ahora que os he avisado, ya puedo continuar... Llevo más de un año trabajando con despliegues de n8n, y cuando vi el anuncio de v2.0, mi primer pensamiento no fue "qué funciones tan geniales", fue "¿cuántos workflows en producción voy a tener que arreglar?"

¿Y sabes qué? Este lanzamiento es realmente bueno, pero van a romper tus cosas si no te preparas.

Calendario del lanzamiento de diciembre de 2025

• Beta: 8 de diciembre, 2025
• Estable: 15 de diciembre, 2025
• Recomendación de aquel anuncio: probar antes de migrar

La versión 1.x tendrá 3 meses de parches de seguridad después del lanzamiento de v2, y luego se acabó.

Las cosas buenas

Autoguardado viene en camino. Sí, por fin. ¿Después de cuántos años de gente perdiendo trabajo? Mejor tarde que nunca.

También: interfaz de canvas actualizada, nueva barra lateral, y "sorpresas".

Pero seamos realistas, no estás aquí por las actualizaciones de UI.

Las cosas que realmente van a romper tus workflows

Seguridad: están bloqueando todo

1. El nodo Code ya no puede acceder a variables de entorno

N8N_BLOCK_ENV_ACCESS_IN_NODE=true  # Este es ahora el valor por defecto

Revisa los nodos Code que dependan de variables de entorno. Traslada los valores sensibles a las credenciales de n8n y utiliza nodos o integraciones que admitan esas credenciales. Desactivar la nueva restricción cambia el aislamiento de seguridad; no debería ser la solución predeterminada de la migración. Guía de migración a 2.0.

2. Los task runners se activan por defecto

En n8n 2.0, las ejecuciones de los nodos Code utilizan task runners por defecto. En una versión 1.x compatible, N8N_RUNNERS_ENABLED=true permite probar este comportamiento antes de actualizar; desde 2.0 ese parámetro ya no es necesario.

JavaScript admite el modo interno. Python nativo requiere el modo externo, y n8n recomienda runners externos con medidas adicionales de aislamiento en producción o con datos sensibles. Activar los runners no configura por sí solo los contenedores externos, su conexión al broker ni sus permisos. Configuración de runners.

3. Nodo Python Code: reescritura completa

Eliminaron Pyodide (el Python basado en navegador). Ahora es Python nativo solamente, task runners requeridos, modo externo obligatorio.

Lo que se rompe:

• Variable _input (eliminada)
• Notación de acceso por punto (eliminada)
• Cualquier nodo Python Code sin configuración apropiada de task runner (roto)

Esto es mejor a largo plazo, pero el dolor de migración es importante. Revisa todos los nodos Python Code que tengas.

4. ExecuteCommand y LocalFileTrigger: deshabilitados por defecto

Estos nodos permiten ejecutar comandos del sistema o vigilar archivos locales, por lo que n8n 2.0 los deshabilita por defecto. Mantén esas exclusiones salvo que un workflow revisado necesite un nodo concreto.

NODES_EXCLUDE contiene los nodos que no deben cargarse. Una lista vacía habilita todos los nodos; no es una medida de seguridad que debas copiar en todos los despliegues. Si decides habilitar uno, elimina solo ese nodo de la lista de exclusiones existente y conserva los demás. Configuración de nodos.

5. Los Callbacks de OAuth Necesitan Autenticación

N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false  # Nuevo valor por defecto

Antes de actualizar, prueba cada integración OAuth. Slack, Google, lo que sea que tengas conectado, pruébalo todo.

6. Las Operaciones con Archivos Están en Sandbox

N8N_RESTRICT_FILE_ACCESS_TO=~/.n8n-files  # Nuevo valor por defecto

Los nodos ReadWriteFile y ReadBinaryFiles solo pueden tocar archivos en este directorio ahora. Bueno para seguridad, molesto si has estado leyendo archivos de ubicaciones aleatorias.

7. Permisos del archivo de configuración

n8n 2.0 exige permisos 0600 en su archivo de configuración: solo su propietario puede leerlo o escribirlo. Antes de actualizar, prueba con N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true y comprueba el propietario y los permisos del archivo en el entorno donde se ejecuta realmente n8n.

La excepción documentada es un entorno que no admita esos permisos; en ese caso se puede desactivar la comprobación. Que el host sea Windows no basta para desactivarla dentro de un contenedor Linux. Revisa el sistema de archivos y el comportamiento del volumen montado. Guía de migración.

Cambios en la base de datos (los dolorosos)

MySQL/MariaDB: eliminados

Se acabó. Solo PostgreSQL o SQLite. Esto fue deprecado en v1.0, si todavía estás en MySQL, el aviso de migración venía de julio de 2023.

Usa la herramienta de migración de base de datos o estás fregado.

SQLite: Driver Legacy eliminado

Solo queda el driver de pooling. Usa el modo WAL y pasa a ser la opción predeterminada; n8n publicó mejoras de hasta 10 veces en sus pruebas.

DB_SQLITE_POOL_SIZE=2  # Auto-configurado

La mayoría de la gente no notará este cambio. Si lo haces, probablemente es porque algo estaba roto antes.

Datos binarios: No más modo In-memory

¿El modo default que mantiene datos binarios en memoria durante la ejecución? Se fue.

Tus opciones:

• filesystem (por defecto para instancia única)
• database (por defecto para modo queue)
• s3 (si eres elegante)

Asegúrate de tener espacio en disco. Si estás procesando archivos grandes y de repente te quedas sin espacio, esta es la razón.

Cambios de comportamiento (los sutiles)

Subworkflow + Wait Node = Arreglado

Antes: El workflow padre recibía el input de los nodos Wait en workflows hijos (lo cual no tenía sentido)

Ahora: El workflow padre recibe el output del final del workflow hijo (lo cual es correcto)

Si tienes workflows llamando subworkflows con nodos Wait, revísalos. El cambio de comportamiento es correcto, pero tu lógica podría depender del comportamiento roto anterior.

Infierno de configuración

Actualización de dotenv

El parsing de tu archivo .env es diferente ahora.

Cambios:

• Los backticks necesitan comillas ahora
• Un # sin comillas inicia un comentario; escribe entre comillas los valores que contengan #
• Los valores multilínea funcionan ahora

Revisa tus archivos .env. Especialmente si tienes caracteres raros en contraseñas o tokens.

Cosas eliminadas:

• QUEUE_WORKER_MAX_STALLED_COUNT
• Opción CLI n8n --tunnel (usa ngrok o Cloudflare Tunnel)
• update:workflow --all --active=true (buen viaje, esto era peligroso)

Nodos eliminados:

• Spontit
• crowd.dev
• Kitemaker

Arquitectura de Docker para migrar a 2.0

Los ejemplos anteriores mezclaban etiquetas latest sin fijar, credenciales de ejemplo y parámetros que volvían a habilitar nodos desactivados. Se han retirado. Esta sección explica la migración de diciembre de 2025; no es una receta completa de despliegue ni se ha validado de principio a fin.

Runners internos y externos

Desde 2.0, la imagen principal de n8n ya no incluye el runner externo. La imagen oficial separada de runners incluye JavaScript y Python. Los paquetes adicionales pueden requerir ampliar esa imagen y configurar listas de módulos permitidos; instalar un paquete no lo hace accesible automáticamente a los nodos Code.

La conexión al broker

La dirección importa: runner → broker de n8n, con la dirección privada del broker en el puerto 5679 por defecto. Un despliegue de una sola instancia no necesita Redis por utilizar runners externos; el modo de colas tiene un requisito de Redis independiente.

Estos son parámetros de conexión, no un archivo de Compose. Mantén privado el broker, fija imágenes compatibles de n8n y de los runners a la misma versión y configura la autenticación, el almacenamiento y el proxy para tu entorno. 1.111.0 es el mínimo documentado de esta configuración auxiliar, no una recomendación de versión actual. En modo de colas, cada worker necesita un runner; main también lo necesita si ejecuta workflows manuales.

Mantén las exclusiones predeterminadas de ExecuteCommand y LocalFileTrigger. Revisa cualquier lista personalizada de exclusiones en lugar de sustituirla por una lista vacía.

Implementación y validación

Sigue la configuración oficial de runners, las variables de los runners y las medidas de aislamiento para la versión elegida. Comprueba la compatibilidad de las imágenes, el acceso privado al broker, la coincidencia de los tokens, los permisos y las dependencias que utilizan tus workflows.

Después prueba nodos Code reales de JavaScript/Python, callbacks de OAuth, operaciones con archivos, persistencia y recuperación tras reinicios en un entorno separado. Que los contenedores arranquen no valida una migración. Los contenedores externos mejoran la separación; no garantizan protección frente a cualquier script malicioso, agotamiento de recursos o error de configuración.

Cómo no arruinar esto

Paso 1: revisa el reporte de migración

Settings → Migration Report (necesitas acceso de admin)

Disponible desde v1.121.0. Ejecútalo ahora.

Paso 2: decide tu modo de runner

¿Usas nodos Code con Python nativo? → El modo externo es obligatorio. ¿Producción o datos sensibles? → Modo externo, medidas de aislamiento y validación. ¿Pruebas aisladas de JavaScript sin datos sensibles? → El modo interno puede ser una opción.

Paso 3: si vas con modo externo, genera token

openssl rand -hex 32

Edita .env:

N8N_RUNNERS_AUTH_TOKEN=tu-token-aqui

Configura permisos:

chmod 600 .env

Paso 4: prueba el conjunto en staging

En una versión 1.x compatible, activa los task runners y prueba los nuevos valores predeterminados de OAuth y permisos antes de migrar. En 2.0 los runners ya están activados; verifica el modo real, la conexión al broker y el comportamiento de los workflows. Mantén bloqueado el acceso al entorno y conserva las exclusiones de nodos predeterminadas. Unos pocos parámetros no sustituyen las pruebas del despliegue completo.

Paso 5: revisa cada nodo Code

Especialmente:

• Cualquier cosa usando process.env
• Todos los nodos Python Code
• Operaciones de archivo

Paso 6: prueba OAuth

Todas las integraciones. Manualmente. Sin excepciones.

Paso 7: respalda todo

Base de datos, workflows, credenciales, configs, directorio .n8n completo.

Paso 8: Ayuda a encontrar los bugs

Reporta los bugs ya sea en un issue en el repositorio o en el foro de la comunidad n8n.

Mi opinión

Este es el lanzamiento más significativo de n8n desde 1.0. Las mejoras de seguridad son necesarias.

Para pruebas aisladas, el modo interno es más sencillo. En producción o con datos sensibles, sigue la configuración externa y las medidas de aislamiento, y comprueba el flujo completo antes de migrar.

El modo externo es obligatorio para Python nativo y se recomienda con medidas de aislamiento en producción. Si utilizas workers con colas, proporciona a cada uno la configuración de runners que necesita.

Si estás corriendo n8n en producción (como yo todos los días), tómate esto en serio. Presupuesta tiempo real para pruebas y migración. No solo hagas docker pull y esperes lo mejor.

El lanzamiento añade valores predeterminados de seguridad útiles y elimina componentes antiguos. La fiabilidad de tu migración depende de la configuración, los workflows y las pruebas de recuperación que realmente compruebes.

Recursos

• Documentación de cambios que rompen
• Documentación de task runners
• Notas de lanzamiento
• Anuncio de la comunidad