Autoalojar n8n exige proteger la entrada, los datos, las credenciales y la recuperación.
Instalar n8n en tu propio servidor te da control sobre datos, versiones y costes de infraestructura. También te convierte en responsable de actualizaciones, copias de seguridad, certificados, disponibilidad y seguridad. Si nadie va a ocuparse de esas tareas, n8n Cloud suele ser la decisión más sensata.
Esta guía explica una arquitectura self-hosted razonable para un equipo pequeño: Docker, una base de datos separada, proxy inverso con HTTPS, volumen persistente y copias externas. No es la única configuración posible, pero evita varios errores de las instalaciones rápidas que terminan expuestas a internet sin protección.
Cuándo compensa autoalojar n8n
El self-hosting tiene sentido cuando necesitas una región concreta, integración con una red privada, mayor control de versiones o una carga estable que justifica administrar infraestructura. No es automáticamente más barato: hay que valorar tiempo técnico, monitorización y recuperación ante fallos.
| Criterio | n8n Cloud | n8n self-hosted |
|---|---|---|
| Puesta en marcha | Rápida | Requiere servidor y configuración |
| Mantenimiento | Gestionado | A cargo de tu equipo |
| Control de red y datos | Según el servicio | Mayor, si está bien configurado |
| Escalado | Simplificado por el proveedor | Debes diseñarlo y operarlo |
| Coste real | Suscripción previsible | Servidor, almacenamiento y horas técnicas |
Si todavía no has creado un workflow, empieza por nuestro curso de n8n desde cero. Instalar una plataforma antes de saber cómo la usarás suele generar un servidor olvidado y sin actualizar.
Arquitectura mínima recomendada
Para producción básica, usa un dominio propio, un proxy inverso que termine HTTPS, el contenedor de n8n sin puertos administrativos expuestos directamente, PostgreSQL y almacenamiento persistente. Guarda la clave de cifrado fuera del archivo que subes al repositorio.

