n8n self-hosted en Cantabria: cuándo conviene tener tu propio servidor de automatización

César · Publicado el 28 mayo 2026 · 13 min de lectura

n8n Cloud vs n8n Self-hosted

n8n ofrece dos formas de usarlo: el servicio gestionado en su cloud (n8n.io) o instalarlo tú mismo en un servidor que controles. La diferencia de fondo no es solo técnica; afecta a quién toca tus datos, cuánto pagas a escala y cuánto control tienes sobre la infraestructura.

n8n Cloud es el camino de menor resistencia inicial. Te registras, pagas la suscripción mensual y en diez minutos tienes n8n funcionando sin haber tocado un servidor. El plan Starter (en torno a 20 €/mes a fecha 2026) incluye un número limitado de workflows activos y ejecuciones mensuales. Si superas esos límites subes al plan Pro, que puede estar entre 50 y 120 €/mes dependiendo del uso. Los datos se procesan en la infraestructura de n8n; sí, ofrecen región EU, pero siguen siendo servidores gestionados por un tercero fuera de tu control directo.

n8n Self-hosted es instalar la misma herramienta de código abierto en un VPS que tú contratas y administras. Tus datos no salen de ese servidor. El coste de la licencia es cero (n8n es open source en su versión community). Pagas el VPS, los backups y el tiempo de mantenimiento. A partir de cierto volumen de uso, la diferencia de coste mensual es muy significativa.

La pregunta que importa

La elección no es "¿cuál es mejor?", sino "¿cuál encaja con mi situación?". El cloud es mejor para arrancar rápido con bajo volumen. Self-hosted gana cuando el volumen crece, los datos son sensibles o necesitas un control que el cloud no puede darte. Las siguientes secciones te ayudan a decidir sin rodeos.

Cuándo conviene self-hosted

Hay cinco escenarios en los que self-hosted deja de ser "la opción técnica" y se convierte en la opción obvia:

1. Manejas datos sensibles

Gestorías fiscales, despachos de abogados, clínicas, consultas de RRHH, empresas con datos financieros de clientes. En todos estos casos, que los workflows procesen información personal o confidencial pasando por servidores de un tercero complica el cumplimiento del RGPD y puede generar problemas con clientes que exigen soberanía sobre sus datos. Con self-hosted en un datacenter alemán o finlandés de Hetzner, los datos nunca salen de la UE y nunca salen de tu infraestructura. Es el argumento que más peso tiene en una auditoría o cuando un cliente grande te pregunta dónde se tratan sus datos.

2. Superas las 5.000 ejecuciones/mes

El punto de inflexión en el que self-hosted empieza a ser más barato que cloud está alrededor de ese volumen. Si tienes workflows de notificaciones, sincronización de datos, reportes automáticos o integraciones de e-commerce activos todo el día, es fácil llegar a 10.000-50.000 ejecuciones mensuales. En cloud, eso significa subir de plan. En self-hosted, el coste del VPS es el mismo independientemente de cuántas veces se ejecuten tus workflows.

3. Workflows complejos con muchas operaciones internas

n8n Cloud factura (o limita) por ejecución de workflow, no por número de nodos dentro de un workflow. Pero workflows muy largos con bucles, procesamiento de listas o llamadas encadenadas a APIs pueden agotarte los límites del plan más rápido de lo esperado. En self-hosted no hay ese techo artificial.

4. Necesitas nodos personalizados o integraciones internas

Si tu empresa usa software a medida, un ERP interno o quieres conectar con sistemas que no tienen conector oficial en n8n, puedes desarrollar tus propios nodos y cargarlos en una instalación self-hosted. En el cloud de n8n no puedes instalar extensiones propias. Para muchas PYMEs de Cantabria con software sectorial específico (Sage Despachos, A3, software de hostelería propietario, sistemas de gestión de obras), esto es determinante.

5. Requisito de soberanía o cumplimiento sectorial

