Actualizar n8n sin pérdida de datos: fijación de versión, copia de seguridad, rollback

n8n puede actualizarse sin pérdida de datos si crea una copia de seguridad completa de la base de datos y de la clave de cifrado antes de cada actualización, fija deliberadamente la versión de destino en lugar de actualizar automáticamente a "latest", y prueba primero la nueva versión en un entorno de pruebas. La documentación oficial de n8n recomienda actualizar regularmente, al menos una vez al mes, y no saltarse varias versiones principales, porque de lo contrario aumenta el riesgo de una actualización disruptiva. Los workflows que parecen haber desaparecido tras una actualización casi nunca son, en la práctica, una pérdida de datos real, sino un error de configuración en los volúmenes de Docker o en los permisos de usuario. Fecha: julio de 2026.

¿Por qué no debería simplemente actualizar n8n a la última versión disponible?

Una actualización descontrolada a la última versión es la causa más frecuente de sorpresas desagradables. El propio n8n recomienda, en la documentación oficial de actualización, actualizar regularmente para no tener que saltarse varias versiones a la vez, revisar las notas de la versión en busca de cambios incompatibles (breaking changes) antes de cada actualización, y ejecutar primero la nueva versión en un entorno de pruebas separado antes de que pase a producción. Quien en cambio no instala actualizaciones durante meses y luego salta varias versiones principales de una vez aumenta el riesgo de que nodos obsoletos, estructuras de datos modificadas o funciones eliminadas actúen simultáneamente. Encontrará los detalles del procedimiento recomendado en la documentación de actualización de n8n.

¿Cómo se fija la versión de n8n en Docker y npm?

La fijación de versión significa usar un número de versión concreto en lugar de una etiqueta móvil como "latest", para que un reinicio o redeploy no descargue involuntariamente una versión más nueva. En Docker, se descarga una etiqueta de imagen fija, por ejemplo con docker pull docker.n8n.io/n8nio/n8n seguido del número de versión deseado como etiqueta, y se introduce el mismo número en su archivo compose, tal como describe la guía de instalación de Docker. En una instalación con npm, se instala una versión concreta con npm install -g n8n seguido del número de versión, según la guía de instalación de npm. Según la documentación, no debería usar explícitamente la etiqueta next para versiones beta en producción. Solo cuando la nueva versión fijada funcione correctamente en el entorno de pruebas debería actualizar la instancia de producción al mismo número.

¿Qué debe respaldar antes de la actualización?

Antes de cada actualización, dos cosas deben incluirse en la copia de seguridad: la base de datos con todos los workflows y ejecuciones, así como la clave de cifrado. n8n cifra las credenciales guardadas con una clave que se almacena automáticamente en el directorio .n8n al primer inicio, o se establece mediante la variable de entorno N8N_ENCRYPTION_KEY, como se describe en la documentación sobre la clave de cifrado. Si esta clave se pierde, por ejemplo porque un contenedor Docker se reconstruye sin un volumen persistente, las credenciales guardadas ya no pueden descifrarse, incluso si la base de datos en sí está intacta. En modo cola, según la documentación, cada worker también debe recibir la misma clave de cifrado, de lo contrario los procesos principal y worker cifran y descifran con claves diferentes. Quien además utilice la rotación de la clave de cifrado debería, según la documentación sobre la rotación de claves, crear previamente una copia de seguridad completa de la base de datos, porque la activación es, según n8n, un paso de un solo sentido sin posibilidad de rollback.

¿Qué hacer si faltan workflows después de una actualización?

Los workflows que faltan después de una actualización por lo general no son una pérdida de datos real, sino un problema de acceso. En los foros de la comunidad de n8n, los usuarios informan repetidamente de workflows aparentemente desaparecidos tras una actualización, y la causa suele resultar ser un volumen de Docker montado incorrectamente o permisos de usuario incorrectos en el contenedor: la base de datos sigue existiendo, pero el proceso de n8n simplemente ya no puede encontrarla o leerla tras el reinicio. Por eso, compruebe primero si su directorio de datos está correctamente montado como volumen y si el contenedor se ejecuta con el mismo usuario que antes de la actualización. Con una copia de seguridad de la base de datos actualizada, en caso de emergencia se puede restaurar el estado anterior a la actualización, lo que constituye de hecho su rollback, ya que n8n no ofrece un rollback integrado de un clic a una versión anterior. Quien no quiera asegurar este proceso por sí mismo puede externalizarlo como parte de una consultoría y soporte de n8n a NordFlux.

Preguntas frecuentes sobre actualizaciones de n8n

¿Con qué frecuencia debo actualizar n8n?

n8n recomienda, en la documentación oficial, actualizar al menos una vez al mes. Esto evita que se acumulen varias versiones principales y que una sola actualización traiga consigo varios cambios incompatibles a la vez. Las actualizaciones más pequeñas y frecuentes son más fáciles de probar y más fáciles de acotar en caso de error.

¿Basta con una copia de seguridad de la base de datos para protegerse contra la pérdida de datos?

No, sin la clave de cifrado correspondiente, una copia de seguridad de la base de datos carece de valor para las credenciales guardadas. n8n cifra las credenciales con esta clave, y sin ella los valores cifrados de la base de datos ya no pueden hacerse legibles. Por eso, respalde siempre juntos la base de datos y la clave de cifrado.

¿Existe un mecanismo de rollback oficial en n8n?

No, n8n no ofrece un rollback integrado de un clic a una versión anterior. La vía práctica de rollback consiste en reinstalar la imagen antigua fijada o la versión antigua de npm, y restaurar la base de datos previamente respaldada junto con la clave de cifrado.

¿Cuál es la diferencia entre la clave de cifrado y la rotación de la clave de cifrado?

La clave de cifrado, establecida mediante N8N_ENCRYPTION_KEY, es la única clave maestra fija con la que n8n cifra las credenciales. La rotación de la clave de cifrado es una función separada y opcional para instancias que desean intercambiar periódicamente la clave de datos interna, para la cual, según la documentación, es obligatoria previamente una copia de seguridad completa, porque la activación no se puede deshacer.