Requisitos del servidor
Para aprender o ejecutar pocos flujos, una máquina virtual pequeña puede ser suficiente. La memoria y CPU necesarias crecen con la concurrencia, el tamaño de los datos y los nodos de código. No proceses archivos de cientos de megabytes en memoria sin probar el impacto.
- Una distribución Linux mantenida.
- Docker Engine y el complemento Docker Compose.
- Dominio o subdominio apuntando al servidor.
- Puertos 80 y 443 accesibles para el proxy.
- Firewall que bloquee servicios innecesarios.
- Destino externo para copias de seguridad.
La documentación oficial de Docker para n8n debe ser la referencia para versiones, variables y comandos vigentes.
Ejemplo de Docker Compose
El siguiente esquema es deliberadamente abreviado. Sustituye secretos, dominio y zona horaria, y fija versiones después de probarlas. No copies contraseñas reales en el archivo.
services:
postgres:
image: postgres:16
restart: unless-stopped
environment:
POSTGRES_DB: n8n
POSTGRES_USER: n8n
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- postgres_data:/var/lib/postgresql/data
n8n:
image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
restart: unless-stopped
environment:
DB_TYPE: postgresdb
DB_POSTGRESDB_HOST: postgres
DB_POSTGRESDB_DATABASE: n8n
DB_POSTGRESDB_USER: n8n
DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
N8N_HOST: automatiza.ejemplo.com
N8N_PROTOCOL: https
WEBHOOK_URL: https://automatiza.ejemplo.com/
N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
volumes:
- n8n_data:/home/node/.n8n
depends_on:
- postgres
volumes:
postgres_data:
n8n_data:
No publicamos el puerto de n8n en el host porque el proxy debería comunicarse por una red de Docker. Añade Caddy, Traefik o Nginx según tu experiencia. El proxy obtiene y renueva el certificado, limita solicitudes y envía tráfico al contenedor.
Variables que no debes improvisar
N8N_ENCRYPTION_KEY
n8n cifra credenciales almacenadas con una clave. Si pierdes esa clave, una copia de la base de datos puede no bastar para recuperar las credenciales. Guárdala en un gestor de secretos y en el procedimiento de recuperación, nunca en Git.
WEBHOOK_URL
Debe coincidir con la URL pública y HTTPS. Una configuración incorrecta hace que servicios externos intenten llamar a una dirección interna o con protocolo equivocado.
Zona horaria
Define la zona de n8n y del sistema de forma consciente. Prueba cambios de horario de verano si programas ejecuciones en hora local.
Seguridad antes de activar workflows
- Aplica actualizaciones del sistema y limita el acceso SSH.
- No expongas PostgreSQL ni el puerto interno de n8n.
- Usa HTTPS y contraseñas únicas.
- Protege el editor; los webhooks públicos deben ser solo los necesarios.
- Restringe nodos que ejecutan código o acceden al sistema de archivos.
- Revisa nodos comunitarios antes de instalarlos.
- Separa desarrollo y producción si el flujo es crítico.
n8n incluye una auditoría de seguridad que revisa credenciales, base de datos, archivos, nodos y configuración de instancia. Ejecútala tras instalar y de forma periódica; no sustituye un análisis del servidor.
Copias de seguridad que realmente se pueden restaurar
Copia la base de datos, el volumen de n8n, la clave de cifrado y la configuración del proxy. Cifra el destino y mantenlo fuera del servidor. Una copia en otro directorio de la misma máquina no protege frente a pérdida del disco o compromiso.
Programa una restauración de prueba. Levanta una instancia aislada, importa datos y comprueba que las credenciales funcionan. Documenta cuánto tarda y qué DNS o secretos hay que cambiar.
Actualizaciones sin romper producción
No uses una etiqueta flotante en un sistema crítico. Lee las notas, crea una copia, fija la nueva versión y prueba workflows importantes. Después actualiza y observa ejecuciones, webhooks y colas. Conserva un camino de vuelta compatible con la base de datos.
La sección oficial de hosting reúne recomendaciones de instalación, escalado y seguridad que deben revisarse antes de cada cambio importante.
Coste mensual real
Suma máquina virtual, almacenamiento, copias, dominio, correo transaccional, monitorización y horas de operación. Un servidor económico puede alojar pocos flujos, pero el coste de una incidencia fuera de horario puede superar meses de suscripción gestionada.
El self-hosting resulta atractivo cuando aporta control necesario o cuando el equipo ya opera infraestructura. Si se elige solo para evitar una cuota, suele infravalorarse el mantenimiento.
Monitorización: no esperes a que un cliente avise
Comprueba al menos disponibilidad HTTPS, uso de disco, memoria, estado de los contenedores y fallos de ejecución. Configura alertas hacia un canal independiente del propio n8n; si el flujo que envía la alerta depende de la instancia caída, nunca llegará.
Los webhooks merecen una prueba externa periódica. Una portada puede responder mientras las ejecuciones están detenidas o la base de datos rechaza conexiones. Registra tiempos y tasa de error, pero evita enviar datos personales completos al servicio de monitorización.
Errores frecuentes en una instalación self-hosted
- Publicar el editor directamente en un puerto sin HTTPS.
- Usar la misma contraseña de ejemplo en base de datos y aplicación.
- Actualizar automáticamente sin copia ni prueba.
- Guardar solo los workflows y olvidar credenciales, clave y base de datos.
- Instalar nodos comunitarios sin revisar mantenimiento y permisos.
- Permitir que un workflow procese entradas ilimitadas o archivos enormes.
El peligro aumenta cuando el flujo puede actuar sobre correo, CRM o producción. En nuestra guía de agentes de voz con IA mostramos por qué las herramientas y acciones sensibles necesitan permisos y aprobación fuera del modelo; el mismo principio se aplica a n8n.
Preguntas frecuentes
¿Puedo instalar n8n en un NAS o en casa?
Sí para aprendizaje o uso interno, si el equipo es compatible. Para webhooks públicos necesitarás conectividad, HTTPS y disponibilidad. Evita abrir puertos del router sin comprender los riesgos.
¿SQLite sirve para producción?
Puede funcionar en cargas pequeñas, pero PostgreSQL facilita una arquitectura más robusta y escalable. Decide según concurrencia, copias y estrategia de crecimiento.
¿Self-hosted significa que ningún dato sale del servidor?
No. Cada nodo puede enviar información a Google, OpenAI, un CRM u otra API. Autoalojar n8n controla el orquestador; debes revisar también cada integración.
¿Cómo sé si mi instalación es segura?
No existe una comprobación única. Ejecuta la auditoría de n8n, revisa firewall y proxy, aplica parches, prueba copias y monitoriza accesos. Para datos sensibles, solicita una revisión especializada.
Conclusión
Una instalación n8n self-hosted correcta no termina cuando aparece el editor. Termina cuando puedes actualizar, detectar un fallo y restaurar el servicio sin improvisar. Empieza con Docker, PostgreSQL, HTTPS, secretos protegidos y copias verificadas; después añade complejidad solo cuando la carga lo exija.
1 comentario en «n8n self-hosted: instalación segura, costes y mantenimiento»