Versión actual de n8n: ¿cuándo y cómo debería actualizar un equipo autoalojado?
Guía práctica para mantener actualizada una versión de n8n autoalojada: cuándo aplicar actualizaciones menores, cómo planificar una versión mayor y qué revisar antes.
Comprobado con las fuentes citadas el .
Por qué mantener una versión actual de n8n es importante
Decidir con qué frecuencia actualizar una versión actual de n8n autoalojada son en realidad dos preguntas distintas: con qué frecuencia aplicar actualizaciones pequeñas y cómo planificar el salto ocasional a una versión mayor. La propia documentación de hosting de n8n recomienda actualizar con frecuencia, señalando que esto evita tener que saltar varias versiones de una sola vez y reduce el riesgo de una actualización disruptiva.
Para los responsables de operaciones e IT que gestionan su propia instancia, lo que está en juego difiere de n8n Cloud: en una instalación autoalojada, el equipo decide cuándo ocurre una actualización y es quien se entera después si algún flujo de trabajo se ha roto. Acertar con el momento y el proceso es una decisión del equipo, no una tarea en segundo plano.
Sources: Update n8n | Deploy | n8n Docs
Actualizaciones menores frente a versiones mayores de n8n: dos decisiones distintas
La mayor parte de lo que recibe cada semana una versión actual de n8n autoalojada es una versión menor. El registro de cambios de n8n indica que publica una nueva versión menor la mayoría de las semanas, por lo que un equipo que quiera mantenerse al día se enfrenta a una alta frecuencia de actualización si intenta seguir el ritmo de cada versión. n8n también distingue un canal de versiones beta, descrito como potencialmente inestable, del canal estable recomendado para uso en producción. En nuestra opinión, perseguir cada versión menor en el momento en que se publica es excesivo para la mayoría de los equipos; un ritmo mensual constante captura las correcciones de seguridad sin convertir las actualizaciones en un trabajo a tiempo parcial.
Una versión mayor es un tipo de decisión distinto. El anuncio de n8n sobre su versión 2.0 indica que la empresa planea publicar de una a dos versiones mayores al año en adelante, por lo que los equipos autoalojados deberían esperar una revisión de cambios incompatibles con más frecuencia que en la historia anterior del producto. El mismo anuncio indica que la versión mayor anterior, 1.x, siguió recibiendo correcciones de seguridad y errores durante tres meses después del lanzamiento de 2.0, y que todos los cambios de 2.0 se aplicaron a todas las ediciones, incluidas las instalaciones Community autoalojadas.
| Dimensión | Actualización menor | Salto de versión mayor |
|---|---|---|
| Frecuencia | Una nueva versión menor la mayoría de las semanas, según el registro de cambios de n8n | De una a dos versiones mayores al año, según el plan declarado por la propia n8n |
| Riesgo típico | Bajo cuando se aplica con un ritmo rutinario | Cambios incompatibles en toda la instancia, que afectan a todas las ediciones |
| Proceso necesario | Revisar notas de versión, aplicar según un calendario | Copia de seguridad, prueba en staging, revisión de cambios incompatibles, posibles cambios de scripts |
| Ventana de soporte | No aplicable | Documentada solo para la transición de 1.x a 2.0: la versión anterior siguió recibiendo correcciones de seguridad y errores durante 3 meses tras el lanzamiento de 2.0; n8n no ha indicado si la misma ventana se aplicará a futuros saltos de versión mayor |
Sources: Update n8n | Deploy | n8n Docs, Changelog | n8n Docs, Introducing n8n 2.0 – n8n Blog
Un ritmo práctico y pasos seguros para actualizar
Establece un ritmo rutinario para las actualizaciones menores y trata los saltos de versión mayor como un proyecto independiente y planificado. Creemos que tratar un salto de versión mayor de n8n como mantenimiento rutinario es un error que conviene evitar; merece su propio plan de proyecto, no un hueco en la rotación habitual de actualizaciones.
Antes de cualquier actualización, la propia documentación de actualización de n8n indica a los operadores que revisen las notas de la versión en busca de cambios incompatibles. Para una versión mayor, esa revisión debería extenderse a una guía dedicada de cambios incompatibles, una prueba previa en una instancia de staging o Environments, y una copia de seguridad completa, que es exactamente lo que indicaba la guía de migración a 1.0 de n8n antes de esa actualización concreta. La misma guía recomendaba pasar primero a la última versión 0.x antes de saltar a 1.x, de modo que cualquier problema pudiera aislarse en la versión correcta en lugar de mezclarse con otros cambios.
Sources: Update n8n | Deploy | n8n Docs, Changelog | n8n Docs, v1.0 Migration guide | Changelog | n8n Docs
Qué cambia en un límite de versión mayor: lecciones de la 1.0 y la 2.0
En un límite de versión mayor, la nomenclatura y los valores predeterminados pueden cambiar. La documentación de cambios incompatibles de n8n 2.0 muestra que los propios canales de versiones se renombraron, de latest y next a stable y beta, y recomienda fijar un despliegue a un número de versión explícito, como 2.0.0, en lugar de seguir una etiqueta móvil. Somos optimistas respecto a que fijar un número de versión explícito es una de las mejoras de fiabilidad más baratas que puede hacer un equipo autoalojado, ya que convierte las actualizaciones en una decisión en lugar de una sorpresa.
La automatización que llama a la CLI de n8n necesita su propia revisión. La documentación de la CLI de n8n indica que el comando update:workflow queda obsoleto a partir de n8n 2.0 y será eliminado, nombrando publish:workflow y unpublish:workflow como los comandos de sustitución para gestionar el estado de los flujos de trabajo. Cualquier script que un equipo haya escrito para activar o desactivar flujos de trabajo desde la línea de comandos debería migrar a los nuevos comandos antes de que el antiguo desaparezca.
El método de instalación también importa. El registro de cambios de n8n vincula la eliminación de las instalaciones vía npm a n8n 3.0, en torno a una ventana de lanzamiento de octubre, por lo que un equipo autoalojado que todavía ejecute n8n mediante npm necesita tener lista una configuración basada en Docker antes de que llegue esa versión.
Sources: Use the command line | Deploy | n8n Docs, Changelog | n8n Docs, v2.0 Breaking changes | Changelog | n8n Docs
Lista de verificación: ¿es momento de actualizar?
Una breve rutina previa a la actualización responde a la mayor parte de la pregunta sobre cuándo toca cambiar una versión actual de n8n. La siguiente lista convierte los puntos tratados arriba en algo que un equipo puede repasar antes de tocar una instancia de producción.
Sources: Update n8n | Deploy | n8n Docs, Use the command line | Deploy | n8n Docs, Changelog | n8n Docs, v2.0 Breaking changes | Changelog | n8n Docs, v1.0 Migration guide | Changelog | n8n Docs
