n8n en tu propio servidor,: guía con Docker, backups y seguridad

Montar n8n con Docker en un VPS propio es viable para producción si cumples cuatro cosas: base de datos Postgres en lugar de SQLite, un proxy inverso con HTTPS y acceso restringido, copias de seguridad automáticas de la base de datos y de la clave de cifrado, y una rutina de actualización con versión fijada. Con un VPS de 4 vCPU y 8 GB de RAM aguantas decenas de flujos activos; a partir de ahí toca separar workers con el modo cola de n8n usando Redis.

Soy Oscar Álvarez, fundador de SEOscar, agencia de ecommerce en Barcelona. Monto automatizaciones con n8n para tiendas online desde hace años, y casi siempre acabo en el mismo sitio: un VPS con n8n en Docker y Postgres, detrás de un proxy inverso. Esta guía es mi stack real, el mismo que uso para clientes y para mis propios productos, sin las partes que no puedo enseñar (claves, dominios internos y credenciales).

n8n es una herramienta de automatización de flujos de trabajo de código abierto: conectas servicios, APIs y bases de datos mediante nodos y disparadores, sin escribir todo el pegamento a mano. La versión en la nube es cómoda, pero cuando los flujos tocan datos de pedidos, clientes o stock, muchas tiendas prefieren tenerlo en su propio servidor. Ahí empieza el trabajo de verdad: que no se caiga, que no se pierda nada y que no entre nadie que no deba.

Aviso honesto antes de empezar: el autoalojamiento, lo que en inglés se llama self-hosting, no es gratis. Es barato en euros y caro en atención. Si no tienes a alguien que mire los registros del sistema (logs) cuando algo falla a las tres de la mañana de un Black Friday, lee hasta el último apartado antes de decidir.

Requisitos y elección de VPS para n8n

Para un n8n self hosted de producción con Postgres recomiendo un VPS (servidor privado virtual) de 4 vCPU, 8 GB de RAM y 80 GB de disco SSD con Ubuntu LTS. Con 2 vCPU y 4 GB funciona para empezar, pero se queda corto en cuanto ejecutas flujos con nodos de código, imágenes o PDF. La RAM es el recurso que se agota primero, no la CPU.

Qué consume realmente n8n

n8n carga en memoria los datos que pasan entre nodos. Un flujo que descarga un CSV de 50.000 pedidos y lo recorre registro a registro puede comerse 1 o 2 GB él solo durante la ejecución. Por eso el dimensionado no depende del número de flujos, sino del volumen de datos que mueve el flujo más pesado que tengas.

Proveedores y criterios de elección

Para elegir un vps para n8n yo miro cuatro cosas: centro de datos en la Unión Europea si tratas datos personales, copias de seguridad automáticas del disco (snapshots), IP fija dedicada y posibilidad de ampliar recursos sin reinstalar. Hetzner, OVH, DigitalOcean y Scaleway cumplen las cuatro en sus planes básicos. El precio ronda los 10 a 25 euros al mes, bastante menos que el plan equivalente en la nube de n8n.

• Sistema operativo: Ubuntu Server LTS, por documentación y soporte largo.

• Disco: SSD o NVMe, nunca HDD. Postgres y los registros agradecen la latencia baja.

• Red: salida sin límite estricto de tráfico si vas a mover ficheros.

• Copias del proveedor: activa las copias automáticas del disco, cuestan poco y salvan noches enteras.

• Zona horaria: configúrala desde el principio con la variable GENERIC_TIMEZONE, o tus tareas programadas se dispararán a deshora.

Docker Compose con Postgres: la configuración que uso

La instalación de n8n docker compose que recomiendo tiene tres servicios: n8n, Postgres y un proxy inverso (Caddy o Traefik). La clave está en no usar SQLite en producción: la base de datos por defecto de n8n se corrompe con escrituras simultáneas y no escala. Postgres te da transacciones fiables, copias de seguridad con pg_dump y la opción de crecer después.

Estructura de ficheros

Yo mantengo todo en /opt/n8n con tres elementos: docker-compose.yml, un fichero .env con las variables sensibles fuera del compose, y volúmenes con nombre para los datos de n8n y de Postgres. El .env nunca va a un repositorio de control de versiones (Git). El docker-compose.yml sí, porque así cualquier despliegue nuevo se reproduce en diez minutos.

Variables que no puedes olvidar

• DB_TYPE=postgresdb y las credenciales de conexión a Postgres.

