n8n es la plataforma de automatizacion low-code que mas ha crecido en el mundo auto-alojado en los ultimos dos anos. Ofrece alternativa seria a Zapier y Make para organizaciones que quieren controlar sus propios flujos sin pagar por integraciones pagadas por uso, y lo hace con una interfaz visual razonable y un modelo de licencias permisivo para uso interno. Este articulo cubre la instalacion concreta con Docker Compose, las decisiones de arquitectura que hay que tomar al arrancar y los puntos donde la mayoria de gente tropieza la primera vez. Es la configuracion que uso actualmente en un servidor de jacar.es y que lleva unos seis meses funcionando con flujos productivos.
Que hace n8n y cuando compensa auto-alojarlo
n8n permite conectar herramientas mediante flujos visuales donde cada nodo es una accion, un disparador o una transformacion. Hay nodos para cientos de servicios comunes: Google Workspace, Slack, bases de datos, APIs HTTP genericas, colas de mensajes, WhatsApp, correo, almacenamiento de objetos. Cuando no hay nodo, un nodo de codigo permite escribir JavaScript o Python para hacer casi cualquier cosa.
Auto-alojarlo compensa sobre todo por tres razones. La primera es el control de datos sensibles: si tus flujos mueven datos de clientes, contratos o datos financieros, tenerlos saltando entre un SaaS externo y tus sistemas internos supone una exposicion que no todas las organizaciones aceptan. La segunda es el coste: la version auto-alojada no cobra por ejecucion de flujo, lo que para volumenes altos es un ahorro sustancial frente a las alternativas comerciales. La tercera es la flexibilidad: integrar con sistemas internos, con APIs privadas o con bases de datos locales es mucho mas facil cuando n8n corre dentro de la misma red.
Donde no compensa es cuando los flujos son pocos y sencillos, con pocas integraciones externas y volumen bajo. En ese escenario la fricion operativa de mantener otra pieza de infraestructura supera el ahorro economico. Para equipos pequenos con cinco o diez flujos simples, una solucion SaaS suele salir mejor.
La eleccion de base de datos
La primera decision al instalar n8n es la base de datos para guardar flujos, credenciales, historial de ejecucion y usuarios. n8n soporta SQLite, PostgreSQL y MySQL. La opcion por defecto es SQLite, que funciona perfectamente para instalaciones pequenas con un solo proceso y pocos flujos.
Mi recomendacion, para casi cualquier despliegue que vaya a tener mas de un flujo o mas de un usuario, es empezar directamente con PostgreSQL. La migracion de SQLite a PostgreSQL despues es posible pero incomoda, y las ventajas de PostgreSQL aparecen incluso en escalas pequenas: copias de seguridad mejores, introspeccion mas clara, y la posibilidad de activar modo queue mas adelante sin volver a migrar.
Una nota importante es que si ya tienes un PostgreSQL compartido, puedes usarlo creando una base de datos dedicada para n8n. Esta es la configuracion que uso yo: un PostgreSQL compartido entre varias aplicaciones, con una base para Authentik, otra para Grafana y otra para n8n. Reduce el numero de contenedores y simplifica los respaldos.
El modo queue para cargas serias
Por defecto, n8n ejecuta flujos en el mismo proceso que sirve la interfaz web. Este modo es suficiente para volumenes bajos, pero cuando hay flujos largos o muchos simultaneos aparecen problemas: la interfaz se ralentiza, las ejecuciones pueden bloquearse, y no hay forma de escalar horizontalmente.
La solucion es el modo queue, que separa el proceso web del proceso worker y los comunica a traves de una cola Redis. En este modo la interfaz responde rapido incluso bajo carga, y se pueden anadir mas workers para procesar mas flujos en paralelo. La configuracion consiste en definir dos servicios Docker con la misma imagen pero variables distintas: el principal con EXECUTIONS_MODE igual a queue y QUEUE_BULL_REDIS_HOST apuntando a Redis, y los workers con el comando n8n worker.
Mi recomendacion es que si vas a pasar de los cinco flujos con ejecucion frecuente, empieces directamente en modo queue. El coste operativo de anadir Redis es minimo y evita una migracion incomoda cuando la carga crece. Para flujos puntuales y pocos usuarios, el modo por defecto basta.
Variables de entorno criticas
Hay unas pocas variables de entorno que conviene configurar correctamente desde el principio. La mas importante es N8N_ENCRYPTION_KEY, que es la clave usada para cifrar credenciales en la base de datos. Si esta clave cambia, todas las credenciales almacenadas quedan inutilizables. Generala una vez, guardala en un lugar seguro y no la cambies nunca.
Otras variables relevantes son N8N_HOST y WEBHOOK_URL, que dicen a n8n desde que dominio se accede y bajo que URL deben generarse los webhooks publicos. Si estos no coinciden con la realidad, los webhooks externos no funcionaran y tendras flujos que no se disparan sin explicacion aparente. El error tipico es instalar n8n detras de Traefik con un dominio y olvidar actualizar WEBHOOK_URL, dejando a los webhooks apuntando a localhost.
N8N_RUNNERS_ENABLED activa el ejecutor aislado para codigo de usuario, que es mas seguro porque los nodos de codigo corren en procesos separados del servidor principal. Desde las versiones recientes esta es la recomendacion por defecto y conviene tenerlo activado en cualquier despliegue que corra codigo no confiable.
Traefik o Nginx por delante
En la mayoria de instalaciones auto-alojadas, n8n corre detras de un proxy como Traefik o Nginx para manejar HTTPS y para servir mas de un servicio en el mismo servidor. La configuracion del proxy es estandar: un router apuntando al puerto 5678 del contenedor n8n, con certificado TLS automatico y, si se quiere proteger el acceso a la interfaz, un middleware de autenticacion.
Un detalle a cuidar es el tiempo limite del proxy. Algunos flujos pueden tardar minutos en ejecutarse, especialmente si llaman a APIs externas lentas o procesan archivos grandes. El tiempo limite por defecto de Nginx de sesenta segundos puede cortar estas ejecuciones, dando errores 504 Gateway Timeout. Conviene subirlo a varios minutos en la configuracion del proxy para las rutas de ejecucion de flujos.
Para webhooks publicos, donde los disparadores externos como Stripe o GitHub envian datos, hay que prestar atencion a que la URL publica sea accesible desde internet. Un error comun es tener n8n en una red interna detras de VPN, poner un webhook en un flujo y no entender por que no llega: el servicio externo no puede alcanzar la URL que n8n genera. La solucion es exponer un subdominio publico dedicado para webhooks o usar el endpoint alojado de n8n cloud para ese caso especifico.
Puntos de friccion tipicos
Tres problemas que casi todo el mundo encuentra la primera vez.
El primero es la persistencia de datos. El contenedor de n8n guarda datos en /home/node/.n8n, que debe ir en un volumen persistente. Varios equipos han perdido flujos y credenciales por ejecutar docker compose down con la bandera que borra volumenes. La recomendacion es usar volumenes nombrados y tener copias de seguridad regulares de la base de datos.
El segundo es el manejo de credenciales. n8n cifra las credenciales con N8N_ENCRYPTION_KEY, pero el proceso de backup debe incluir tanto la base de datos como la clave de cifrado. Si restauras la base en otro servidor con una clave distinta, todas las credenciales son inutiles. Guarda siempre las dos piezas juntas.
El tercero es la confusion entre flujos activos y no activos. Un flujo creado pero no activado no se ejecuta, aunque se vea en la interfaz y se pueda probar manualmente. Varios usuarios han dado por hecho que su flujo estaba en produccion cuando no lo estaba. La distincion es un interruptor en la parte superior del editor, y conviene revisar la lista de flujos activos despues de importar o modificar varios.
Mi lectura
n8n es una herramienta que cumple bien su promesa: automatizaciones complejas sin tener que escribir mucho codigo, con control sobre los datos y sin tarifas por ejecucion. Para organizaciones que tienen entre veinte y varios cientos de flujos, y que quieren mantener sus datos internos, la version auto-alojada es competitiva frente a cualquier alternativa comercial.
Mi recomendacion concreta es que si estas evaluando Zapier o Make para uso serio en tu organizacion, mires n8n auto-alojado antes de decidir. El coste mensual de infraestructura para una instalacion que atienda el tipo de volumen que pagarias cien euros en Zapier suele estar en torno a veinte euros, y tienes la ventaja anadida de poder hacer integraciones con sistemas internos sin problemas. La curva de aprendizaje es similar a la de cualquier plataforma de flujos, no es especialmente dificil.
Donde recomiendo parar y pensar es en el caso contrario: si no tienes operaciones internas con muchas integraciones o datos sensibles, y solo necesitas pegar tres APIs externas comunes, la version SaaS comercial sigue siendo mas facil de gestionar. Auto-alojar infraestructura siempre tiene coste operativo, y ese coste debe compensarse con beneficio real. n8n no es una excepcion a esa regla general.
