n8n self-hosted: guía técnica completa para instalar, escalar y operar tu instancia (2026)

30 de abril de 2026
Netbrain

TL;DR técnico — n8n self-hosted te da control total sobre tu motor de automatización: workflows ilimitados, ejecuciones ilimitadas, integraciones sin caja negra, datos en tu infraestructura. Esta guía cubre la instalación con Docker + Postgres, configuración productiva (queue mode con Redis, workers horizontales), nodos avanzados, agentes IA con LangChain integrados, hardening de seguridad, alta disponibilidad y la comparativa real frente a n8n Cloud, Zapier y Make. Si vas a poner n8n a trabajar para tu empresa, este es el documento que te ahorra dos semanas de prueba y error.

Qué es n8n self-hosted (y en qué se diferencia de n8n Cloud)

n8n es un motor de automatización de workflows fair-code (licencia Sustainable Use) que permite conectar APIs, bases de datos, archivos y servicios entre sí mediante un editor visual basado en nodos. La gran diferencia con la mayoría de competidores es que n8n se puede desplegar en tu propia infraestructura y, en su modalidad self-hosted, no aplica límites de ejecuciones, ni de workflows activos, ni de pasos por workflow.

Aspecto	n8n Cloud	n8n self-hosted
Hosting	Gestionado por n8n.io	Tu servidor / Kubernetes / VPS
Datos	En infraestructura de n8n	En tu infraestructura
Ejecuciones	Plan-limited (ej. 5.000-50.000/mes)	Ilimitadas
Workflows activos	Plan-limited	Ilimitados
Custom nodes	Limitado	Sin restricción (incluyendo nodos privados)
AI Agents (LangChain)	Sí (planes superiores)	Sí, sin límite
Coste mensual	Desde 20 €/mes a varios cientos	Desde ~5 €/mes (infraestructura)
Cumplimiento (RGPD, ISO)	Depende del plan	Control directo del compliance
SSO / SAML	Plan Enterprise	Plan Enterprise license (también self-hosted)

Para una pyme con 10-50 ejecuciones/día, la diferencia económica entre Cloud y self-hosted es marginal. El argumento real para self-hosted suele ser gobierno del dato (datos sensibles que no salen de la red corporativa), integraciones internas (ERP on-premise, BBDD detrás del firewall) y personalización profunda (nodos custom propios, encriptación con KMS propio).

Cuándo elegir n8n self-hosted (y cuándo no)

Elige self-hosted si:

Tu workflow toca datos personales o financieros y tu DPO requiere data residency en tu propia infraestructura.
Necesitas integrar sistemas internos (ERP SAP/Dynamics on-premise, BD interna PostgreSQL/Oracle, NAS, file shares SMB) que no son accesibles desde Internet.
Tienes volumen alto de ejecuciones (10.000+/mes) y el plan Cloud equivalente sale caro.
Necesitas custom nodes propios con lógica de negocio o credenciales corporativas.
Quieres una arquitectura HA con varios workers, queue mode y monitorización propia.

Quédate en Cloud si:

Estás en POC / prueba inicial, sin equipo de IT que mantenga la infraestructura.
Tu volumen es bajo y el plan Starter / Pro Cloud te basta.
No quieres operar Postgres, Redis, certificados TLS, backups, ni monitoreo.
No necesitas SSO ni custom nodes.

Nota práctica: muchos proyectos empiezan en Cloud para validar el caso de uso y migran a self-hosted cuando alcanzan ~5.000 ejecuciones/mes y/o cuando se identifica una integración con un sistema interno. La migración no es trivial: los workflows se exportan en JSON, las credenciales hay que recrearlas. Plan from day one si vas en serio.

Requisitos de infraestructura

Mínimo viable (entornos PoC y bajo volumen)

1 vCPU, 2 GB RAM, 20 GB disco
Sistema operativo Linux (Debian 12, Ubuntu 22.04 LTS, Rocky Linux 9)
Docker 24+ y Docker Compose v2
Acceso entrante 443/tcp (HTTPS) si vas a exponer webhooks
Dominio con certificado TLS válido (Let’s Encrypt vía Caddy/Traefik/Nginx)