• N8N_ENCRYPTION_KEY: cifra las credenciales guardadas. Si la pierdes, pierdes todas las credenciales de todos los flujos. Guárdala en un gestor de contraseñas, hoy mismo.

• N8N_HOST, N8N_PROTOCOL=https y WEBHOOK_URL con tu dominio real, o los webhooks apuntarán a localhost.

• GENERIC_TIMEZONE=Europe/Madrid para que los nodos de tipo Schedule hagan lo que esperas.

• EXECUTIONS_DATA_PRUNE=true y EXECUTIONS_DATA_MAX_AGE para que Postgres no crezca sin control con el historial de ejecuciones.

• N8N_DIAGNOSTICS_ENABLED=false si prefieres no enviar telemetría.

El fallo que más veo cuando me pasan un docker n8n ya montado por otro: EXECUTIONS_DATA_PRUNE sin configurar. A los seis meses la tabla de ejecuciones pesa 30 GB, el disco se llena y n8n deja de arrancar. Poner un máximo de 14 o 30 días de histórico resuelve la mayoría de estos sustos.

Arrancar y comprobar

Con docker compose up -d levantas los tres contenedores. Después comprueba tres cosas antes de dar por buena la instalación: que docker compose logs -f n8n no muestra errores de conexión a la base de datos, que la comprobación de estado (healthcheck) de Postgres pasa, y que un flujo de prueba con un webhook responde desde fuera del servidor, no solo desde localhost. Si el webhook no responde desde internet, la variable WEBHOOK_URL está mal configurada.

Dominio, HTTPS y acceso restringido

n8n no debe estar nunca expuesto en el puerto 5678 con http sin cifrar. La configuración mínima de producción es: un subdominio propio (por ejemplo automatizaciones.tudominio.com), un proxy inverso que gestione el certificado TLS con Let's Encrypt, y el puerto de n8n cerrado al exterior en el cortafuegos (firewall). Caddy hace esto con cuatro líneas de configuración y renueva los certificados solo.

El cortafuegos, primero

Con ufw dejo abiertos solo los puertos 80, 443 y el de SSH (cambiado del 22 y con acceso por clave, nunca por contraseña). Todo lo demás, cerrado. Ojo con un detalle que pilla a mucha gente: Docker escribe sus propias reglas en iptables y puede saltarse ufw si publicas puertos con la sintaxis corta. Publica siempre los puertos internos como 127.0.0.1:5678:5678 para que solo escuche en la interfaz local.

Quién puede entrar al editor

El panel de n8n tiene usuarios y contraseñas, pero yo añado siempre una capa más. Dos opciones según el caso: restringir el acceso al editor por IP en el proxy inverso (si el equipo trabaja desde oficina o red privada virtual, VPN), o dejar público solo la ruta /webhook y /webhook-test y proteger el resto. La segunda es la que uso con clientes que reciben webhooks de Shopify o de pasarelas de pago desde IP cambiantes.

• Autenticación de dos factores activada para todos los usuarios del editor.

• Claves SSH con frase de contraseña, acceso por contraseña deshabilitado.

• Actualizaciones de seguridad del sistema automáticas (unattended-upgrades).

• Fail2ban o equivalente vigilando los intentos de acceso SSH.

• Credenciales de terceros con el mínimo permiso posible: una clave de API de Shopify con permisos de solo lectura si el flujo solo lee datos.

Backups y actualizaciones sin romper nada

Una copia de seguridad de n8n son dos cosas: el volcado de la base de datos Postgres y la clave de cifrado N8N_ENCRYPTION_KEY. Sin la clave, el volcado es inútil porque todas las credenciales quedan ilegibles. Yo programo un pg_dump diario comprimido, lo subo a un almacenamiento externo tipo S3 o Backblaze B2 con retención de 30 días, y guardo la clave aparte en el gestor de contraseñas.

La prueba de restauración

Una copia de seguridad que no has restaurado nunca no es una copia de seguridad, es una esperanza. Una vez cada trimestre levanto los contenedores en una máquina limpia, restauro el último volcado y compruebo que los flujos abren y que las credenciales descifran. Esta rutina me ha permitido detectar a tiempo un cron de backup que llevaba semanas fallando en silencio.

Actualizar sin perder la noche

Nunca uso la etiqueta latest en la imagen de n8n. Fijo la versión exacta (por ejemplo n8nio/n8n:1.XX.X) y actualizo a mano cuando toca. El procedimiento es siempre el mismo: leer las notas de la versión buscando cambios incompatibles, hacer un pg_dump, cambiar el número de versión en el compose, ejecutar docker compose pull y up -d, y revisar los flujos críticos uno por uno. Si algo se rompe, vuelves a la versión anterior en un minuto.

