n8n 3.0 elimina las instalaciones vía npm y rompe nodos de flujo de trabajo heredados

La plataforma de automatización n8n se prepara para el lanzamiento de su versión mayor 3.0, que introduce cambios disruptivos significativos para las instancias autoalojadas. Lanzada como beta el 27 de octubre de 2026, con un lanzamiento estable previsto para principios de diciembre, esta actualización altera fundamentalmente cómo se despliega el software y cómo funcionan los flujos de trabajo existentes. Los equipos que ejecutan sus propios servidores n8n deben prepararse para cambios obligatorios en la infraestructura y refactorización de código antes de que cierre la ventana de actualización.

Qué ha ocurrido

El cambio operativo más inmediato es la eliminación de los métodos de instalación basados en npm. La versión 3.0 no publicará un paquete n8n ejecutable en npm, lo que significa que comandos como npm install n8n o npx n8n ya no están soportados. Los usuarios autoalojados deben migrar a contenedores Docker para ejecutar el software. Este cambio también incluye modificaciones en las rutas de almacenamiento de archivos; el directorio heredado ~/.n8n/binaryData es reemplazado por ~/.n8n/storage. La aplicación se negará a iniciarse si ambos directorios existen, lo que requiere una limpieza manual durante la transición. Además, la rotación de claves de cifrado ahora está habilitada por defecto, y el nodo Compression tiene límites más estrictos, restringiendo las operaciones a 256 MiB o 1,000 entradas.

Más allá de la infraestructura, la actualización elimina varios nodos y funciones centrales que habían sido deprecados en versiones anteriores. Los disparadores Cron e Interval han desaparecido, siendo reemplazados completamente por el Schedule Trigger. Nodos heredados como Function, Function Item e Item Lists han sido eliminados, causando fallos en las ejecuciones si aún están presentes en flujos de trabajo antiguos. La herramienta de migración puede convertir algunos de estos a nodos Code, pero es necesaria una revisión manual. Asimismo, el método de expresión $getPairedItem ha sido eliminado de los nodos Code, requiriendo que los desarrolladores actualicen sus scripts para usar alternativas como .itemMatching() o .pairedItem().

Las configuraciones de seguridad e integración también se han endurecido. Los disparadores de Slack ahora requieren un Signature Secret en las credenciales, lo que detendrá los flujos existentes de aprobación y alertas si no se actualizan. La plataforma ha ampliado su lista de bloqueo de Server-Side Request Forgery (SSRF) para incluir el rango 100.64.0.0/10 por defecto, lo que potencialmente bloquea conexiones a ciertos servicios internos privados a menos que se permitan explícitamente mediante variables de entorno. Los paquetes comunitarios no verificados están deshabilitados por defecto, lo que significa que los nodos personalizados de terceros no se cargarán a menos que el usuario acepte explícitamente el riesgo estableciendo una bandera de entorno.

Detalles clave

• Cambio en el despliegue: Las instalaciones via npm y npx no están soportadas; los usuarios deben migrar a Docker.
• Eliminación de nodos: Los nodos Cron, Interval, Function, Function Item e Item Lists son eliminados.
• Cambios en el código: $getPairedItem es eliminado; el tiempo de espera predeterminado para tareas en Code baja de 300s a 60s.
• Integración con Slack: Los disparadores ahora exigen un Signature Secret en la configuración de credenciales.
• Ruta de almacenamiento: ~/.n8n/binaryData pasa a llamarse ~/.n8n/storage; la ruta antigua debe ser eliminada.
• Línea temporal de soporte: El soporte para la versión 1.x termina el 31 de diciembre de 2026; las correcciones de seguridad para 2.x terminan 12 meses después del lanzamiento estable de 3.x.

Contexto

n8n es una herramienta de automatización de flujos de trabajo que permite a los usuarios conectar diferentes aplicaciones y servicios a través de una interfaz visual. Para muchas empresas, especialmente aquellas que manejan datos sensibles, el autoalojamiento de n8n proporciona control sobre dónde residen los datos y cómo se procesan. Sin embargo, mantener software autoalojado requiere estar al día con los cambios upstream. Los cambios disruptivos en versiones mayores a menudo implican la eliminación de características deprecadas para reducir la deuda técnica y mejorar la seguridad. En este contexto, eliminar el soporte para npm simplifica la carga de mantenimiento para los desarrolladores al enfocarse en un único modelo de despliegue contenedorizado. De manera similar, la eliminación de nodos heredados fuerza a los usuarios a adoptar prácticas de codificación más modernas, eficientes y seguras dentro de sus flujos de trabajo.

Por qué importa

Para los equipos que gestionan su propia infraestructura de automatización, esta actualización no es opcional si desean permanecer soportados. La eliminación del soporte para npm significa que cualquier pipeline CI/CD existente o configuración de servidor que dependa de la instalación directa de node fallará al actualizar. Esto requiere una re-arquitectura fundamental de los scripts de despliegue. Además, la reducción del tiempo de espera duro para los nodos Code de 300 segundos a 60 segundos puede causar fallos inesperados en transformaciones de datos de larga duración. Los equipos que procesan grandes conjuntos de datos o realizan cálculos complejos en nodos de código JavaScript deben optimizar sus scripts o configurar la variable de entorno N8N_RUNNERS_TASK_TIMEOUT para evitar caídas en producción.

El impacto en los flujos de trabajo críticos para el negocio es significativo. Los flujos que gestionan pedidos, facturas o movimientos de inventario a menudo dependen de nodos heredados o disparadores de temporización específicos. Si estos no se identifican y migran antes de la actualización, las operaciones comerciales podrían detenerse. El requisito de verificar manualmente los flujos de trabajo migrados automáticamente añade una capa de trabajo de aseguramiento de calidad que no puede omitirse. Adicionalmente, las protecciones SSRF más estrictas pueden bloquear silenciosamente llamadas a API internas que previamente estaban permitidas, requiriendo que los equipos de red revisen y actualicen las listas blancas para rangos de IP privadas.

Qué puedes hacer

• Verifica tu versión actual: Si estás en la versión 1.x, actualiza primero a 2.x, ya que no hay una ruta directa a 3.x.
• Ejecuta el Informe de Migración: Usa la herramienta integrada en Settings (disponible en n8n 2.39+) para identificar problemas de flujos de trabajo e instancias.
• Prioriza los flujos críticos: Corrige primero los flujos de trabajo involucrados en transacciones financieras o de inventario, y revisa cuidadosamente el código migrado automáticamente.
• Audita los nodos Code: Busca métodos deprecados como $getPairedItem e identifica tareas que superen los 60 segundos.
• Prueba en staging: Haz una copia de seguridad de tu instancia de producción, restaura en un entorno de staging, actualiza y reproduce entradas reales para verificar los conteos de registros.
• Programa tiempos de inactividad: Realiza la actualización final durante un período tranquilo y confirma que todos los flujos de trabajo programados se activen correctamente después.