Cómo alojar n8n por tu cuenta en 2026: despliegue, TLS, webhooks y copias de seguridad

Un contenedor de n8n puede aparecer en verde mientras el trabajo que les importa a los usuarios está fallando. En n8n, ese fallo oculto suele deberse a que los enlaces de webhook siguen apuntando a localhost o a que las cabeceras del proxy indican HTTP. Esta guía considera como prueba de aceptación «activar un workflow con un webhook de producción, llamar a ese webhook desde fuera del servidor y confirmar que la ejecución llega a su nodo final», y diseña el despliegue a partir de ese resultado.

n8n cumple una función específica en el stack: automatización de workflows con más de 400 integraciones y un sistema de nodos extensible. Por tanto, la pregunta en producción no es si el puerto 5678 responde una vez, sino si el estado, las dependencias y la dirección pública siguen coincidiendo después de un reinicio, una actualización y una restauración.

Separa los contenedores reemplazables de los datos persistentes

Define el punto y el tiempo de recuperación de n8n en términos de la base de datos y de los datos de cifrado y configuración de .n8n. Monta /home/node/.n8n antes del bootstrap, escribe algunos datos de prueba inocuos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Un volumen con nombre resuelve la persistencia durante el redeploy; no resuelve una intrusión ni la pérdida del servidor.

Prepara un entorno de restauración limpio, usa la misma versión fijada de la aplicación y comprueba que las credenciales restauradas siguen descifrándose y que un workflow restaurado recibe la misma URL pública de webhook. Registra los comandos, las correcciones de propietario y el tiempo transcurrido. La guía de copias de seguridad ofrece un estándar útil: una copia de seguridad se considera fiable después de restaurarla, no después de subirla.

Haz reproducible el arranque de n8n

Un comando mínimo resulta útil cuando muestra qué gestionará posteriormente la plataforma.

docker run -d \
  --name n8n \
  --restart unless-stopped \
  -p 127.0.0.1:5678:5678 \
  -v n8n-data:/home/node/.n8n \
  -e N8N_ENCRYPTION_KEY=replace-with-a-long-random-value \
  docker.n8n.io/n8nio/n8n

Aquí, el puerto 5678 permanece privado para el host y todas las rutas necesarias están definidas explícitamente. Añade la configuración de conexión revisada para Postgres en una configuración de producción duradera y multiusuario; utiliza nombres privados para los servicios privados. Verifica el arranque tanto con los logs como con la prueba específica de la aplicación: activa un workflow con un webhook de producción, llama a ese webhook desde fuera del servidor y confirma que la ejecución llega a su nodo final. Una vez verificado, fija la versión de la imagen para que un reemplazo rutinario no cambie el comportamiento de forma silenciosa.

Puertos, procesos y servicios privados

Empieza por el network namespace de n8n: su listener web está en el puerto 5678, no en un puerto del host copiado de un tutorial para portátiles. El contrato de red de n8n es Postgres para una configuración de producción duradera y multiusuario. Mantén los endpoints privados en el DNS interno, permite únicamente las llamadas salientes necesarias y asigna a n8n una credencial de servicio con permisos limitados.

Una vez satisfecho el requisito, ejecuta el escenario completo: activa un workflow con un webhook de producción, llama a ese webhook desde fuera del servidor y confirma que la ejecución llega a su nodo final. Registra logs y mediciones de la concurrencia de ejecuciones, la profundidad de la cola, el tamaño de las cargas binarias y los nodos de larga duración, en lugar de las vistas de la página del editor. Esa evidencia se convierte en la primera arquitectura conocida como válida y permite probar posteriormente los cambios entre el compute de Dockup y un servidor conectado.

Evita que el éxito del proxy oculte un fallo de la aplicación

El límite público de n8n debería ser un único hostname canónico, TLS automático y un único destino interno en el puerto 5678. Configura WEBHOOK_URL con la URL HTTPS externa exacta para que los clientes vuelvan a una dirección que el servicio reconozca.

Si la transacción de aceptación falla, clasifica el primer error. Los problemas de DNS, certificados y 502 pertenecen a la lista de comprobación de validación de TLS. La condición «los enlaces de webhook siguen apuntando a localhost o las cabeceras del proxy indican HTTP» pertenece al lado de la aplicación, después de que una solicitud haya llegado correctamente a n8n.

Qué debe pasar antes de que lleguen datos reales a n8n

Convierte la prueba de smoke de n8n en un comando de release repetible o en un runbook breve. Su salida debe demostrar este resultado: activar un workflow con un webhook de producción, llamar a ese webhook desde fuera del servidor y confirmar que la ejecución llega a su nodo final. Registra con el resultado la versión de la aplicación, el digest del contenedor, el hostname de la ruta y el identificador de los datos de prueba.

