# n8n 3.0 Beta, limpia el software viejo y aprieta la seguridad > n8n 3.0 entra en beta con cambios que rompen: fuera nodos antiguos, solo Docker, tiempos de espera más cortos y rotación de claves activada por defecto. > Por José Maldonado · Tecnología · 2026-10-30 n8n ha publicado la beta de su versión 3.0, y la compañía lo dice sin rodeos: no hay funciones nuevas que celebrar, hay una limpieza profunda que rompe cosas. Los nodos heredados desaparecen, el modo de datos binarios en memoria se elimina, el tiempo máximo del nodo Code baja de cinco minutos a uno y la instalación con npm o npx deja de tener soporte. La [versión estable](https://blog.n8n.io/introducing-n8n-v3/) llegará a principios de diciembre y quien administre una instancia tiene hasta entonces para revisar qué se le rompe. El motivo del salto de número es el versionado semántico. Durante el último año n8n ha ido acumulando cambios incompatibles que no podía publicar sin subir de major, y ahora los junta todos en una entrega. Desde la 2.0 de diciembre de 2025 han salido más de 45 versiones, aproximadamente una por semana, con las funciones nuevas dentro. Es decir: el producto ha seguido avanzando y este 3.0 se ocupa de los cimientos. Ese planteamiento tiene una lectura práctica que conviene entender antes de actualizar. Una herramienta de automatización no es un editor de texto: sus flujos conectan sistemas, mueven datos y a veces tocan producción. Un cambio de comportamiento en un nodo no se queda en casa, se propaga a todo lo que dependa de esa automatización. La propia compañía ha puesto a disposición de los clientes un informe que hace el trabajo de auditoría, y esa es la parte que cualquier responsable técnico debería leer antes que la lista de novedades. ## ¿Qué se rompe y por qué? El primer bloque es de fiabilidad. Las ejecuciones manuales pasan a correr siempre en los workers, de modo que la instancia principal deja de hacer ese trabajo. Los datos binarios en memoria desaparecen y se pasa siempre al sistema de archivos o a un almacenamiento externo tipo S3, que bajo carga se comporta de forma más predecible. El segundo bloque son los límites. El nodo Code tenía un tiempo máximo de cinco minutos que ahora baja a uno y se puede configurar. Los límites de descompresión también bajan, con una explicación que no oculta el problema: proteger la instancia de archivos comprimidos maliciosos, las conocidas bombas zip. El tercer bloque es el calendario. Los nodos Cron e Interval se sustituyen por el Schedule Trigger, que se apoya en el planificador más robusto de la plataforma. Quien tuviera flujos con los antiguos tendrá que migrarlos o aceptar que dejen de funcionar. Cambio Antes En 3.0 Ejecuciones manuales En la instancia principal Siempre en workers Datos binarios Opción en memoria Solo archivos o S3 Tiempo del nodo Code 5 minutos 1 minuto, configurable Programación Nodos Cron e Interval Schedule Trigger Instalación npm, npx o Docker Solo Docker Paquetes de la comunidad Disponibles Desactivados si no están verificados ## La seguridad deja de ser opcional El bloque más relevante para quien administra instancias ajenas es el de los valores por defecto. La rotación de la clave de cifrado pasa a estar siempre activa. Las credenciales de Slack exigen un secreto de firma, de modo que nadie pueda enviar peticiones falsas haciéndose pasar por el servicio. La lista de bloqueo de SSRF crece cuando la protección está activada, y los paquetes de la comunidad sin verificar quedan desactivados de serie. Ese último punto va a generar conversaciones en equipos que dependían de integraciones no oficiales. La decisión es correcta desde el punto de vista del riesgo y molesta desde el punto de vista operativo, que es el equilibrio habitual en seguridad. La retirada del soporte a npm y npx tiene la misma lógica. Los responsables del proyecto explican que algunas funciones nuevas dependen de un entorno de contenedor, y quien apreciaba la instalación rápida con una línea tiene un script que reproduce el resultado. Kubernetes y Helm no se ven afectados. ## El informe que hay que mirar primero Cualquier instancia en la versión 2.39 o posterior tiene un Migration Report en el menú de ajustes. El informe lista los flujos y configuraciones afectados, corrige automáticamente muchos de los problemas guardando cada cambio como una nueva versión del flujo, sugiere un responsable para cada caso, avisa por correo a esa persona y permite exportar un resumen en CSV. Hay dos detalles que lo hacen útil de verdad. El primero es que los flujos publicados siguen funcionando en la versión 2 mientras se revisa la migración, así que no hay que apagar nada para empezar. El segundo es que filtra los flujos que no están publicados o no se ejecutan desde hace tiempo, con lo que se pueden marcar como descartados y centrarse en lo que importa. El consejo de la compañía es actualizar primero a la última 2.x para tener la versión más reciente del informe. Es un paso de una hora que ahorra un fin de semana. ## La retirada de nodos, con matices La lista de nodos eliminados es larga: Function, Function Item, Item Lists, Cron, Interval, el nodo antiguo de OpenAI, modos anteriores de agentes de IA, versiones viejas de edición de imagen y nodos de servicios que ya no existen. La mayoría tiene sustituto directo y muchos migran solos. Function pasa a ser el nodo Code, Item Lists se reparte entre Split Out, Aggregate, Sort, Limit, Remove Duplicates y Summarize, y esa fragmentación es una buena noticia a medio plazo: un nodo que hacía cinco cosas distintas se convierte en piezas que se pueden probar por separado. También hay funciones retiradas que no tienen equivalente exacto. Chat Hub queda desactivado por defecto, la importación desde URL desaparece del editor y la pestaña de consulta a la IA se va del nodo Code. Quien dependiera de ellas tendrá que buscar alternativa fuera de la plataforma. Este tipo de limpieza se parece a la que ha hecho la comunidad de Python al retirar su compilador experimental: quitar peso para poder avanzar, como contamos al analizar [la retirada del JIT de CPython](https://observatorioblockchain.com/tecnologia/python-retira-jit-cpython-pep-836/). En ambos casos el mensaje es el mismo: mantener código viejo tiene un coste que alguien acaba pagando.