Skip to main content

n8n: Automatización de flujos de trabajo

Introducción

Este artículo documenta el despliegue de n8n como motor de automatización self-hosted, ejecutado mediante contenedores Docker, con persistencia externa y ejecución desacoplada mediante task runners.

n8n se integra en el stack como capa transversal de orquestación, actuando como punto de unión entre servicios internos (APIs, contenedores, scripts, webhooks) y servicios externos. El objetivo es centralizar lógica de automatización sin dispersarla en cada aplicación.

El enfoque prioriza control, trazabilidad, aislamiento de ejecución y persistencia, evitando dependencias SaaS y manteniendo el control completo sobre datos, credenciales y comportamiento interno.

Enfoque general / Arquitectura

El despliegue se basa en una arquitectura desacoplada y preparada para carga real:

  • Instancia principal de n8n actuando como plano de control:

    • UI web y API.
    • Gestión de workflows, credenciales y ejecuciones.
    • Orquestación y envío de tareas.

  • Task runners dedicados:

    • Procesos independientes responsables de ejecutar workflows y nodos de código.
    • Aislados del plano de control para evitar bloqueos o degradación de la UI.

  • Base de datos PostgreSQL externa:

    • Persistencia de workflows, ejecuciones y credenciales.
    • Eliminación de los límites de SQLite en concurrencia y fiabilidad.

  • Variables sensibles externalizadas mediante .env.

  • Volúmenes persistentes para estado interno y datos.

  • Preparado para exposición tras proxy inverso (Caddy) si se requiere acceso HTTPS.

La separación entre control (n8n) y ejecución (task runners) permite escalar, aislar errores y asumir workflows con carga real sin comprometer la estabilidad del sistema.

Requisitos previos

Se asumen resueltos previamente los siguientes puntos:

  • Docker y Docker Compose operativos.
  • Almacenamiento persistente disponible para volúmenes.
  • Subdominio definido si se va a exponer externamente.
  • Clave de cifrado generada previamente para proteger credenciales internas.

Estos requisitos condicionan decisiones clave, especialmente en seguridad, persistencia y aislamiento de ejecución.

Desarrollo

Qué se hizo y por qué

  • PostgreSQL externo

    • Sustituye a SQLite para evitar problemas de concurrencia y corrupción.
    • Facilita reinicios, recreaciones del contenedor y migraciones futuras.

  • Ejecución desacoplada mediante task runners

    • Los workflows y nodos de código no se ejecutan en la instancia principal.
    • La UI y la API permanecen responsivas incluso con flujos pesados o bloqueantes.
    • Permite escalar ejecución sin duplicar la interfaz web.

  • Variables sensibles en .env

    • Separación clara entre configuración y credenciales.
    • Facilita rotación de secretos sin modificar manifests.

  • Cifrado interno activado

    • Las credenciales nunca se almacenan en claro en la base de datos.
    • La estabilidad de la clave de cifrado es crítica para la integridad del sistema.

  • Opt-out explícito de telemetría

    • Se desactiva el envío de diagnósticos para mantener control total sobre la instancia.

  • Diseño proxy-ready

    • Preparado para funcionar tras HTTPS sin reconfiguraciones internas invasivas.

No se documentan comandos triviales ni pasos manuales: el despliegue se considera reproducible directamente desde repositorio.

Configuración utilizada (solo enlaces)

Toda la configuración se mantiene versionada en Gitea:

Contenido relevante:

  • .env: credenciales, claves de cifrado y parámetros de entorno.
  • docker-compose.yml: definición de servicios, runners, volúmenes, dependencias y red.

Validación

Comprobaciones mínimas tras el despliegue:

  • PostgreSQL inicia correctamente y supera su healthcheck.
  • La instancia principal de n8n arranca sin errores de conexión.
  • Los task runners se conectan al broker sin errores de autenticación.
  • Los volúmenes persistentes permiten escritura sin problemas de permisos.
  • La interfaz web responde correctamente tras reinicios.
  • Las credenciales y workflows sobreviven a reinicios completos del stack.

La validación busca confirmar funcionamiento estable, no auditar exhaustivamente el sistema.

Decisiones importantes o problemas detectados

  • El healthcheck de PostgreSQL es crítico: sin él, n8n puede arrancar antes de que la base de datos esté lista y fallar de forma poco visible.
  • La variable N8N_ENCRYPTION_KEY debe mantenerse estable; cambiarla invalida todas las credenciales existentes.
  • Los task runners no realizan ninguna acción si no hay ejecuciones que requieran código o carga; su inactividad inicial es normal.
  • Si se expone a Internet, es obligatorio definir correctamente WEBHOOK_URL, N8N_HOST, N8N_PROTOCOL y habilitar cookies seguras para evitar comportamientos inconsistentes.

Resumen breve

n8n se despliega como servicio de automatización centralizado, persistente y con ejecución desacoplada, integrándose en el stack mediante Docker, PostgreSQL y task runners dedicados. El diseño prioriza estabilidad, seguridad, aislamiento y capacidad de crecimiento sin depender de servicios externos.

Referencias

Back to top