Ejecuta la misma comprobación después de un cambio rutinario de contenedor y de restaurar la base de datos junto con los datos de cifrado y configuración de .n8n en otro lugar. La restauración se ha realizado correctamente cuando las credenciales restauradas siguen descifrándose y un workflow restaurado recibe la misma URL pública de webhook. Compara el tiempo y el consumo relacionados con la concurrencia de ejecuciones, la profundidad de la cola, el tamaño de las cargas binarias y los nodos de larga duración, en lugar de las vistas de la página del editor; un cambio importante merece investigación aunque la acción final siga superándose.

Después, prueba un fallo controlado: deniega temporalmente a la identidad de prueba el acceso a Postgres para una configuración de producción duradera y multiusuario. Confirma que n8n muestra el error y vuelve a la normalidad sin ediciones manuales destructivas. Conserva únicamente el fragmento de log necesario y redactado. Este control de cuatro partes cubre el arranque, la persistencia, la recuperación y la gestión de fallos.

Comprobaciones de capacidad y actualización

Crea dashboards en torno a la concurrencia de ejecuciones, la profundidad de la cola, el tamaño de las cargas binarias y los nodos de larga duración, en lugar de las vistas de la página del editor. Un gráfico de CPU sin el contexto de esa carga de trabajo no puede explicar por qué n8n va lento. Añade una comprobación sintética o programada que intente activar un workflow con un webhook de producción, llamar a ese webhook desde fuera del servidor y confirmar que la ejecución llega a su nodo final usando datos de prueba inocuos.

Antes de actualizar, ten en cuenta este riesgo específico de la aplicación: las migraciones de la base de datos, el cifrado de credenciales y los community nodes instalados deben seguir siendo compatibles con la release de n8n de destino. Restaura una copia de seguridad reciente en un despliegue aislado, ejecuta allí las migraciones y compara el comportamiento. Si los enlaces de webhook siguen apuntando a localhost o las cabeceras del proxy indican HTTP, inspecciona el límite implicado —origen público, almacenamiento o dependencia— antes de modificar ajustes no relacionados.

Refuerza la seguridad de n8n después del bootstrap

No heredes las suposiciones de seguridad de un tutorial local. La preocupación específica de n8n es rotar N8N_ENCRYPTION_KEY después de haber guardado credenciales. Por tanto, en producción el editor debe mantenerse autenticado y solo deben exponerse las rutas de webhook que las integraciones necesiten realmente.

Genera N8N_ENCRYPTION_KEY una sola vez, mantenla fuera de Git y consérvala con el manifiesto de recuperación, porque cambiarla puede invalidar el estado cifrado o firmado de la aplicación. Limita el acceso al sistema de archivos y a la red, protege los endpoints de configuración y define límites de subida, solicitudes o ejecuciones en torno a la concurrencia de ejecuciones, la profundidad de la cola, el tamaño de las cargas binarias y los nodos de larga duración, en lugar de las vistas de la página del editor.

Mantén n8n explícito mientras Dockup gestiona el routing

El despliegue de n8n con un clic de Dockup debería hacer que los reemplazos sean seguros: la ruta debe seguir apuntando al puerto 5678, los secretos no deben estar integrados en la imagen y las rutas persistentes deben estar disponibles en el nuevo contenedor. El mismo despliegue puede ejecutarse en el compute de Dockup o en una máquina conectada.

Completa el trabajo específico de la aplicación conectando y probando Postgres para una configuración de producción duradera y multiusuario, aplicando la dirección pública canónica y ejecutando esta comprobación de aceptación: activa un workflow con un webhook de producción, llama a ese webhook desde fuera del servidor y confirma que la ejecución llega a su nodo final. Añade el resultado de la restauración al runbook antes de que lleguen los usuarios reales.

Preguntas frecuentes

¿Qué necesita n8n para un despliegue de producción?

Enruta el contenedor de n8n en el puerto 5678 a través de un único origen HTTPS. El requisito de red complementario es Postgres para una configuración de producción duradera y multiusuario. No des n8n por listo hasta que puedas activar un workflow con un webhook de producción, llamar a ese webhook desde fuera del servidor y confirmar que la ejecución llega a su nodo final.

¿Qué datos de n8n deben incluirse en una copia de seguridad?

Conserva /home/node/.n8n e incluye la base de datos junto con los datos de cifrado y configuración de .n8n en el mismo manifiesto de recuperación. Una restauración limpia de n8n solo se considera correcta cuando las credenciales restauradas siguen descifrándose y un workflow restaurado recibe la misma URL pública de webhook.

¿Necesita n8n HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de n8n y mantén el puerto 5678 en la ruta interna. Aplica correctamente el ajuste de n8n: configura WEBHOOK_URL con la URL HTTPS externa exacta. En n8n, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento de los clientes que depende del origen.

¿Cómo se debe probar una actualización de n8n?

Restaura el estado actual de n8n en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención a que las migraciones de la base de datos, el cifrado de credenciales y los community nodes instalados sigan siendo compatibles con la release de n8n de destino. Conserva la imagen anterior de n8n hasta comprender los límites de la migración de datos y del rollback.