Guía para el cambio de servidor en n8n autoalojado: enfoque blue-green con migración de datos, cambio de DNS y tiempo de inactividad mínimo.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Fundador de NordFlux. Siete años de experiencia, desde la web y el SEO hasta la automatización a escala de grupo, hoy de forma pragmática para las pymes y con soberanía de datos alemana.
Certificaciones
Cómo instalar n8n con Docker Compose: Postgres en lugar de SQLite, .env, volúmenes y actualizaciones paso a paso.
Preparar el nuevo servidor, migrar workflows y credenciales, y conmutar el DNS con un enfoque blue-green: cada paso tiene sus propias trampas cuando los workflows en producción deben seguir funcionando durante la transición. NordFlux planifica y acompaña la migración de su servidor de n8n para que sus automatizaciones sigan funcionando sin interrupciones perceptibles.
