n8n 3.0 en beta: los cambios que rompen workflows

n8n 3.0: una versión que no trae features y aun así te obliga a moverte

La beta de n8n 3.0.0 ya está disponible y la versión estable llega a principios de diciembre. No hay funciones nuevas: es una release de cimientos que elimina nodos legacy, endurece los valores por defecto de seguridad y rompe compatibilidad con workflows y configuraciones existentes. Si tu negocio corre sobre automatizaciones en n8n, esto te toca antes de fin de año.

El dato que más debería mover a un founder: el self-hosted deja de instalarse con npm o npx n8n. A partir de 3.0, n8n corre sobre Docker, y no es capricho — parte de las nuevas funciones de seguridad dependen de un entorno de contenedor. Si tu equipo levantó n8n con un npx rápido en un VPS para probar una idea, ese camino se cierra.

¿Por qué n8n salta de la 2.x a la 3.0 sin features nuevas?

n8n sigue versionado semántico: los cambios que rompen cosas solo pueden entrar en un salto de versión mayor. Durante el último año la compañía acumuló una lista de arreglos incómodos —rutas de código heredadas que había que borrar, defaults que había que hacer más seguros, funciones a retirar— y cada uno esperaba su turno en una major.

La 3.0 los junta todos de una vez. Y las features no se quedaron esperando: desde que salió la 2.0 en diciembre de 2025, el equipo publicó más de 45 releases, aproximadamente una por semana, muchas con funciones importantes. Por eso esta versión puede dedicarse solo a la base, y todo lo nuevo que venga después de la estable saldrá en la rama 3.x.

¿Qué cambia en fiabilidad y estabilidad?

Cuatro movimientos que afectan a cualquiera que tenga workflows en producción:

• Queue mode: las ejecuciones manuales ahora siempre corren en workers, así la instancia principal no carga con ese trabajo.
• Datos binarios: se elimina el modo en memoria. Las instancias usan filesystem o almacenamiento externo como S3, más predecible bajo carga.
• Límites contra trabajo desbocado: el timeout por defecto del Code node baja de 5 minutos a 1 minuto (configurable), y los límites de descompresión se reducen para proteger la instancia de archivos gigantes tipo "zip bomb".
• Scheduling: los antiguos nodos Cron e Interval son reemplazados por el Schedule Trigger, que corre sobre el scheduler más robusto de n8n.

El punto del Code node es el que más va a doler en la práctica. Un script que procesa un lote grande de datos y tardaba cuatro minutos ahora falla por defecto. No es un bug: es una decisión de diseño para que un workflow mal escrito no tumbe la instancia.

¿Qué cambia en seguridad?

La 3.0 mueve varios defaults hacia el lado conservador:

• La rotación de la clave de cifrado queda siempre activada.
• Las credenciales de Slack exigen un signing secret, de modo que nadie pueda enviar peticiones falsas haciéndose pasar por Slack.
• Se amplía la lista de bloqueo por defecto contra SSRF (server-side request forgery) cuando esa protección está activa.
• Los paquetes de comunidad no verificados quedan desactivados por defecto.

Para un equipo que usa n8n como capa de integración entre sistemas internos, el último punto es el más relevante: si dependes de un nodo comunitario para conectar con un servicio propio, tendrás que habilitarlo explícitamente y asumir la revisión de ese código.

¿Qué nodos y funciones desaparecen?

La limpieza es amplia. Se eliminan los nodos Function, Function Item, Item Lists, Cron, Interval, el nodo legacy de OpenAI, modos antiguos del AI Agent, versiones anteriores del nodo Edit Image y nodos de servicios que ya no existen.

La mayoría tiene reemplazo directo y muchos migran de forma automática: Function pasa a ser el Code node, e Item Lists se reparte entre Split Out, Aggregate, Sort, Limit, Remove Duplicates y Summarize.

También se retiran funciones: Chat Hub queda apagado por defecto (puedes reactivarlo durante la 3.x, mientras el asistente de IA y los agentes de n8n lo reemplazan), Import from URL desaparece del editor y la pestaña Ask AI se va del Code node.

¿Cómo saber si tu instancia está afectada?

Esta es la parte que hay que leer aunque no se lea nada más. Toda instancia en versión 2.39 o superior tiene un Migration Report en Settings > Migration Report.

Qué hace el reporte:

• Lista los workflows y ajustes de instancia afectados por la 3.0.
• Corrige muchos problemas automáticamente, y cada arreglo se guarda como una nueva versión del workflow para que la revises y publiques, mientras lo publicado sigue corriendo en v2.
• Sugiere un responsable por workflow (quien lo editó por última vez), permite reasignarlo y envía correos a los dueños con lo que hay que arreglar.
• Filtra los workflows que no están publicados o llevan mucho tiempo sin ejecutarse, para que los marques como "no se va a arreglar".
• Exporta un resumen en CSV.

Los administradores ven todos los workflows; el resto de usuarios ve los que tiene permiso de ver. A diferencia del año pasado, no hace falta ser admin para consultarlo.

¿Qué significa esto para tu startup?

Si n8n sostiene procesos críticos —facturación, sincronización de CRM, onboarding de clientes, pipelines de datos— la 3.0 no es una actualización de fin de semana. Es un proyecto con dueño y fecha.

Acción 1: actualiza primero a la última 2.x y abre el Migration Report. La versión más reciente de la 2.x trae la versión más nueva del reporte, y el equipo seguirá mejorándolo con el feedback. Antes de tocar nada, actualiza dentro de la 2.x y revisa qué te va a explotar.

Acción 2: resuelve o descarta cada bandera antes de la estable. Arregla lo que el reporte marque o márcalo como "no se va a arreglar". Los workflows viejos que nadie usa no merecen tu tiempo; los que facturan, sí.

Acción 3: backup completo y staging antes que producción. La ruta recomendada por n8n es explícita: actualizar a la última 2.x, abrir el reporte, arreglar o descartar, tomar un backup completo y subir primero una instancia de test o staging. Y un aviso que conviene subrayar: pasar a 3.x es un camino de ida. No hay rollback; volver atrás significa restaurar el backup.

Acción 4: si sigues en 1.x, no saltes. No existe ruta directa de 1.x a 3.x: hay que pasar primero por 2.x. El soporte de la 1.x termina el 31 de diciembre de 2026, así que el margen se agota.

¿Qué pasa con la 2.x y con tus datos?

Después de la estable, la 2.x recibirá parches de seguridad y correcciones de bugs críticos durante 12 meses. Las funciones nuevas saldrán solo en 3.x. Las credenciales y el historial de ejecuciones se conservan al migrar, y el tiempo de inactividad es un reinicio corto, como cualquier actualización.

La 3.0 aplica por igual a Community self-hosted, Cloud y Enterprise/Business: nadie queda fuera del cambio de defaults.

Un año que explica por qué esta release existe

n8n cerró la 2.0 con unos 160.000 stars en GitHub; hoy supera las 208.000. El foro de comunidad pasó de 115.192 a más de 183.000 miembros. Ese volumen es la razón por la que una release sin features nuevas importa: cuando tienes esa base instalada, cada default que cambias tiene consecuencias en miles de instancias.

Para un founder, la lectura es simple. La herramienta que usas para automatizar se está volviendo más estricta en seguridad y más predecible bajo carga, y eso es bueno a mediano plazo. Pero el costo se paga ahora, en horas de revisión y migración. Presupuesta ese tiempo antes de diciembre, no después.

Fuentes

• Introducing n8n 3.0 (fuente original)