Producción enterprise (workers separados, alta disponibilidad)

1 nodo «main» + N workers (cada worker en VM o pod separado)
Postgres en alta disponibilidad (Patroni, RDS Multi-AZ, etc.)
Redis en cluster o Sentinel
Almacenamiento de binarios externo (S3, MinIO) si manejas archivos grandes
Kubernetes con el Helm chart oficial es el camino estándar

Instalación paso a paso con Docker Compose

Este es el deployment de referencia que recomendamos como punto de partida. Cubre Postgres + n8n + Redis + Caddy con TLS automático.

1. Estructura de archivos

/opt/n8n/
├── docker-compose.yml
├── .env
├── caddy/
│   └── Caddyfile
└── data/                  # creado automáticamente
    ├── n8n/
    ├── postgres/
    └── caddy/

2. `.env` (mantener fuera de git, perms 600)

# Dominio público
N8N_DOMAIN=n8n.tudominio.com

# Postgres
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=cambiar-este-password-largo-y-aleatorio
POSTGRES_NON_ROOT_USER=n8n_app
POSTGRES_NON_ROOT_PASSWORD=otro-password-diferente

# n8n
N8N_ENCRYPTION_KEY=genera-32-bytes-base64-con-openssl-rand-base64-32
N8N_USER_MANAGEMENT_JWT_SECRET=otro-secret-distinto-de-32-bytes
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379

# Webhook público (si lo expones)
WEBHOOK_URL=https://n8n.tudominio.com/

# Email para Let's Encrypt
LETSENCRYPT_EMAIL=admin@tudominio.com

Crítico: la N8N_ENCRYPTION_KEY cifra todas las credenciales almacenadas en BD. Si la pierdes, las credenciales son irrecuperables. Guárdala en tu gestor de secretos corporativo (Vaultwarden, Bitwarden, 1Password, AWS Secrets Manager).

3. `docker-compose.yml`

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_NON_ROOT_USER: ${POSTGRES_NON_ROOT_USER}
      POSTGRES_NON_ROOT_PASSWORD: ${POSTGRES_NON_ROOT_PASSWORD}
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
      - ./init-data.sh:/docker-entrypoint-initdb.d/init-data.sh
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -h localhost -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 10

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - ./data/redis:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_NON_ROOT_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_NON_ROOT_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_USER_MANAGEMENT_JWT_SECRET: ${N8N_USER_MANAGEMENT_JWT_SECRET}
      N8N_HOST: ${N8N_DOMAIN}
      N8N_PROTOCOL: https
      WEBHOOK_URL: ${WEBHOOK_URL}
      EXECUTIONS_MODE: ${EXECUTIONS_MODE}
      QUEUE_BULL_REDIS_HOST: ${QUEUE_BULL_REDIS_HOST}
      QUEUE_BULL_REDIS_PORT: ${QUEUE_BULL_REDIS_PORT}
      GENERIC_TIMEZONE: Europe/Madrid
      TZ: Europe/Madrid
      N8N_LOG_LEVEL: info
      N8N_DIAGNOSTICS_ENABLED: "false"
      N8N_VERSION_NOTIFICATIONS_ENABLED: "false"
    volumes:
      - ./data/n8n:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_NON_ROOT_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_NON_ROOT_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_USER_MANAGEMENT_JWT_SECRET: ${N8N_USER_MANAGEMENT_JWT_SECRET}
      QUEUE_BULL_REDIS_HOST: ${QUEUE_BULL_REDIS_HOST}
      QUEUE_BULL_REDIS_PORT: ${QUEUE_BULL_REDIS_PORT}
      GENERIC_TIMEZONE: Europe/Madrid
    volumes:
      - ./data/n8n:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    deploy:
      replicas: 2

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile
      - ./data/caddy:/data
    environment:
      LETSENCRYPT_EMAIL: ${LETSENCRYPT_EMAIL}

4. `caddy/Caddyfile`

{$N8N_DOMAIN} {
    reverse_proxy n8n:5678
    encode zstd gzip
    tls {$LETSENCRYPT_EMAIL}
    header {
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
        X-Content-Type-Options nosniff
        X-Frame-Options DENY
        Referrer-Policy strict-origin-when-cross-origin
    }
}

