n8n 2.0 guía de cambios y migración segura en producción

n8n 2.0 no es un “update de fueguitos”, es una hardening release: más seguridad por defecto, menos comportamientos legacy raros y una base más confiable para correr automatizaciones críticas.

Si tienes n8n en producción (self-hosted o cloud) y tus flujos hacen cosas serias como facturación, onboarding, tickets o sincronización de datos, esto te interesa porque sí hay breaking changes reales.

Qué es n8n 2.0 y por qué importa

n8n 2.0 se enfoca en:

Secure by default: cierra accesos peligrosos que antes podían filtrar secretos o permitir ejecución riesgosa.
Aislamiento de ejecución: especialmente cuando usas Code node (JavaScript/Python).
Más predictibilidad bajo carga: menos edge cases por configuraciones heredadas.

Breaking changes clave en n8n 2.0

Start node eliminado

Si tenías workflows antiguos que dependían de ese nodo, toca ajustar el flujo (en muchos casos es solo rearmar el inicio con triggers/steps actuales).

Code node ya no puede leer variables de entorno por defecto

Esto es de los cambios más “ouch”: por seguridad, n8n bloquea el acceso a process.env desde Code node por defecto.

Qué hacer si lo necesitas sí o sí

Puedes desactivar el bloqueo con esta variable:
- N8N_BLOCK_ENV_ACCESS_IN_NODE=false
Pero la recomendación sana es: secretos en credenciales (y/o soluciones de secretos), no en env vars dentro del código.

Task runners activados por defecto

n8n habilita task runners por defecto y todas las ejecuciones de Code node pasan por ahí. Esto mejora aislamiento y seguridad.

Antes podías “vivir peligrosamente” con configuraciones menos estrictas; ahora n8n dice “producción = cinturón puesto”. Y sí, se agradece.

Docker cambia si usas task runners en modo externo

A partir de 2.0, la imagen principal n8nio/n8n ya no incluye el task runner para modo externo. Debes usar la imagen separada n8nio/runners si corres runners externos.

ExecuteCommand y LocalFileTrigger deshabilitados por defecto

Por seguridad, estos nodos quedan apagados por default. Si los necesitas, tienes que permitirlos explícitamente.

Otros cambios que pueden pegarte

OAuth callbacks ahora requieren auth por defecto (cambia N8N_SKIP_AUTH_ON_OAUTH_CALLBACK).
Se elimina n8n --tunnel (si lo usabas para dev, toca usar otra opción).
Se deja de soportar MySQL/MariaDB como base de datos de almacenamiento (si estabas ahí, hay que migrar).

Cómo migrar a n8n 2.0 sin romper medio negocio

1) Usa el Migration Report antes de actualizar

n8n incluye una herramienta para escanear tu instancia y decirte qué workflows y settings tienen problemas para 2.0.

Dónde está

Settings → Migration Report (solo global admins).

Cómo leerlo

Te muestra “X de Y workflows son compatibles”
Separa Workflow Issues vs Instance Issues
Ordena por severidad (Critical primero).

2) Arma un entorno de prueba y replica lo crítico

Si tu n8n mueve dinero, usuarios o infraestructura, lo ideal:

clonar config (sin exponer secretos),
probar workflows top (los que más ejecuciones tienen),
validar integraciones OAuth,
y revisar cualquier Code node.

3) Ajusta configuración “mínima” para probar el nuevo comportamiento

Ejemplo de variables típicas que podrías tocar según tu caso (no copies a lo loco, úsalo como guía):

# Prueba el comportamiento de task runners (recomendado antes de actualizar)
N8N_RUNNERS_ENABLED=true

# Si tus Code nodes dependen de env vars (mejor migrar a credenciales, pero en emergencia…)
N8N_BLOCK_ENV_ACCESS_IN_NODE=false

# OAuth callback con autenticación (lo nuevo por defecto)
N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false

Qué estás haciendo aquí:

activas runners para detectar problemas temprano,
decides si vas a permitir env vars en Code node o migras a credenciales,
y pruebas el cambio de OAuth antes de pegarte el susto en producción.

4) Si usas Docker con runners externos, prepara `n8nio/runners`

Si tu arquitectura separa runners (external mode), en 2.0 ya no basta con la imagen principal. Hay que sumar n8nio/runners.

5) Reescanea y valida

La herramienta recomienda corregir issues, refrescar y verificar que todo quede compatible antes de actualizar.

Mejores prácticas para n8n 2.0 en producción

Evita secretos en env vars dentro de Code node: si algo se filtra, duele más que un “rm -rf” mal puesto. El enfoque de 2.0 va justo contra eso.
Minimiza nodos peligrosos (ExecuteCommand, LocalFileTrigger) y habilítalos solo cuando de verdad no haya alternativa.
Versiona y fija versiones: n8n recomienda pinnear a una versión específica para evitar sorpresas.
Prueba bajo carga si tienes picos fuertes: 2.0 busca mejor performance bajo load, pero cada instalación es su propio universo.

Conclusión

n8n 2.0 es un upgrade con mentalidad de “producción real”: más seguridad por defecto, mejores bases para escalar y cambios que obligan a tener los workflows bien hechos.

n8n 2.0 guía de cambios y migración segura en producción