n8n 3.0: qué cambia y cómo migrar sin romper tus automatizaciones

n8n 3.0 es la primera versión mayor de n8n que acumula cambios incompatibles desde la 2.0. La beta salió el 27 de octubre de 2026 y la versión estable se espera para principios de diciembre. Si tu empresa usa n8n autoalojado tienes que prepararte por tres motivos: solo se podrá instalar con Docker (adiós a npm y npx n8n), desaparecen decenas de nodos heredados (Function, Cron, Interval, Read PDF, el OpenAI antiguo, el AI Agent v1…) y cambian varios valores de seguridad y configuración. Además, el salto es de un solo sentido: no hay vuelta a la 2.x. La forma segura de hacerlo es actualizar al último 2.x, revisar el Migration Report, hacer copia de seguridad completa y probar en una instancia de pruebas antes de tocar producción.

Te contamos qué cambia, qué flujos se pueden romper y cómo planificar la migración sin que tu equipo se entere de nada un lunes por la mañana.

Calendario de n8n 3.0: fechas que tienes que apuntar

Según el anuncio oficial en la comunidad de n8n, este es el calendario:

El dato más urgente es el de la 1.x. Quien siga en esa rama no puede saltar directamente a la 3.0: primero tiene que pasar por la 2.x. Y no es un tema menor, porque n8n publica boletines de seguridad cada dos semanas. El del 1 de octubre de 2026 recogía 14 avisos, 10 de ellos de severidad alta. Quedarse en una versión sin soporte con flujos que tocan clientes, facturas o pedidos es un riesgo real.

Qué se rompe en n8n 3.0: los cambios incompatibles

La lista completa está en la página oficial de cambios incompatibles de n8n 3.0. Estos son los que más afectan a una pyme.

Instalación: n8n 3.0 solo funciona con Docker

Se acaban las instalaciones con npm o npx n8n, y no se publicará en npm ningún paquete n8n ejecutable. Si tu instancia la montó alguien en un VPS con npm install -g n8n, tienes que pasar a Docker antes de actualizar. Si ya usas Docker Compose, no tienes que cambiar nada. Kubernetes y Helm tampoco se ven afectados.

Nodos eliminados en n8n 3.0 y su sustituto

Los flujos que usen estos nodos fallarán después de actualizar. Estos son los más habituales en flujos antiguos:

Agentes de IA: adiós al AI Agent v1

Si montaste un agente en 2024 o principios de 2025, revísalo con lupa. Se elimina la versión 1 del nodo AI Agent con todos sus modos (SQL Agent, Conversational Agent, ReAct, Plan and Execute, OpenAI Functions). Hay que pasar a la versión actual con Tools Agent. Para consultas SQL, la recomendación oficial es conectar una herramienta de Postgres o MySQL al agente. También se retira la pestaña «Ask AI» del nodo Code y el nodo AI Transform: los existentes se convierten solos en nodos Code.

Seguridad: valores por defecto más estrictos

• Slack: la credencial de la API de Slack exige el signing secret. Sin él, los flujos con Slack Trigger dejan de recibir eventos sin dar ningún error visible. Si avisas al comercial por Slack cuando entra un lead, este cambio te afecta.
• Rotación de la clave de cifrado activada por defecto. No tienes que hacer nada, pero sí sacar antes una copia de seguridad de la base de datos.
• Protección SSRF ampliada: se bloquean más rangos de IP. Si n8n llama a servicios internos de tu red (un ERP local, una API en otra máquina), puede que tengas que añadirlos a N8N_SSRF_ALLOWED_IP_RANGES.
• Nodos de comunidad no verificados: dejan de cargarse por defecto (N8N_UNVERIFIED_PACKAGES_ENABLED=false).

Configuración y comportamiento

• El tiempo máximo de una tarea del nodo Code baja de 300 a 60 segundos. Si tienes scripts que procesan catálogos grandes o ficheros pesados, ajusta N8N_RUNNERS_TASK_TIMEOUT.
• La carpeta ~/.n8n/binaryData pasa a llamarse ~/.n8n/storage. Si existen las dos, n8n no arranca.
• El Gmail Trigger cambia de comportamiento: ignora borradores y correos enviados o programados. Revisa este punto si tus flujos de captación de leads dependen del correo.
• Desaparece «Import from URL» del editor, y Chat Hub queda desactivado por defecto.

Cómo migrar a n8n 3.0 paso a paso

Este es el procedimiento que seguimos en las instancias que mantenemos. Se basa en la guía oficial y le añade los controles que, en la práctica, evitan sustos:

