Cómo instalar n8n auto-alojado con Docker

Actualizado: 2026-05-03

n8n es la plataforma de automatización low-code que más ha crecido en el mundo auto-alojado en los últimos dos años. 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 artículo cubre la instalación concreta con Docker Compose, las decisiones de arquitectura que hay que tomar al arrancar y los puntos donde la mayoría de gente tropieza la primera vez.

Puntos clave

• La primera decisión importante es la base de datos: empieza directamente con PostgreSQL, no con SQLite, para cualquier despliegue con más de un flujo o más de un usuario.
• El modo queue (separar proceso web de workers mediante Redis) es necesario por encima de cinco flujos con ejecución frecuente.
• N8N_ENCRYPTION_KEY es la variable más crítica: genérala una vez, guárdala en lugar seguro y nunca la cambies.
• Los webhooks públicos requieren que WEBHOOK_URL apunte exactamente al dominio público accesible desde internet, no a localhost.
• La persistencia de /home/node/.n8n debe ir en un volumen nombrado; varios equipos han perdido flujos y credenciales por olvidar esto.

Qué hace n8n y cuándo compensa auto-alojarlo

n8n permite conectar herramientas mediante flujos visuales donde cada nodo es una acción, un disparador o una transformación. Hay nodos para cientos de servicios comunes: Google Workspace, Slack, bases de datos, APIs HTTP genéricas, colas de mensajes, WhatsApp, correo, almacenamiento de objetos. Cuando no hay nodo, un nodo de código permite escribir JavaScript o Python para hacer casi cualquier cosa.

Auto-alojarlo compensa sobre todo por tres razones:

• 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 exposición que no todas las organizaciones aceptan.
• Coste: la versión auto-alojada no cobra por ejecución de flujo, lo que para volúmenes altos es un ahorro sustancial frente a las alternativas comerciales.
• Flexibilidad: integrar con sistemas internos, con APIs privadas o con bases de datos locales es mucho más fácil 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 fricción operativa de mantener otra pieza de infraestructura supera el ahorro económico.

La elección de base de datos

La primera decisión al instalar n8n es la base de datos para guardar flujos, credenciales, historial de ejecución y usuarios. n8n soporta SQLite, PostgreSQL y MySQL. La opción por defecto es SQLite, que funciona perfectamente para instalaciones pequeñas con un solo proceso y pocos flujos.

La recomendación, para casi cualquier despliegue que vaya a tener más de un flujo o más de un usuario, es empezar directamente con PostgreSQL. La migración de SQLite a PostgreSQL después es posible pero incómoda, y las ventajas de PostgreSQL aparecen incluso en escalas pequeñas:

• Mejores copias de seguridad.
• Introspección más clara.
• Posibilidad de activar modo queue más adelante sin volver a migrar.

Si ya tienes un PostgreSQL compartido, puedes usarlo creando una base de datos dedicada para n8n. Esto reduce el número 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 volúmenes bajos, pero cuando hay flujos largos o muchos simultáneos aparecen problemas: la interfaz se ralentiza, las ejecuciones pueden bloquearse y no hay forma de escalar horizontalmente.

La solución es el modo queue, que separa el proceso web del proceso worker y los comunica a través de una cola Redis. En este modo la interfaz responde rápido incluso bajo carga, y se pueden añadir más workers para procesar más flujos en paralelo.

La configuración consiste en definir dos servicios Docker con la misma imagen pero variables distintas:

• El principal con EXECUTIONS_MODE=queue y QUEUE_BULL_REDIS_HOST apuntando a Redis.
• Los workers con el comando n8n worker.

La recomendación es que si vas a pasar de los cinco flujos con ejecución frecuente, empieces directamente en modo queue. El coste operativo de añadir Redis es mínimo y evita una migración incómoda cuando la carga crece.

Variables de entorno críticas

Hay unas pocas variables de entorno que conviene configurar correctamente desde el principio:

• N8N_ENCRYPTION_KEY: la clave usada para cifrar credenciales en la base de datos. Si esta clave cambia, todas las credenciales almacenadas quedan inutilizables. Genérala una vez, guárdala en lugar seguro y no la cambies nunca.
• N8N_HOST y WEBHOOK_URL: dicen a n8n desde qué dominio se accede y bajo qué URL deben generarse los webhooks públicos. Si no coinciden con la realidad, los webhooks externos no funcionarán. El error típico es instalar n8n detrás 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 código de usuario. Desde las versiones recientes esta es la recomendación por defecto para cualquier despliegue que corra código no confiable.

Traefik o Nginx por delante

En la mayoría de instalaciones auto-alojadas, n8n corre detrás de un proxy como Traefik o Nginx para manejar HTTPS y para servir más de un servicio en el mismo servidor. La configuración del proxy es estándar: un router apuntando al puerto 5678 del contenedor n8n, con certificado TLS automático.

Un detalle a cuidar es el tiempo límite del proxy. Algunos flujos pueden tardar minutos en ejecutarse, especialmente si llaman a APIs externas lentas o procesan archivos grandes. El tiempo límite por defecto de Nginx de sesenta segundos puede cortar estas ejecuciones, dando errores 504 Gateway Timeout. Conviene subirlo a varios minutos para las rutas de ejecución de flujos.

Para webhooks públicos hay que prestar atención a que la URL pública sea accesible desde internet. Un error común es tener n8n en una red interna detrás de VPN, poner un webhook en un flujo y no entender por qué no llega: el servicio externo no puede alcanzar la URL que n8n genera.

Puntos de fricción típicos

Tres problemas que casi todo el mundo encuentra la primera vez:

• 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 volúmenes. La recomendación es usar volúmenes nombrados y tener copias de seguridad regulares de la base de datos.
• 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 inútiles. Guarda siempre las dos piezas juntas.
• Confusión 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. La distinción es un interruptor en la parte superior del editor, y conviene revisar la lista de flujos activos después de importar o modificar varios.

Mi lectura

n8n es una herramienta que cumple bien su promesa: automatizaciones complejas sin tener que escribir mucho código, con control sobre los datos y sin tarifas por ejecución. Para organizaciones que tienen entre veinte y varios cientos de flujos, y que quieren mantener sus datos internos, la versión auto-alojada es competitiva frente a cualquier alternativa comercial.

La recomendación concreta es que si estás evaluando Zapier o Make para uso serio en tu organización, mires n8n auto-alojado antes de decidir. El coste mensual de infraestructura para una instalación que atienda el tipo de volumen que pagarías cien euros en Zapier suele estar en torno a veinte euros, y tienes la ventaja añadida de poder hacer integraciones con sistemas internos sin problemas.

Donde conviene 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 versión SaaS comercial sigue siendo más fácil de gestionar. Auto-alojar infraestructura siempre tiene coste operativo, y ese coste debe compensarse con beneficio real. n8n no es una excepción a esa regla general.

Conclusión

La decisión de auto-alojar n8n se reduce a una pregunta: ¿el control de los datos y el ahorro en ejecuciones compensa el coste operativo de mantener otra pieza de infraestructura? Para volúmenes medios y datos sensibles, la respuesta suele ser sí.