Fijar la versión de la imagen y hacer un volcado antes de cada actualización es la diferencia entre un mantenimiento de quince minutos y un sábado entero reconstruyendo flujos.

Colas y escalado cuando el volumen crece

n8n en modo normal ejecuta todo en un solo proceso: si un flujo pesado bloquea el hilo, los demás esperan. El modo cola (EXECUTIONS_MODE=queue) separa la instancia principal de uno o varios workers (procesos trabajadores) y usa Redis como cola de trabajos. Es el paso natural cuando pasas de decenas a miles de ejecuciones diarias o cuando los webhooks empiezan a dar tiempos de espera agotados.

Qué cambia en el compose

Añades un servicio Redis y uno o más servicios worker que ejecutan el comando n8n worker, compartiendo la misma base de datos Postgres, la misma clave de cifrado y las mismas variables de conexión a Redis. La instancia principal sigue sirviendo el editor y recibiendo los webhooks; los workers hacen el trabajo pesado. Puedes escalar con docker compose up -d --scale n8n-worker=3.

Cuándo merece la pena

En las tiendas que audito, la mayoría de instalaciones de n8n no necesitan modo cola: con 20 o 30 flujos y unos cientos de ejecuciones al día, una instancia sobra. El modo cola se justifica cuando ves ejecuciones encoladas en el panel, cuando un proceso nocturno de sincronización de catálogo bloquea los webhooks de pedidos, o cuando necesitas que el sistema sobreviva al reinicio de un worker sin perder trabajos.

Qué monitorizar

• Uso de RAM del contenedor n8n (con docker stats o un agente tipo Netdata).

• Tamaño de la base de datos y de la tabla de ejecuciones.

• Espacio libre en disco, con alerta por debajo del 20%.

• Ejecuciones fallidas: configura un flujo de error (Error Trigger) que te avise por Slack o correo.

• Tiempo de respuesta de los webhooks críticos desde un servicio externo de monitorización de disponibilidad.

Cuándo no montarlo tú

No deberías autoalojar n8n si no hay nadie en tu equipo con acceso al servidor y responsabilidad clara sobre él. El coste real del autoalojamiento no es el VPS de 15 euros, son las horas de mantenimiento al mes y la capacidad de reaccionar cuando un flujo que mueve pedidos deja de funcionar un viernes. Si tu automatización toca facturación, stock o envíos, el riesgo deja de ser técnico y pasa a ser de negocio.

Hay un segundo caso donde no lo recomiendo: cuando el equipo no sabe reconstruir los flujos. He visto tiendas con 40 automatizaciones montadas por alguien que ya no está, sin documentación y sin exportaciones versionadas. Técnicamente funcionaba. Operativamente era una bomba de relojería. Exporta los flujos a formato JSON y versiónalos, aunque sea en un repositorio privado.

La alternativa sensata si quieres control de los datos pero no el mantenimiento: que alguien externo se encargue del servidor, las copias de seguridad y las actualizaciones, y que el código y los flujos sigan siendo tuyos. Es exactamente como trabajo en los proyectos de automatizaciones de SEOscar: construyo sobre tu infraestructura o sobre la mía, pero todo lo que monto queda en tu propiedad.

Qué haría yo desde SEOscar en tu caso

Cuando llego a una tienda que ya tiene n8n montado, lo primero que reviso no son los flujos, es la infraestructura: si hay Postgres o SQLite, si existe copia de seguridad y si alguien la ha restaurado alguna vez, si la clave de cifrado está guardada en algún sitio y qué versión de imagen corre. En buena parte de los casos encuentro al menos un fallo de los tres primeros.

Después miro qué aporta cada flujo al negocio. Automatizar por automatizar genera mantenimiento sin retorno. En ecommerce los flujos que suelen pagar el servidor son la sincronización de stock, la recuperación de carritos conectada a datos reales, el enriquecimiento de fichas de producto y los avisos operativos. Ese análisis forma parte del diagnóstico con datos reales con el que empiezo cualquier proyecto, sea sobre Shopify o sobre WooCommerce.

Y una cosa que digo siempre: todo lo que monto queda en propiedad del cliente. El docker-compose, los flujos exportados y la documentación son tuyos. Si mañana quieres llevártelo a otro proveedor o mantenerlo en casa, puedes hacerlo sin pedirme permiso.

Resumen operativo: la lista mínima de producción

