n8n prepara uno de los cambios más importantes desde el lanzamiento de la rama 2.x. La futura versión 3.0, prevista para octubre de 2026, introduce modificaciones que afectarán directamente a administradores de sistemas, equipos DevOps y desarrolladores que mantienen instalaciones autoalojadas. La principal novedad es que Docker pasará a ser el único método soportado para desplegar n8n, mientras que varias funciones heredadas desaparecerán definitivamente.
Las claves de n8n 3.0 en 20 segundos
- Las instalaciones mediante
npmonpx n8ndejarán de estar soportadas. - Docker y Docker Compose serán el modelo recomendado para todos los despliegues autoalojados.
- Se eliminan los nodos Function, Function Item e Item Lists en favor del nodo Code.
- La versión incorpora medidas de seguridad más estrictas y retira varias funciones heredadas.
La compañía ha querido anunciar estos cambios con varios meses de antelación para que los administradores puedan auditar sus despliegues y adaptar los workflows antes de la publicación oficial.
Docker deja de ser una recomendación para convertirse en un requisito
Uno de los cambios más relevantes afecta directamente a la forma de instalar n8n.
Hasta ahora era habitual encontrar pequeños despliegues ejecutándose mediante:
npm install n8n -g
n8no simplemente:
npx n8nEse modelo desaparecerá con la llegada de la versión 3.
A partir de entonces, las instalaciones autoalojadas únicamente estarán soportadas mediante Docker, siendo Docker Compose la opción recomendada para la mayoría de despliegues individuales y de laboratorio.
Aunque técnicamente seguiría siendo posible ejecutar n8n de otras maneras, la documentación oficial y el soporte del proyecto se centrarán exclusivamente en contenedores.
Para los administradores esto supone varias ventajas:
- despliegues reproducibles;
- actualizaciones más sencillas;
- aislamiento de dependencias;
- menor riesgo de incompatibilidades entre versiones de Node.js;
- integración más sencilla con Kubernetes, Portainer o Docker Swarm.
También simplifica el trabajo del propio equipo de desarrollo, que ya no tendrá que mantener distintos métodos de instalación.
Revisión obligatoria de workflows antes de actualizar
El segundo gran cambio afecta a la compatibilidad.
n8n aprovechará la nueva versión mayor para eliminar componentes que llevaban tiempo marcados como obsoletos.
Desaparecen:
- Function
- Function Item
- Item Lists
Los dos primeros deberán sustituirse por el nodo Code, utilizando los modos:
- Run Once for All Items
- Run Once for Each Item
En el caso de Item Lists, la funcionalidad queda repartida entre varios nodos especializados como:
- Aggregate
- Split Out
- Remove Duplicates
- Sort
- Limit
- Summarize
Para instalaciones con decenas o cientos de workflows conviene comenzar cuanto antes una auditoría, ya que cualquier flujo que utilice estos componentes dejará de funcionar tras la actualización.
Cambios también en Execute Workflow y las expresiones
No solo desaparecen nodos.
n8n también elimina comportamientos heredados del nodo Execute Workflow, aunque todavía no ha publicado todos los detalles técnicos de la migración.
Asimismo desaparece definitivamente el helper:
$getPairedItem()Lenguaje del código: PHP (php)La plataforma recomienda utilizar el sistema moderno de item linking, mediante:
pairedItemo expresiones como:
$("NombreNodo").itemLenguaje del código: JavaScript (javascript)Los usuarios que ya trabajan con versiones recientes probablemente apenas notarán diferencias, ya que estas alternativas llevan tiempo disponibles.
Seguridad más estricta por defecto
Otra parte importante de la actualización está relacionada con la seguridad.
n8n endurece varias configuraciones predeterminadas para reducir riesgos en entornos de producción.
Entre las novedades anunciadas destacan:
- restricciones adicionales sobre nombres de recursos potencialmente peligrosos;
- gestión más segura de credenciales;
- activación automática de la rotación de claves (key rotation).
Aunque la compañía todavía no ha detallado todos los cambios internos, el objetivo es reducir configuraciones inseguras heredadas sin depender de ajustes manuales posteriores.
Para equipos DevSecOps esto supone una mejora interesante, especialmente en despliegues compartidos entre varios usuarios.
También desaparecen varias funciones del producto
La limpieza de código no afecta únicamente a los workflows.
n8n retirará algunas funcionalidades poco utilizadas para reducir la complejidad de mantenimiento.
Entre ellas:
- Chat Hub.
- Importación de workflows mediante URL desde el editor.
- Non-functional nodes.
Seguirán disponibles otras formas de importar flujos:
- copiar y pegar;
- importar desde archivo;
- CLI;
- API pública.
Un paso más hacia la automatización basada en IA
Aunque muchos de los cambios parecen centrarse únicamente en eliminar componentes antiguos, la estrategia tiene un objetivo claro.
n8n quiere simplificar su base tecnológica para seguir evolucionando hacia una plataforma orientada a la automatización inteligente y la orquestación de agentes de IA.
Durante los últimos dos años la plataforma ha incorporado soporte para modelos de lenguaje, agentes, RAG, herramientas MCP y múltiples integraciones con proveedores de IA. Mantener compatibilidad con APIs y nodos heredados dificultaba esa evolución.
Reducir deuda técnica también permitirá acelerar el desarrollo de nuevas funcionalidades sin arrastrar comportamientos de hace varias versiones.
Qué deberían hacer los administradores antes de octubre
Aunque n8n 3 todavía no está disponible, la recomendación es empezar a revisar la infraestructura.
Los principales puntos de comprobación serían:
| Revisar | Acción recomendada |
|---|---|
| Instalación mediante npm o npx | Planificar migración a Docker Compose |
| Uso de Function o Function Item | Sustituir por Code |
| Uso de Item Lists | Reemplazar por los nuevos nodos específicos |
Uso de $getPairedItem() | Migrar al nuevo sistema de item linking |
| Uso de Chat Hub | Buscar alternativa antes de actualizar |
Las organizaciones que todavía permanecen en n8n 1.x también deberían comenzar cuanto antes la actualización, ya que esa rama dejará de recibir soporte al finalizar este año.
Por su parte, n8n 2.x seguirá recibiendo soporte durante 12 meses después de la publicación de la versión 3, aunque todas las nuevas funcionalidades llegarán únicamente a la nueva rama.
Para muchos administradores de sistemas este lanzamiento supone algo más que una actualización: marca la transición definitiva de n8n hacia una plataforma claramente orientada a producción, con despliegues estandarizados mediante contenedores y una base tecnológica mucho más limpia para afrontar la siguiente generación de automatización empresarial e inteligencia artificial.
Preguntas frecuentes
¿Será obligatorio usar Docker en n8n 3?
Sí. Las instalaciones autoalojadas mediante npm o npx dejarán de estar soportadas oficialmente.
¿Qué workflows dejarán de funcionar?
Aquellos que utilicen los nodos Function, Function Item, Item Lists o el helper $getPairedItem deberán migrarse antes de actualizar.
¿Docker Compose seguirá siendo válido?
Sí. La documentación oficial indica que será el método recomendado para la mayoría de instalaciones locales y autoalojadas.
¿Cuánto tiempo seguirá soportada la versión 2?
n8n ha confirmado soporte durante 12 meses tras el lanzamiento oficial de la versión 3.