1. Haz inventario. Anota la versión exacta, cómo está instalada (npm, Docker, Compose, Kubernetes), qué base de datos usa (SQLite o Postgres) y qué flujos son críticos para el negocio: pedidos, facturación, leads, avisos a clientes.
2. Si estás en 1.x, sube primero a 2.x. No hay salto directo de la 1.x a la 3.x.
3. Actualiza al último 2.x y abre Settings > Migration Report (disponible desde la 2.39). El informe marca los flujos y ajustes de la instancia que se verán afectados, y muchos se pueden corregir automáticamente como versiones nuevas del flujo, que revisas antes de publicar.
4. Corrige o descarta cada aviso. Sustituye los nodos heredados, añade el signing secret de Slack y ajusta las variables de entorno. Lo que no vayas a arreglar, márcalo como «won't fix» para que quede documentado.
5. Copia de seguridad completa. Base de datos, carpeta .n8n y, sobre todo, la clave N8N_ENCRYPTION_KEY. Sin esa clave, las credenciales guardadas no sirven para nada. Las migraciones de base de datos solo van hacia delante, así que la copia es tu única marcha atrás.
6. Si usas npm, pasa a Docker con la instalación de una línea o con Docker Compose. Para producción, mejor Postgres que SQLite.
7. Fija la versión de la imagen (nada de latest) para que una actualización automática no te cuele la 3.0 sin planificar.
8. Prueba en staging. Clona la instancia, actualiza la copia y ejecuta los flujos críticos con datos de prueba: un pedido, un lead, una factura.
9. Actualiza producción en una ventana tranquila y vigila las ejecuciones fallidas durante las primeras 48 horas.

¿Debes migrar ya a n8n 3.0? Criterios para decidir

No tienes que correr, pero tampoco puedes dejarlo para marzo. Esta tabla te ayuda a decidir:

Una orientación sobre el esfuerzo, sacada de nuestra experiencia y no de un estudio: una instancia en Docker con una docena de flujos sencillos y sin nodos heredados suele quedar lista en pocas horas. Una instalación con npm, SQLite, agentes v1 y decenas de flujos sin documentar puede llevar varios días entre migrar, rehacer y probar. Lo que más cuesta no es actualizar, sino descubrir qué hace cada flujo cuando nadie se acuerda de quién lo montó.

Errores habituales al actualizar n8n (y cómo evitarlos)

• Usar la etiqueta latest en Docker. El día que salga la 3.0 estable, un simple reinicio puede actualizarte sin que lo hayas decidido.
• Hacer copia de la base de datos pero no de la clave de cifrado. Recuperas los flujos, pero todas las credenciales quedan inservibles.
• Dar por buena la migración porque «arranca». El Slack Trigger sin signing secret o el Gmail Trigger con el nuevo comportamiento no dan error: simplemente dejan de disparar. Comprueba las ejecuciones, no solo que el panel abre.
• No revisar los scripts largos del nodo Code. Con el nuevo límite de 60 segundos, la sincronización nocturna del catálogo puede empezar a fallar sin que nadie lo vea.
• Migrar sin dueño de cada flujo. El Migration Report permite asignar flujos a responsables y avisarles por email. Úsalo.

Si la migración te obliga a revisar todos tus flujos, aprovecha para limpiar los que ya no usas y para preguntarte si sigue compensando tenerlo autoalojado. Aquí explicamos por qué n8n elimina los costes variables frente a Zapier o Make. Y si tus automatizaciones alimentan el embudo comercial, es buen momento para conectarlas bien con un CRM con IA que puntúe y reparta los leads en lugar de depender de avisos sueltos por Slack o correo.

Preguntas frecuentes

¿Cuándo sale n8n 3.0 estable?

La beta está disponible desde el 27 de octubre de 2026 y n8n prevé la versión estable para principios de diciembre de 2026. Para producción, espera a la estable.

¿Puedo volver a n8n 2.x si algo falla tras actualizar?

No. El paso a la 3.x es irreversible y las migraciones de base de datos solo van hacia delante. Tu única marcha atrás es restaurar la copia de seguridad que hayas hecho antes, con la base de datos y la clave de cifrado.

¿Afecta n8n 3.0 a los usuarios de n8n Cloud?

Sí, en los flujos. Los nodos eliminados y los cambios de comportamiento se aplican a todas las ediciones, así que también tienes que revisar el Migration Report. Lo que no te afecta es el paso a Docker, porque la infraestructura la gestiona n8n.

¿Qué pasa si sigo en n8n 1.x después del 31 de diciembre?

Tus flujos seguirán funcionando, pero sin parches de seguridad. Con un ritmo de boletines quincenales y fallos de severidad alta cada pocas semanas, no es recomendable para una instancia expuesta a internet o con credenciales de clientes.

Si no tienes claro en qué versión estás, cuántos flujos usan nodos heredados o cómo pasar de npm a Docker sin parar la operación, podemos ayudarte. En Guznel Flow auditamos tu instancia, preparamos el Migration Report, rehacemos los flujos y agentes afectados y hacemos la actualización en staging antes de tocar producción. Cuéntanos tu caso en nuestra página de automatización de procesos con n8n y te diremos qué hay que tocar y cuánto llevaría.