5. `init-data.sh` (Postgres bootstrap del usuario aplicación)

#!/bin/bash
set -e
psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" --dbname "$POSTGRES_DB" <<-EOSQL
    CREATE USER ${POSTGRES_NON_ROOT_USER} WITH PASSWORD '${POSTGRES_NON_ROOT_PASSWORD}';
    GRANT ALL PRIVILEGES ON DATABASE ${POSTGRES_DB} TO ${POSTGRES_NON_ROOT_USER};
    GRANT CREATE ON SCHEMA public TO ${POSTGRES_NON_ROOT_USER};
EOSQL

6. Levantar la pila

chmod 600 .env init-data.sh
chmod +x init-data.sh
docker compose up -d
docker compose logs -f n8n

A los 30-60 segundos, n8n estará disponible en https://n8n.tudominio.com/. La primera visita pide crear el usuario owner.

Configuración productiva: variables de entorno clave

Estas son las env vars que diferencian un n8n «que funciona» de un n8n «listo para producción»:

Variable	Recomendado	Por qué
`EXECUTIONS_MODE`	`queue`	Habilita el modo cola con Redis. Sin esto no puedes escalar workers.
`EXECUTIONS_DATA_PRUNE`	`true`	Borra ejecuciones viejas automáticamente
`EXECUTIONS_DATA_MAX_AGE`	`336` (14 días)	Retención de logs de ejecución (en horas)
`EXECUTIONS_DATA_PRUNE_MAX_COUNT`	`50000`	Límite duro de ejecuciones almacenadas
`N8N_LOG_LEVEL`	`info` (prod) / `debug` (troubleshooting)	Verbosidad de logs
`N8N_LOG_OUTPUT`	`console,file`	Loguear también a fichero para análisis
`N8N_METRICS`	`true`	Expone `/metrics` para Prometheus
`N8N_PAYLOAD_SIZE_MAX`	`16` (MB)	Sube si tus webhooks reciben payloads grandes
`N8N_DEFAULT_BINARY_DATA_MODE`	`filesystem` o `s3`	Para evitar inflar la BD con binarios
`N8N_BLOCK_ENV_ACCESS_IN_NODE`	`true`	Bloquea que workflows lean env vars del host (seguridad)
`N8N_DIAGNOSTICS_ENABLED`	`false`	Desactiva telemetría a n8n.io (privacidad)
`N8N_HIRING_BANNER_ENABLED`	`false`	Quita banner de «estamos contratando»
`N8N_PERSONALIZATION_ENABLED`	`false`	Desactiva onboarding inicial repetitivo

Capacidades reales de n8n: qué se puede hacer

n8n tiene 400+ integraciones nativas y, donde no hay nodo, los nodos HTTP Request y Code cubren prácticamente cualquier caso. Estas son las grandes familias de uso:

1. Triggers (cómo arrancan los workflows)

Webhook Trigger — recibe POST/GET de cualquier sistema externo. Soporta autenticación basic/header/JWT. URL pública o privada.
Schedule Trigger — cron expression. «Todos los lunes a las 9:00», «cada 15 minutos en horario laboral».
Email Trigger (IMAP) — escucha buzón corporativo, dispara workflow al llegar email matching reglas.
App-specific triggers — Stripe (payment_succeeded), Shopify (orders/create), GitHub (push), Slack (mention), Telegram, WhatsApp Business, etc.
Manual Trigger — para ejecutar bajo demanda desde el editor o vía API.
Error Trigger — workflow que se lanza cuando otro falla (alertas centralizadas).
Form Trigger — n8n genera un formulario web público que dispara el workflow al ser enviado.
Chat Trigger — interfaz tipo chatbot embebida (combinable con AI Agent).

2. Bases de datos y storage

