# 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: * [Repositorio de configuración de n8n](https://gitea.jtrapero.eu.org/R4di04kt1v3/ChronosCMPS/src/branch/main/Automatizaci%C3%B3n%20y%20desarrollo/n8n) 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 * [Documentación de n8n](https://docs.n8n.io/) * [Repositorio en Github de n8n](https://github.com/n8n-io/n8n)