Sector público, servicios vinculados a defensa, sanidad con historia clínica, o cualquier contrato donde el pliego técnico exige que los datos se traten en infraestructura propia o bajo control directo. El cloud de un tercero, aunque sea EU, generalmente no pasa ese filtro.

Cuándo NO conviene self-hosted

La opción self-hosted tiene un coste real que a veces se subestima: tiempo de mantenimiento, responsabilidad de backups y actualizaciones, y capacidad técnica mínima para reaccionar si algo falla. Hay situaciones en las que cloud es la decisión correcta:

• Volumen muy bajo y workflows simples. Si ejecutas menos de 500 workflows/mes con flujos de 3-4 nodos, el cloud Starter te cubre y no tiene sentido mantener infraestructura por eso.
• No hay nadie con perfil técnico mínimo. Self-hosted requiere que alguien sepa acceder a un servidor por SSH, entender un fichero docker-compose.yml básico y saber qué hacer si el contenedor se cae. No es desarrollo avanzado, pero sí es un umbral mínimo. Si en tu empresa o en tu equipo nadie llega a ese umbral y no tienes soporte externo, el cloud es más seguro.
• Time-to-value urgente. Si necesitas tener algo funcionando esta semana para demostrar un caso de uso, el cloud te da eso sin fricción. Puedes migrar a self-hosted después cuando el proyecto esté validado.
• Aversión completa al mantenimiento. Self-hosted bien configurado requiere unas pocas horas al mes (actualizaciones, revisión de backups, alertas). Si ese tiempo o esa responsabilidad son inaceptables para el negocio, el cloud es la opción honesta.

Stack recomendado para PYME (Hetzner + Coolify + Docker)

Este es el stack que recomiendo y despliego habitualmente para PYMEs en Cantabria que quieren self-hosted sin complicarse la vida innecesariamente:

VPS: Hetzner Cloud (Alemania o Finlandia)

Hetzner es el proveedor que mejor ratio precio/rendimiento/ubicación ofrece para este caso de uso. Datacenter en Nuremberg, Falkenstein (Alemania) o Helsinki (Finlandia), todo dentro de la UE y con certificaciones de cumplimiento sólidas. Para n8n con uso medio de una PYME, el modelo CX22 (2 vCPU, 4 GB RAM) es suficiente para empezar, a unos 5 €/mes. Si el volumen crece o ejecutas workflows pesados con procesamiento de documentos, el CX32 (4 vCPU, 8 GB RAM) a unos 12 €/mes da bastante margen.

El punto clave: Hetzner tiene DSGVO/RGPD bien cubierto, DPA disponible y precios estables. No es AWS ni GCP; es un proveedor europeo sin la complejidad de facturación variable de los grandes clouds.

Capa de despliegue: Coolify