Sistema	Operaciones soportadas
PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, Oracle	SELECT, INSERT, UPDATE, DELETE, executeQuery con parámetros bindeados
MongoDB	find, insert, update, aggregate
Redis	get/set/incr/expire/publish
Snowflake, BigQuery, ClickHouse	execute query, batch insert
S3, MinIO, Google Cloud Storage, Azure Blob	upload, download, list, presigned URL
FTP, SFTP, SMB	get/put/list/delete
Airtable, Notion, Coda, Google Sheets, Microsoft Excel	CRUD sobre filas

3. APIs y comunicación

HTTP Request node con todas las opciones reales: oauth2 (auth code, client credentials, password), API key, basic, custom headers, retry con backoff exponencial, paginación automática (offset/cursor/link header), timeout configurable, certificados cliente.
GraphQL node nativo.
Webhook Response node — devolver respuesta sincrónica al caller.
Wait node — pausar workflow hasta nuevo webhook (patrón human-in-the-loop).
Respond to Webhook — control fino del status code, body y headers de respuesta.

4. Lógica y transformación de datos

Code node con JavaScript (V8) y Python (vía Pyodide).
Set / Edit Fields — manipulación declarativa de JSON.
IF, Switch — branching condicional.
Merge — joins entre arrays (append, by index, by key, multiplex).
Loop Over Items — iteración con batch size configurable.
Item Lists — split, aggregate, sort, limit, remove duplicates.
Date & Time — parsing, formato, zona horaria, deltas.
Crypto — hashing (sha256, hmac), generación de UUIDs, signing JWT.
XML ↔ JSON — conversión bidireccional.
Compression — zip/gzip dentro del workflow.
Spreadsheet File — leer/escribir XLSX, CSV, ODS desde memoria sin escribir a disco.

5. Integraciones empresariales (selección B2B)

CRM: HubSpot, Salesforce, Pipedrive, Microsoft Dynamics 365, Zoho CRM, ActiveCampaign, Brevo (ex-Sendinblue), Mautic.
ERP / Facturación: Holded, FacturaScripts (vía API), QuickBooks, Xero, ContaPlus (vía DB), SAP (vía OData / RFC con HTTP Request).
eCommerce: Shopify, WooCommerce, PrestaShop, Magento, BigCommerce.
Comunicación: Slack, Microsoft Teams, Discord, Telegram, WhatsApp Business API (Meta), SMS via Twilio/MessageBird, email via SMTP/SendGrid/Mailgun/SES.
Project management: Jira, Asana, Trello, ClickUp, Monday, Notion, Linear, GitHub Projects.
Almacenamiento documental: Google Drive, OneDrive, Dropbox, Box, NextCloud.
Identidad: LDAP/AD via HTTP, Okta, Auth0, Azure AD, JWT issuance.

6. AI Agents y LLMs (la diferencia 2024-2026)

Desde 2024, n8n integra de forma nativa LangChain y soporta agentes IA con herramientas. Los nodos clave son:

AI Agent — agente con tool-calling. Le pasas un prompt + lista de tools (otros workflows o nodos) y el modelo decide cuándo invocarlos.
OpenAI node — chat completions, embeddings, image generation, audio transcription (whisper), function calling, structured outputs.
Anthropic node — Claude Sonnet/Opus, vision, tool use.
Google Gemini node — texto, imagen, video.
Ollama node — modelos locales (Llama 3, Mistral, Qwen, DeepSeek) self-hosted en la misma red.
Vector Store nodes — Pinecone, Qdrant, Weaviate, Postgres con pgvector, Supabase, MongoDB Atlas Vector Search.
Memory — Buffer Memory, Window Memory, Postgres Memory, Redis Memory para conversaciones persistentes.
Embeddings — OpenAI, Cohere, HuggingFace, Ollama (locales).
Document Loaders — PDF, Word, web scraping, GitHub repo, Notion, S3.
Text Splitters — recursive, character, token-aware.

Ejemplo concreto: clasificación automática de tickets de soporte. Trigger Email → carga PDFs adjuntos → embeddings con Ollama → similarity search en Qdrant contra base de conocimiento → AI Agent (Claude) decide: responder con plantilla, escalar a humano via Slack, o crear ticket en Jira. Todo el flujo es un workflow n8n, sin código custom, ejecuta en self-hosted, y el coste por ticket es marginal (<0,01 €) si usas Ollama local para embeddings.

