n8n self-hosted vs n8n Cloud: ¿cuál elegir para automatizar?

n8n self-hosted vs n8n Cloud: la diferencia en dos frases

n8n self-hosted es instalar n8n en tu propio VPS con Docker. Un VPS (Virtual Private Server) es un servidor virtual con recursos dedicados al que tú tienes acceso raíz. Las ejecuciones son ilimitadas, los datos no salen de tu máquina y el costo mensual es el del servidor.

n8n Cloud es el servicio gestionado de n8n GmbH: pagas un plan según el volumen de ejecuciones y ellos se encargan de la infraestructura, las actualizaciones y la disponibilidad. Nunca tocas una terminal.

Ambas opciones ejecutan el mismo motor y los mismos nodos. Lo que cambia es el modelo de costos y el reparto de responsabilidades.

Comparativa de planes y precios (2026)

n8n Cloud factura por ejecuciones, no por usuarios ni por pasos. Todos los planes incluyen usuarios y workflows ilimitados. Estos son los precios publicados en n8n.io:

El detalle que más sorprende a quien contrata Cloud: al agotar la cuota de ejecuciones los workflows se detienen hasta el siguiente ciclo de facturación. No hay facturación por exceso ni periodo de gracia. Calcular el volumen antes de contratar deja de ser un ejercicio teórico.

Qué cuenta como una "ejecución" y por qué importa tanto

Una ejecución es una corrida completa de un workflow, sin importar cuántos nodos tenga ni cuántos datos mueva. Un flujo de 3 pasos y otro de 40 consumen exactamente lo mismo: uno.

Eso hace que el consumo dependa del disparador, no de la complejidad. Un workflow disparado por webhook consume una ejecución por cada llamada recibida. Un workflow con schedule consume una por cada tic del reloj, haya trabajo o no.

Casos de uso con alto volumen de ejecuciones

Los escenarios que revientan la cuota de Cloud son siempre los mismos cuatro, y son justamente los más útiles para una PyME:

1. Sincronización de inventario o precios entre sistemas. Una tienda en WooCommerce que sincroniza stock con un ERP cada 15 minutos genera 2.880 ejecuciones mensuales con un único flujo activo. Añade el flujo inverso (del ERP a la tienda) y vas por 5.760.

2. Ingesta de formularios y leads por webhook. Un formulario de contacto que recibe 100 envíos al día, más el flujo que enriquece el lead y lo mete en el CRM, más el que avisa por WhatsApp: si están separados, son tres ejecuciones por lead. 100 leads diarios se convierten en 9.000 ejecuciones al mes.

3. Vigilancia de correo o de una bandeja compartida. Un flujo que revisa un buzón IMAP cada minuto para clasificar facturas suma 43.200 ejecuciones mensuales. En Cloud eso no cabe ni en el plan Business; autoalojado es un proceso que consume unos pocos megabytes de RAM.

4. Chatbots y agentes con IA. Cada mensaje del usuario es una ejecución. Un asistente interno con 30 usuarios que escriben 20 mensajes al día son 18.000 ejecuciones al mes. Además, en Cloud los créditos de IA incluidos se agotan rápido; autoalojado pagas directamente al proveedor del modelo, sin intermediario.

Una regla práctica: si algún flujo se dispara más de una vez cada 15 minutos, o si tienes más de tres flujos activos permanentes, autoalojar ya sale más barato. Si quieres ver qué otras cargas puede compartir el mismo servidor, revisa el catálogo de aplicaciones que se pueden instalar en un VPS.

Cuánta máquina necesita n8n autoalojado

n8n arranca cómodo en 2 GB de RAM para una carga normal: decenas de workflows con disparadores por hora o por webhook, y SQLite como base de datos. Con 4 GB soportas ejecuciones concurrentes, nodos de IA y PostgreSQL en el mismo servidor sin sustos.

La instalación estándar es con Docker Compose, que permite levantar n8n y su base de datos con un solo archivo. Si es tu primera vez, la guía de Docker Compose en un VPS explica la sintaxis, y el tutorial paso a paso para instalar n8n en un VPS cubre el proceso completo con dominio y SSL:

services:
  n8n:
    # Sustituye por la versión estable que estés usando, nunca "latest"
    image: n8nio/n8n:1.XX.X
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.tudominio.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.tudominio.com/
      - GENERIC_TIMEZONE=America/Guayaquil
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

Dos detalles que marcan la diferencia frente a copiar el compose de cualquier tutorial: el puerto se publica en 127.0.0.1 para que n8n no quede expuesto directamente a internet (delante va Nginx con certificado), y la imagen está fijada a una versión concreta en lugar de latest, para que un docker compose pull accidental no te cambie de versión mayor. Si no tienes claro cuánta RAM contratar, la guía sobre cuánta RAM necesita un VPS tiene los números por tipo de carga.