Si solo te llevas una cosa de este artículo, que sea esta lista. Es lo que compruebo en cualquier instalación de n8n docker antes de considerarla apta para producción.

• Postgres como base de datos, nunca SQLite.

• N8N_ENCRYPTION_KEY guardada fuera del servidor.

• HTTPS con certificado válido y puerto 5678 cerrado al exterior.

• Copia de seguridad diaria de Postgres en almacenamiento externo y restauración probada.

• Versión de la imagen fijada, nunca latest.

• Prune de ejecuciones activado con un máximo de días.

• Flujo de error que avisa cuando algo falla.

• Flujos exportados a JSON y versionados.

Si quieres control sobre tus datos pero no quieres mantener un servidor, esa parte la puedo llevar yo. Si prefieres montarlo tú, esta guía debería bastarte para llegar a producción sin sustos. Y si lo que te interesa es qué automatizar primero en tu tienda para que el esfuerzo tenga retorno, reserva un diagnóstico: salgas o no conmigo después, el plan es tuyo.

Preguntas frecuentes

¿Es seguro usar n8n self hosted con datos de clientes?

Sí, si cumples unos mínimos: HTTPS con certificado válido, el puerto de n8n cerrado al exterior, acceso al editor restringido por IP o con doble factor, y la clave de cifrado N8N_ENCRYPTION_KEY guardada fuera del servidor. Autoalojar te da control sobre dónde residen los datos, lo que facilita el cumplimiento del RGPD si el VPS está en la Unión Europea. La parte frágil casi nunca es n8n, es el servidor mal configurado.

¿Puedo usar SQLite en lugar de Postgres con n8n en Docker?

Para pruebas sí, para producción no lo recomiendo. SQLite es la base de datos por defecto de n8n y funciona bien con poco volumen, pero sufre con escrituras simultáneas, no admite el modo cola con varios workers y las copias de seguridad son menos fiables. Migrar de SQLite a Postgres más adelante es posible, pero es una operación delicada: mejor empezar directamente con Postgres.

¿Qué VPS necesito para n8n y cuánto cuesta?

Para un uso de producción moderado, un VPS de 4 vCPU, 8 GB de RAM y 80 GB de SSD es un buen punto de partida, y cuesta entre 10 y 25 euros al mes en proveedores como Hetzner, OVH, DigitalOcean o Scaleway. Con 2 vCPU y 4 GB puedes empezar si tus flujos mueven poco volumen de datos. La memoria RAM es el recurso que se agota primero, porque n8n carga en memoria los datos que pasan entre nodos.

¿Qué pasa si pierdo la clave de cifrado de n8n?

Pierdes el acceso a todas las credenciales guardadas en la instancia: claves de API, tokens de autenticación, contraseñas de bases de datos. Los flujos siguen ahí, pero cada credencial hay que volver a introducirla a mano. Por eso la N8N_ENCRYPTION_KEY debe guardarse en un gestor de contraseñas el mismo día que montas la instancia, nunca solo en el fichero .env del servidor.

¿Cómo actualizo n8n en Docker sin romper los flujos?

Fija siempre la versión exacta de la imagen en el docker-compose, nunca uses la etiqueta latest. El procedimiento seguro es: leer las notas de la versión buscando cambios incompatibles, hacer un pg_dump de la base de datos, cambiar el número de versión, ejecutar docker compose pull y up -d, y revisar manualmente los flujos críticos. Si algo falla, vuelves a la versión anterior en un minuto.

¿Cuándo necesito el modo cola de n8n con Redis?

Cuando ves ejecuciones encoladas en el panel, cuando un proceso pesado bloquea los webhooks de otros flujos o cuando pasas de unos cientos a miles de ejecuciones diarias. El modo cola (EXECUTIONS_MODE=queue) separa la instancia principal de uno o varios workers usando Redis como cola de trabajos. La mayoría de tiendas con 20 o 30 flujos no lo necesitan: una sola instancia bien dimensionada sobra.

¿Merece la pena autoalojar n8n o es mejor la versión en la nube?

Autoalojar sale más barato en euros y te da control total sobre los datos, pero te obliga a dedicar tiempo cada mes a copias de seguridad, actualizaciones y vigilancia. La versión en la nube elimina ese mantenimiento a cambio de una cuota mensual mayor y de que tus datos residan en infraestructura de terceros. Si tus flujos tocan facturación, stock o envíos y nadie en tu equipo tiene responsabilidad clara sobre el servidor, la nube o un mantenimiento externalizado son la opción sensata.