7. Custom nodes (cuando los 400+ no bastan)

Si necesitas un nodo para un sistema propietario o quieres encapsular lógica reutilizable:

TypeScript con SDK @n8n/node-cli (anteriormente n8n-node-dev).
Estructura: MyNode.node.ts (definición + execute) + MyNode.credentials.ts (auth) + package.json.
Build local con pnpm build, instalación en ~/.n8n/custom/.
Versionado privado: publicar como paquete npm en registry interno (Verdaccio, GitHub Packages).

Hemos publicado nodos custom para clientes contra ERPs internos en menos de un día de trabajo desde el SDK.

Modo `queue`: por qué es obligatorio para producción

Por defecto n8n ejecuta workflows en el mismo proceso que sirve la UI (modo regular). Con volumen real, esto se atasca: un workflow pesado bloquea la UI y otros workflows.

EXECUTIONS_MODE=queue separa la responsabilidad:

┌──────────┐    ┌────────┐    ┌───────────┐
│  n8n     │───▶│ Redis  │───▶│ n8n-worker│ × N
│  main    │    │ (Bull) │    │           │
│ (UI+API) │    └────────┘    └───────────┘
└──────────┘
       │                              │
       └──────────┬───────────────────┘
                  ▼
            ┌──────────┐
            │ Postgres │
            └──────────┘

Main: editor, API REST, webhook receiver. Encola jobs.
Workers: procesan los jobs. Escalables horizontalmente (docker compose up -d --scale n8n-worker=4).
Redis: cola Bull con persistencia.
Postgres: estado canónico (workflows, credentials, executions, users).

Beneficios reales medidos en clientes:
– Ejecuciones simultáneas pasan de ~5 (limitado por hilos) a 50-100 (limitado por workers × concurrency).
– La UI permanece fluida aunque haya 500 ejecuciones en cola.
– Failover: si un worker cae, los otros recogen los jobs pendientes automáticamente.

N8N_CONCURRENCY_PRODUCTION_LIMIT (por worker) por defecto es 10. Si tus workflows hacen poco I/O y mucho CPU (transformaciones grandes, parseo XML), bájalo. Si es I/O-bound (HTTP, BD), súbelo a 25-50.

Seguridad: hardening de un n8n self-hosted

Capas mínimas obligatorias

HTTPS con certificado válido. Caddy/Traefik te lo dan automático con Let’s Encrypt. Sin TLS, las cookies de sesión y los webhooks viajan en claro.
N8N_ENCRYPTION_KEY rotada y custodiada. Sin ella, las credenciales en BD están comprometidas. No la dejes en un .env versionado en git.
User Management activo (N8N_USER_MANAGEMENT_DISABLED=false, default). Roles disponibles: Owner, Admin, Member.
Reverse proxy con headers de seguridad: HSTS, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy.
Firewall: solo 443/tcp expuesto a Internet. SSH solo desde IPs whitelisted o vía VPN/bastion.
N8N_BLOCK_ENV_ACCESS_IN_NODE=true — impide que workflows lean variables de entorno del host (un usuario malicioso podría exfiltrar secrets con un Code node).
Sin Code node para usuarios no-Admin si manejas dato sensible — desactivar N8N_CODE_NODE_DEFAULT_LANGUAGE solo lectura por rol Member.

Hardening adicional (compliance / RGPD-ready)

Audit log: enviar /rest/audit (Enterprise) o tail de logs a SIEM (Wazuh, Graylog).
Backups encriptados: snapshot Postgres con pg_dump | gpg --encrypt + replicación off-site (S3 + bucket lifecycle a Glacier).
Secrets externos: N8N_EXTERNAL_SECRETS_* permite leer credenciales desde HashiCorp Vault, AWS Secrets Manager, Infisical en lugar de almacenar en BD.
SSO/SAML (licencia Enterprise) — login corporativo con Azure AD, Okta, Google Workspace.
MFA por usuario — WebAuthn / TOTP nativos.
Network policies si despliegas en Kubernetes — solo permitir egress a APIs de las integraciones legítimas.
Rotation de N8N_USER_MANAGEMENT_JWT_SECRET cada 90 días — invalida sesiones activas.