Seguridad y credenciales en n8n self-hosted

Una instancia de n8n contiene las llaves de todo tu negocio digital: tokens de Google, claves de API del CRM, credenciales de la base de datos, accesos a la pasarela de pagos. Protegerla no es opcional. Estos son los cuatro puntos que hay que cubrir sí o sí:

HTTPS obligatorio, sin excepciones. n8n envía credenciales por el formulario web. Sin TLS viajan en claro. Se resuelve con Nginx como proxy inverso y un certificado gratuito de Let's Encrypt.

Autenticación: olvídate de la autenticación básica. La variable N8N_BASIC_AUTH_ACTIVE quedó eliminada a partir de n8n 1.0. Hoy la protección es la gestión de usuarios integrada: al primer acceso creas la cuenta de propietario con su contraseña, y desde ahí invitas al resto. Activa además la verificación en dos pasos para el propietario.

La clave de cifrado, fijada desde el primer arranque. n8n cifra las credenciales antes de guardarlas en la base de datos con una clave que genera sola y deja en ~/.n8n/config. Si la defines tú con N8N_ENCRYPTION_KEY antes de crear la primera credencial, podrás mover la instancia de servidor sin perder nada. Guárdala en tu gestor de contraseñas, no solo en el .env del servidor.

El servidor por debajo también cuenta. De poco sirve el TLS si el VPS acepta contraseñas por SSH. Lo mínimo razonable es autenticación por llaves SSH con las contraseñas desactivadas, firewall cerrado salvo 22, 80 y 443, y Fail2ban frenando la fuerza bruta.

Un aviso sobre el nodo Execute Command: permite ejecutar comandos del sistema operativo dentro del contenedor. Es enormemente útil y también la vía más directa a un desastre si algún día compartes la instancia con alguien en quien no confías del todo.

Backup de workflows y credenciales

Lo que hay que respaldar de n8n son tres cosas: la base de datos, la clave de cifrado y el archivo de configuración. Con esas tres, la instancia se reconstruye en otro servidor en minutos. Sin la clave, el backup de la base es un archivo cifrado que nadie puede abrir, ni tú.

Con SQLite (la opción por defecto), el respaldo correcto implica detener el contenedor un instante para que el archivo no quede a medio escribir:

docker compose stop n8n
docker run --rm -v n8n_data:/data -v $(pwd):/backup alpine \
  tar czf /backup/n8n-$(date +%F).tar.gz -C /data .
docker compose start n8n

Si el volumen de ejecuciones es alto, migra a PostgreSQL: permite respaldo en caliente con pg_dump, sin parar el servicio.

También conviene exportar los workflows en JSON, porque es un formato legible que puedes versionar en Git:

docker exec -u node n8n n8n export:workflow --all \
  --output=/home/node/.n8n/backups/workflows.json

Ese export no incluye las credenciales. Al restaurarlo en una instancia con otra clave de cifrado, los flujos aparecen completos pero con las conexiones vacías. Es la sorpresa más común en una migración mal planificada. Para automatizar el envío de los respaldos fuera del servidor, la guía de backups en un VPS cubre el cron y el destino remoto.

En n8n Cloud, los backups los gestiona el proveedor. Es una ventaja real y hay que decirlo: no tienes que pensar en esto. A cambio, tampoco tienes una copia propia si algún día decides irte.

Privacidad, licencia y control de versiones

n8n procesa datos reales del negocio: contactos, facturas, mensajes internos, registros del CRM. En Cloud, esos datos transitan y se almacenan (con retención de "insights" de 7 días en Pro y 30 en Business) en infraestructura de n8n GmbH, alojada en Europa. Autoalojado, no salen de tu VPS. Para empresas en sectores regulados o con cláusulas de confidencialidad firmadas con sus clientes, esa diferencia decide sola.

Sobre la licencia conviene ser preciso, porque circula mucha confusión: n8n no es open source en el sentido estricto de la OSI. Se distribuye bajo la Sustainable Use License, una licencia fair-code que permite usarlo gratis para ti o para tu empresa, modificarlo y hasta cobrar por construir workflows para clientes. Lo que prohíbe es empaquetar n8n y venderlo como servicio a terceros. Para el 99% de los usos internos, es indistinguible de ser libre.

En cuanto a versiones: Cloud actualiza cuando n8n lo decide, y un cambio de comportamiento en un nodo puede romper un flujo en producción sin previo aviso. Autoalojado fijas la versión, la mantienes meses y actualizas después de probar. El mismo patrón de control que se busca al autoalojar aplicaciones en 2026.

Cuándo elegir cada opción