Coolify es una plataforma open source de auto-despliegue que actúa como interfaz amigable sobre Docker. En lugar de gestionar contenedores directamente por línea de comandos, tienes un panel web desde el que desplegar, actualizar y monitorizar tus aplicaciones. Es el punto medio entre "instalar n8n a mano con Docker" y "usar un PaaS caro". Coolify gestiona también los certificados HTTPS automáticamente (vía Let's Encrypt) y facilita enormemente las actualizaciones de n8n.

Docker con imagen oficial n8nio/n8n

La imagen oficial de n8n en Docker Hub (n8nio/n8n) es el método de despliegue recomendado para self-hosted. El docker-compose.yml estándar levanta n8n y la base de datos en contenedores aislados. Coolify simplifica esto hasta el punto de que el despliegue inicial se puede completar en menos de 30 minutos por alguien con conocimientos básicos.

Base de datos: PostgreSQL (no SQLite)

n8n puede funcionar con SQLite por defecto, pero para cualquier uso en producción debes usar PostgreSQL. SQLite tiene problemas con escrituras concurrentes, no escala bien y complica los backups. PostgreSQL es robusto, soporta volúmenes altos y tiene herramientas de backup maduras. Coolify facilita el despliegue de un contenedor PostgreSQL en el mismo servidor.

Reverse proxy: Caddy o Traefik

Ambos gestionan el HTTPS automático con Let's Encrypt y enrutan el tráfico hacia el contenedor de n8n. Coolify incluye Caddy como proxy por defecto, lo que simplifica la configuración. Si ya conoces Traefik o tienes otros servicios en el servidor, también funciona perfectamente.

Backups: S3 europeo

Para los backups de la base de datos PostgreSQL, las dos opciones más usadas en este stack son Cloudflare R2 (compatible con S3, sin coste de egreso, región EU disponible) y Hetzner Storage Box (almacenamiento en datacenter alemán, muy económico). Los backups deben ser diarios, encriptados y con retención mínima de 30 días. Un script de cron o una herramienta como pg_dumpall automatiza el volcado y la subida.

Monitorización: Uptime Kuma o Healthchecks.io

Uptime Kuma es un monitor de disponibilidad open source que puedes desplegar en el mismo servidor (o en uno separado) y que te avisa por Telegram, email o Slack si n8n deja de responder. Healthchecks.io complementa esto monitorizando que los workflows críticos se ejecutan con la cadencia esperada, no solo que el servidor responde. Ambas herramientas cuestan prácticamente nada y evitan que un fallo silencioso pase desapercibido durante días.

Seguridad, backups y actualizaciones

Self-hosted implica que la responsabilidad de la seguridad es tuya. No es una razón para no hacerlo; es una razón para hacerlo bien desde el principio. La lista de mínimos que aplico en todos los despliegues:

HTTPS obligatorio desde el día uno

Ninguna instancia de n8n debería ser accesible por HTTP plano, ni siquiera en fase de pruebas. Caddy y Traefik gestionan el certificado Let's Encrypt de forma automática; no hay excusa para no tenerlo activado desde el primer acceso.

2FA en n8n

n8n tiene autenticación de doble factor disponible en la configuración de usuario. Activarlo es obligatorio para cualquier cuenta que acceda a la instancia, especialmente si el panel de n8n es accesible desde internet. Los workflows de automatización suelen tener acceso a credenciales de servicios críticos; una cuenta comprometida es un problema serio.

Restricción de acceso por IP o VPN

Si es viable operativamente, restringir el acceso al panel de n8n a las IPs de la oficina o a través de VPN es una capa de protección que elimina prácticamente todos los ataques de fuerza bruta sobre el login. En Hetzner, los Firewall rules del panel permiten hacer esto en cinco minutos sin tocar el servidor.

Backups encriptados con retención mínima de 30 días

Un backup diario de PostgreSQL encriptado antes de subirse al almacenamiento externo. La encriptación importa: si el bucket S3 de backup quedara expuesto, los datos de los workflows y credenciales almacenadas en n8n no serían legibles. La retención de 30 días permite recuperarse de errores que no se detectan inmediatamente.

Plan de recuperación documentado

"Tenemos backups" no es suficiente si nadie sabe restaurarlos. El plan de recuperación debe estar escrito, debe indicar cuánto tiempo tarda la restauración y debe haberse probado al menos una vez. Esto es especialmente relevante si n8n gestiona procesos críticos del negocio.

Actualizaciones mensuales

n8n tiene un ciclo de releases muy activo, con versiones nuevas cada pocas semanas. No es necesario actualizar cada vez que sale una versión, pero sí mantener un ritmo mensual. Las actualizaciones con Coolify se reducen a cambiar el tag de la imagen Docker y hacer click en "Deploy". Antes de actualizar, siempre verificar el changelog por si hay cambios que rompan workflows existentes.

Monitorización de fallos de workflow

n8n permite configurar alertas cuando un workflow falla. Conectar esas alertas a un canal de Slack o a un email del equipo técnico es básico. Un workflow que falla en silencio puede significar que durante días no se están enviando recordatorios, no se están procesando pedidos o no se están generando informes.

Coste real comparado

Los números concretos, sin redondear al alza para hacer la comparativa más favorable:

Coste de infraestructura self-hosted

• VPS Hetzner CX22 (2 vCPU, 4 GB RAM): ~5 €/mes. Suficiente para volumen medio.
• VPS Hetzner CX32 (4 vCPU, 8 GB RAM): ~12 €/mes. Recomendable si hay workflows pesados o varios proyectos en paralelo.
• Backup storage (Hetzner Storage Box o Cloudflare R2): 3-8 €/mes según volumen de datos.
• Dominio + DNS (si se usa subdominio propio): ~12 €/año, prácticamente despreciable.
• Total infraestructura típica: 15-25 €/mes con CX22, hasta 40-50 €/mes con CX32 más backups y extras de monitorización.

Coste de n8n Cloud

• Plan Starter: en torno a 20 €/mes, con límite de workflows activos y ejecuciones mensuales (el límite exacto varía; consultar la página de precios actual de n8n.io).
• Plan Pro: 50-120 €/mes según el volumen de workflows activos y ejecuciones.
• Sin coste de mantenimiento de infraestructura, pero sin control sobre los datos.

La comparativa real

Para un volumen bajo (menos de 2.000 ejecuciones/mes, pocos workflows activos), n8n Cloud Starter y self-hosted en CX22 tienen costes similares o incluso cloud es ligeramente más barato si sumas el tiempo de setup. La diferencia empieza a ser relevante a partir de 5.000 ejecuciones/mes, donde cloud empieza a empujar hacia el plan Pro. Con volúmenes de 20.000-50.000 ejecuciones mensuales, self-hosted puede ser 3 a 5 veces más barato que el equivalente en cloud.

El coste de API de IA (ChatGPT, Claude) es idéntico en ambos casos: lo paga quien llama a la API, sea desde cloud o desde self-hosted.

Cómo empezar sin meterte en líos

La pregunta habitual es: "¿puedo montar esto yo solo?". Depende de tu nivel técnico y de cuánto tiempo quieres invertir en aprenderlo frente a cuánto quieres que simplemente funcione.

Si tienes alguien técnico en el equipo

El proceso de despliegue con Hetzner + Coolify + Docker está documentado y no es especialmente complicado si se conoce Linux a nivel básico. El tiempo estimado para tener n8n funcionando en producción (con HTTPS, PostgreSQL, backups configurados y 2FA activo) es de 4-8 horas la primera vez. Hay guías detalladas en la documentación oficial de n8n y en la comunidad de Coolify. El mantenimiento posterior es de 1-3 horas al mes.

Si no tienes perfil técnico interno

La opción realista es contratar el setup como servicio llave en mano. Esto incluye el despliegue del servidor, la instalación y configuración de n8n con todo el stack (PostgreSQL, backups, HTTPS, monitorización, 2FA), y la documentación de cómo acceder y qué hacer si algo falla. El coste de ese setup suele estar entre 500 y 1.500 €, dependiendo de la complejidad.

Después del setup, el mantenimiento mensual (actualizaciones, revisión de backups, soporte ante incidencias) puede contratarse como servicio recurrente o gestionarse internamente si alguien adquiere el conocimiento básico. En cualquier caso, ese coste de mantenimiento está muy por debajo de lo que se ahorra frente al plan Pro de n8n Cloud a escala.

La decisión práctica

Si estás arrancando y quieres validar si n8n funciona para tus procesos: empieza en cloud. Es más rápido y te permite centrarte en diseñar los workflows sin preocuparte de la infraestructura. Cuando el proyecto esté validado y el volumen empiece a crecer, o cuando tengas claro que vas a manejar datos sensibles de forma continuada, es el momento de migrar a self-hosted. La migración de n8n Cloud a self-hosted no es trivial (hay que exportar los workflows e importarlos, y reconfigurar las credenciales), pero tampoco es dramática si se hace con tiempo.

Lo que sí te recomendaría evitar es empezar en cloud con datos muy sensibles pensando "ya migraré cuando tenga tiempo". Ese tiempo casi nunca llega, y mientras tanto los datos de tus clientes están pasando por infraestructura que no controlas.