Riesgos comunes que vemos en clientes

Credenciales OAuth con scopes excesivos (admin completo a Google Workspace cuando solo necesitabas Sheets read-only).
Webhooks públicos sin autenticación HMAC ni IP allowlist — cualquiera puede dispararlos.
Workflows con datos PII en logs de ejecución — desactivar EXECUTIONS_DATA_SAVE_ON_SUCCESS=none o =manual para flujos sensibles.
BD Postgres expuesta sin firewall (puerto 5432 abierto). Solo el contenedor n8n debe poder llegar.

Backup y recuperación

n8n almacena estado en dos sitios:

Postgres — workflows, credenciales (cifradas con N8N_ENCRYPTION_KEY), ejecuciones, usuarios.
Volumen ~/.n8n — config con identifiers, nodes/ con custom nodes instalados.

Backup mínimo viable diario:

#!/bin/bash
DATE=$(date +%F)
docker compose exec -T postgres pg_dump -U n8n n8n | gzip > /backups/n8n-db-${DATE}.sql.gz
tar czf /backups/n8n-files-${DATE}.tar.gz ./data/n8n
# Sincronizar a S3/MinIO
aws s3 sync /backups s3://mi-bucket-backup/n8n/ --storage-class STANDARD_IA
# Retención local 7 días
find /backups -name "n8n-*" -mtime +7 -delete

Restauración probada cada trimestre — un backup que no se ha probado es Schrödinger’s backup. En entornos Enterprise montamos un staging que se restaura desde producción cada noche y tira tests de smoke automáticos.

Para granularidad por workflow: la API REST GET /rest/workflows exporta JSONs versionables en git. Lo recomendamos para flujos críticos: el repo de workflows es la fuente de verdad y el deploy a n8n es vía CI/CD.

Costes reales: self-hosted vs Cloud vs Zapier vs Make (2026)

Tomemos un escenario realista pyme: 20 workflows activos, 5.000 ejecuciones/mes, 5 usuarios concurrentes.

Solución	Plan	Coste mensual	Cuello principal
n8n self-hosted	VPS Hetzner CX22 (2 vCPU, 4 GB) + dominio + backup S3	~6 €	Tienes que operarlo (1-2h/mes)
n8n Cloud Pro	n8n Cloud Pro 10k ejec	50 €	Límite ejecuciones, sin custom nodes
Zapier Professional	2.000 tasks/mes (5x menos que n8n equiv)	73 €	Limitación drástica de tasks
Make (ex-Integromat) Pro	10.000 ops/mes	16 €	Operaciones cuentan distinto, suele dar para menos
Workato	Plan PYME	500 €	Capacidad mucho mayor pero precio enterprise

Realidad operativa: el self-hosted gana económicamente con cualquier volumen serio. El TCO real (incluyendo tu hora de operación a 50 €/h × 2 h/mes = 100 €) lo iguala a Cloud Pro pero te deja sin límites y con custom nodes. A partir de 10.000 ejecuciones/mes la diferencia con SaaS competidores es de un orden de magnitud.

n8n vs Zapier vs Make: comparativa técnica honesta

Dimensión	n8n self-hosted	Zapier	Make
Modelo de pricing	Infraestructura (fijo)	Por tasks ejecutadas	Por operaciones (cada paso cuenta)
Workflows con lógica compleja (loops, condicionales anidadas)	Excelente	Limitado	Bueno
Code custom (JS/Python)	Nativo, sin restricción	Code by Zapier (limitado)	Custom JS limitado
Self-hosted	Sí	No	No
AI Agents nativos (LangChain)	Sí, completo	Vía integraciones	Vía integraciones
Vector stores nativos	Sí (Pinecone, Qdrant, Weaviate, pgvector)	No nativos	No nativos
Custom nodes	Sí, ilimitado	No	No
Webhook trigger latencia	<100 ms	1-15 min en plans bajos	<1 min
Cobertura integraciones nativas	400+	7000+ apps	1700+ apps
Versionado git de workflows	Sí (export/import JSON)	No	No
SSO/SAML	Enterprise license	Enterprise plan	Enterprise plan
Curva de aprendizaje	Media (hay que entender concepto de items)	Baja	Media
Ideal para	Equipos técnicos, pymes con IT, casos complejos	No-code users, integraciones simples	Híbrido, casos medios

