Cambio de servidor sin tiempo de inactividad

Un cambio de servidor para n8n autoalojado se logra sin tiempo de inactividad perceptible si sigue el principio blue-green: el nuevo servidor se construye completamente en paralelo al antiguo y se prueba con los datos migrados antes de que el cambio de DNS redirija el tráfico. Es fundamental que los workflows, las credenciales y la base de datos de n8n se transfieran por completo y con la misma clave de cifrado al nuevo servidor, ya que n8n utiliza la N8N_ENCRYPTION_KEY para descifrar las credenciales almacenadas. Quien olvide esta clave durante la mudanza pierde el acceso a todas las credenciales guardadas, incluso si los workflows en sí pudieron importarse. Estado: julio de 2026.

Preparar el nuevo servidor

Antes de migrar cualquier cosa, el nuevo servidor (por ejemplo, una instancia nueva de Hetzner Cloud) debe estar configurado y operativo, incluyendo Docker o Docker Compose, proxy inverso y reglas de firewall para los puertos 80 y 443. Para configuraciones de Hetzner, la documentación de n8n sobre el alojamiento en Hetzner describe la configuración con Docker Compose y Caddy como proxy inverso, incluidos volúmenes persistentes para los datos de n8n.

• Entorno Docker: n8n y el proxy inverso se ejecutan como contenedores con sus propios volúmenes, para que los datos sobrevivan a los reinicios.
• Subdominio de prueba: Cree primero una segunda entrada DNS (por ejemplo, n8n-nuevo.sudominio.com), para poder probar el nuevo servidor antes de cambiar el dominio principal.
• Misma versión de n8n: Compruebe que la versión de n8n en el nuevo servidor coincide con la del servidor antiguo, o que se actualiza deliberadamente, para evitar errores de importación.

Migrar workflows, credenciales y base de datos

n8n ofrece comandos dedicados para la exportación y la importación a través de los comandos CLI para exportación e importación que tratan los workflows y las credenciales por separado. Se puede crear una copia de seguridad completa con las opciones --backup y --output, y restaurarla en la importación con --input y --separate.

• Exportar workflows: n8n export:workflow --backup --output=backups/latest/ guarda todos los workflows formateados y como archivos individuales.
• Exportar credenciales: n8n export:credentials --backup --output=backups/latest/ guarda las credenciales aún cifradas; la opción --decrypted las muestra en texto claro y solo debe usarse para migraciones controladas.
• Importar en el nuevo servidor: n8n import:workflow --separate --input=backups/latest/ y n8n import:credentials --separate --input=backups/latest/ restauran los archivos.
• Aplicar la clave de cifrado: Configure N8N_ENCRYPTION_KEY en el nuevo servidor exactamente con el valor del servidor antiguo, de lo contrario las credenciales importadas no se podrán descifrar.
• Tener en cuenta la carpeta de base de datos: La carpeta detrás de N8N_USER_FOLDER contiene, además de la base de datos SQLite, otros datos de configuración locales y también debe incluirse en la copia de seguridad, a menos que de todos modos migre a una base de datos PostgreSQL externa.

Según la documentación de n8n, estos comandos también exportan los ID internos de los workflows y las credenciales. Si ya existen registros con los mismos ID en el servidor de destino, se sobrescriben durante la importación, un punto importante si el nuevo servidor no se configura completamente vacío. Los workflows importados también están desactivados de forma predeterminada y deben reactivarse deliberadamente tras la comprobación.

Después de la importación: pruebe manualmente los workflows críticos a través del subdominio de prueba, compruebe los triggers, los webhooks y las conexiones a servicios externos, y compare de forma aleatoria el número de workflows y credenciales entre el servidor antiguo y el nuevo.

Cambiar el DNS: blue-green sin tiempo de inactividad

Solo cuando el nuevo servidor funciona de forma fiable bajo el subdominio de prueba se cambia el dominio real. Reduzca previamente el TTL de la entrada DNS afectada a un valor bajo (por ejemplo, 300 segundos), para que el cambio surta efecto rápidamente. Luego cambie el registro A del dominio principal a la dirección IP del nuevo servidor. Durante el período de transición, la instancia antigua y la nueva funcionan en paralelo, de modo que las solicitudes entrantes pueden distribuirse brevemente entre ambos servidores según el estado de la caché DNS. En el caso de workflows controlados por webhooks, esto puede provocar que algunas llamadas lleguen al servidor antiguo en lugar de al nuevo durante la ventana de cambio, por lo que los workflows con uso intensivo de webhooks deben vigilarse especialmente durante esta fase.

Apagar el servidor antiguo

Después del cambio de DNS, espere al menos el tiempo del antiguo TTL más un margen de seguridad antes de apagar el servidor antiguo. Durante este tiempo, compruebe los registros del nuevo servidor en busca de tráfico entrante y asegúrese de que ya no se ejecuten ejecuciones importantes en el sistema antiguo. Solo cuando el nuevo servidor procese todo el tráfico de forma estable durante un período prolongado, debería detener el servidor antiguo y archivar una última copia de seguridad antes de eliminarlo definitivamente. NordFlux aplica este procedimiento por defecto en los cambios de servidor para clientes con n8n autoalojado, para mantener de forma continua la soberanía de datos alemana y el control sobre la infraestructura.

Preguntas frecuentes sobre el cambio de servidor sin tiempo de inactividad

¿Cuánto dura un cambio de servidor blue-green con n8n?

Depende del número de workflows, la cantidad de datos y el TTL de las entradas DNS. La migración real de los datos suele completarse en pocos minutos; el cambio de DNS con margen de seguridad puede tardar unas horas según la configuración del TTL.

¿Qué ocurre si no se transfiere la clave de cifrado?

Sin la N8N_ENCRYPTION_KEY idéntica, las credenciales importadas no se pueden descifrar. Los workflows sí aparecen, pero las conexiones a servicios externos fallan hasta que se vuelvan a introducir las credenciales.

¿Basta con una simple exportación de base de datos para la migración?

Para una migración completa, debería exportar tanto los workflows como las credenciales mediante los comandos CLI dedicados de n8n, además de la carpeta de base de datos propiamente dicha o de una instancia PostgreSQL externa, si se utiliza.

¿Hay que apagar n8n durante la migración?

No. Con el enfoque blue-green, el servidor antiguo permanece activo y utilizable hasta que el cambio de DNS se realiza con éxito. El tiempo de inactividad real se limita, en el caso ideal, al breve momento del cambio de DNS.