Zapier es el mejor para gente sin perfil técnico que quiere conectar 2-3 apps consumer rápidamente. Make es bueno para iteración visual rápida sin tocar código. n8n self-hosted gana cuando hay equipo técnico, lógica de negocio compleja, integraciones con sistemas internos o requisitos de gobierno del dato.

Casos de uso reales que hemos implementado en n8n self-hosted

Caso 1 — Onboarding de clientes B2B en pyme (10 min/cliente → 0)

Form web (FormBricks) → Webhook a n8n → Validación NIF contra API AEAT → Creación contacto en HubSpot → Creación cliente en Holded → Generación contrato PDF (DocuSign) → Email de bienvenida → Mensaje Slack al comercial. Tiempo de setup: 1 día. Tiempo ahorrado al mes: ~25 h.

Caso 2 — Sync inventario eCommerce ↔ ERP (cada 15 min, 24/7)

Schedule Trigger 15 min → API Shopify (productos modificados) → Loop → Lookup en Holded → Branch (existe / no existe) → Update stock + precio → Audit log a Postgres + alerta Slack si delta >10%. Resolvió un problema de stock fantasma que generaba 3-5 incidencias/semana.

Caso 3 — Clasificación automática de tickets de soporte con IA local

Trigger email IMAP → Extracción texto + adjuntos → Embeddings con Ollama (Llama 3) self-hosted → Vector search en Qdrant contra base de conocimiento → AI Agent Claude → Decisión: responder automáticamente, asignar a categoría en Jira, o escalar. Coste por ticket: 0,002 €. Resolución automática: 38% de los tickets sin intervención humana.

Caso 4 — Reporting financiero diario

Cron 6:00 AM → Query Postgres ERP → Query API banco PSD2 → Cruce de datos → Pivot table → Render PDF con plantilla → Upload a Google Drive → Mensaje Telegram al CFO con resumen. De 30 min/día manuales a 0.

Caso 5 — Lead scoring + enrichment B2B

HubSpot webhook (lead nuevo) → Enrichment con Apollo.io → Lookup LinkedIn (vía proxycurl) → AI Agent (GPT-4o) genera score + summary → Update HubSpot contact properties → Si score > 70: notificar a comercial en Slack con contexto. +22% en tasa de respuesta de comerciales.

Operativa: lo que realmente vas a tener que mantener

Updates mensuales de la imagen docker.n8n.io/n8nio/n8n:latest (o pinned :1.78.x si prefieres control). Suele ser zero-downtime con docker compose pull && docker compose up -d.
Migrations de BD automáticas al arrancar tras update — siempre hacer pg_dump ANTES.
Monitorización de Redis queue depth — si crece de forma sostenida, escalar workers.
Rotación de logs — EXECUTIONS_DATA_PRUNE=true lo hace automáticamente, pero verificar que el disco no se llena.
Monitor de errores — workflow Error Trigger que envía a Slack/email cualquier ejecución fallida con stack trace.
Disaster recovery test trimestral.

Operar un n8n self-hosted bien gestionado consume 1-3 horas al mes una vez la base está montada. Es proporcionalmente menor coste que cualquier SaaS equivalente a partir de cierto volumen.

FAQ: preguntas técnicas frecuentes

¿Cuánto tarda en arrancar una instalación productiva?

Con la receta Docker Compose de esta guía: 30-60 minutos hasta tener n8n accesible con TLS. La parte que requiere tiempo no es la instalación, es el diseño de los primeros workflows reales y la integración con vuestros sistemas (autenticaciones, mapeos de campos, lógica de negocio). Para un proyecto pyme tipo, un MVP con 3-5 workflows productivos suele estar en 1-2 semanas.

¿Puede correr offline / air-gapped?

Sí, completamente. n8n no requiere conexión saliente a n8n.io para funcionar. Solo desactiva N8N_DIAGNOSTICS_ENABLED y N8N_VERSION_NOTIFICATIONS_ENABLED. La instalación inicial requiere descargar la imagen Docker; después, las actualizaciones se pueden hacer importando imágenes manualmente desde un registro interno.

¿Puedo migrar de Zapier o Make a n8n?

No hay importador automático: los modelos de datos son diferentes. Lo que hacemos es:
1. Inventario de Zaps/Scenarios activos.
2. Priorización por volumen y criticidad.
3. Reimplementación en n8n iterativa (top 20% que mueven el 80% del valor).
4. Periodo de paralelo 2-4 semanas para validar paridad.
5. Apagado del SaaS original.

¿Funciona con Active Directory / LDAP corporativo?

Sí. Con licencia Enterprise vía SAML/OIDC. Sin licencia, vía workflow custom: el primer login crea el user automáticamente leyendo de LDAP via HTTP Request a un proxy (ldap-rest-api). Es feasible pero requiere setup.

¿Soporta multi-tenant?

Hasta n8n 1.x los proyectos (folders) y permisos por proyecto cubren la mayoría de casos. Si necesitas aislamiento estricto entre tenants (ej. agencia con varios clientes), la mejor práctica sigue siendo una instancia n8n por cliente (con orquestación Kubernetes / Docker Swarm). El overhead por instancia es bajo (~200 MB RAM idle).

¿Qué pasa con los datos personales (RGPD)?

n8n self-hosted te deja en pleno control. Recomendaciones:
– Identificar workflows que tocan PII y marcarlos.
– EXECUTIONS_DATA_SAVE_ON_SUCCESS=none para flujos con PII (no guardar payloads en BD).
– Encryption at rest del volumen Postgres (LUKS / AWS RDS encryption).
– Política de retención corta (EXECUTIONS_DATA_MAX_AGE=72 horas) para flujos sensibles.
– Audit log centralizado.

¿Cuál es el límite real de ejecuciones simultáneas?

Depende de CPU + workers. Una instancia con 4 vCPU + 4 workers + concurrency 10 cada uno = 40 ejecuciones simultáneas teóricas. Con I/O-bound (la mayoría de workflows) llegamos a 80-120 reales. Para volúmenes mayores, escalar workers en hardware dedicado.

¿Puedo usar Python en los nodos Code?

Sí, n8n soporta Python via Pyodide (Python ejecutado en WASM dentro de Node). Limitaciones: no puedes instalar paquetes nativos arbitrarios; las librerías disponibles son las que vienen con Pyodide (numpy, pandas, requests subset). Para Python «real» con cualquier librería, mejor crear un microservicio Python (FastAPI) y llamarlo desde n8n con HTTP Request.

¿Cómo se hace deploy continuo de workflows?

Patrón recomendado:
1. Workflows se exportan a JSON via API REST.
2. Repo git con un workflow por archivo.
3. Pipeline CI/CD que importa los workflows al n8n de staging y luego producción usando la API REST de import.
4. Tests automáticos: workflows de test que invocan los workflows productivos con mocks y validan output.

Resumen ejecutivo

n8n self-hosted es la opción correcta cuando: hay equipo técnico mínimo, casos de uso medianos a complejos, integraciones con sistemas internos, requisitos de gobierno del dato o volumen de ejecuciones que hace el SaaS caro. La curva de aprendizaje es asumible (1-2 semanas para un perfil técnico), la operación es ligera (1-3 h/mes) y el techo de capacidad es altísimo: hemos visto instancias con 200+ workflows activos y 100.000+ ejecuciones/mes corriendo en una VM de 8 vCPU.

Si la pregunta es «¿cuánto tardo en montar n8n self-hosted bien?», la respuesta corta es: un día para la infraestructura, dos semanas para tener los primeros workflows productivos, y un mes para tener la operativa madura. Si quieres saltarte la curva, somos especialistas en este stack y montamos pilotos productivos en 2 semanas.

¿Quieres implementar n8n self-hosted en tu empresa? En Netbrain somos agencia n8n especializada en despliegues productivos en pymes y mediana empresa española. Cuéntanos tu caso →