Autoalojar n8n en un VPS.
Su motor de automatización, sus credenciales, su servidor.

n8n es un motor de automatización de flujos de trabajo: un lienzo visual donde se conecta un disparador — un webhook, una programación, una fila nueva en una base de datos, un mensaje en una cola — a una cadena de nodos que llaman a APIs, transforman datos, se ramifican según condiciones, ejecutan JavaScript o Python arbitrario, y entregan el resultado a lo que venga después. Trae de serie varios cientos de nodos de integración, además de un nodo HTTP Request genérico que cubre todo lo demás. Desde la línea 1.x también incorpora nodos AI Agent y LLM, razón por la cual gran parte de quienes lo instalan en 2026 están construyendo agentes en lugar de la clásica fontanería ETL.

La parte que importa antes de escribir un solo comando es la licencia, porque n8n no es de código abierto en el sentido de la OSI y la diferencia no es académica. El núcleo se distribuye bajo la Sustainable Use License: una concesión no exclusiva, libre de regalías y mundial para usar, copiar, modificar y distribuir el software con fines empresariales internos y para uso personal o no comercial. Lo que retiene es el derecho a cobrar a terceros por n8n o por un derivado de él — la cláusula que descarta construir sobre eso un producto de pago de «n8n gestionado». Por separado, cualquier archivo que lleve .ee. en su nombre o .ee en su ruta queda excluido por completo de esa licencia y requiere una n8n Enterprise License de pago.

Dicho sin rodeos: ejecutar n8n en un VPS para automatizar su propia empresa, el trabajo de sus propios clientes entregado como un servicio que usted presta, o su propia vida personal, está dentro de la concesión gratuita y siempre lo ha estado. Vender n8n como producto de alojamiento no lo está. Casi todos los debates de «¿n8n es realmente gratis?» en internet son dos personas hablando sin entenderse a través de esa línea.

El lado del coste. n8n Cloud tiene precio por ejecución: el plan Starter cuesta €20 al mes facturados anualmente por 2 500 ejecuciones, Pro cuesta €50 al mes por 10 000, Business cuesta €667 al mes por 40 000. Autoalojado, el número de ejecuciones no es en absoluto una partida — está limitado por la cantidad de CPU y memoria que tenga la máquina. Un flujo de trabajo que consulta una API cada cinco minutos consume por sí solo 8 640 ejecuciones al mes; en Cloud ese único flujo de trabajo ya obliga al nivel Pro, y en un VPS de $3.90 es un error de redondeo frente a la CPU en reposo.

Precios de Cloud publicados en n8n.io en agosto de 2026, facturados anualmente; la facturación mensual cuesta más. El intercambio no es solo dinero — el autoalojamiento traslada las actualizaciones, las copias de seguridad, la renovación de TLS y el tiempo de actividad a su lado de la línea.

En el panel: Order → VPS → Sentinel, imagen Debian 12. No se requiere ninguna dirección de correo electrónico para abrir la cuenta, no se pide ningún documento de identidad en ningún momento, y la factura se salda en Monero, Bitcoin, Lightning o cualquier otro de los activos admitidos. Elija el bastión por la latencia hacia los servicios que automatiza y no hacia usted mismo — un servidor de automatización habla con APIs mucho más de lo que habla con usted.

Después cree el registro DNS antes de tocar el servidor: un registro A para n8n.example.com que apunte a la IPv4 del VPS, y un registro AAAA si usa IPv6. Esto hay que hacerlo primero, porque Caddy pide un certificado a Let's Encrypt en el momento en que arranca la pila, y una solicitud de certificado para un nombre que no resuelve falla — y luego se retira, y usted se pasa veinte minutos preguntándose por qué el sitio es inalcanzable.

Dele un minuto al DNS para propagarse y confírmelo desde su propia máquina antes de continuar:

dig +short n8n.example.com
# → the IPv4 of your VPS, and nothing else

Antes de que nada escuche en un puerto público, ejecute la lista de refuerzo de la primera hora — SSH solo con clave, un firewall que permita 22, 80 y 443 y nada más, y actualizaciones de seguridad desatendidas. Un servidor de automatización es una caja fuerte de credenciales; se merece la hora entera.

Cree primero el directorio y genere los dos secretos. Genérelos ahora, en este orden, y péguelos en el .env a medida que avanza — la clave de cifrado en particular debe existir antes del primer arranque de n8n, no después.

mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32   # → N8N_ENCRYPTION_KEY
openssl rand -hex 24   # → POSTGRES_PASSWORD

/opt/n8n/.env

DOMAIN=n8n.example.com
LETSENCRYPT_EMAIL=you@example.com
GENERIC_TIMEZONE=Europe/Stockholm

N8N_ENCRYPTION_KEY=paste_the_32_byte_hex_here
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste_the_24_byte_hex_here

Bloquee el archivo de inmediato — contiene la clave de todas las credenciales que la instancia llegará a almacenar:

chmod 600 /opt/n8n/.env

/opt/n8n/docker-compose.yml

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DOMAIN=${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://${DOMAIN}
      - WEBHOOK_URL=https://${DOMAIN}/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_VERSION_NOTIFICATIONS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  caddy_data:
  caddy_config:
  pg_data:
  n8n_data:

/opt/n8n/Caddyfile

{$DOMAIN} {
    encode zstd gzip
    tls {$LETSENCRYPT_EMAIL}
    reverse_proxy n8n:5678
}

Dos decisiones de diseño que merece la pena nombrar. Primero, n8n no publica ningún puerto. Solo Caddy se une a 80 y 443; n8n escucha en 5678 dentro de la red de Compose, donde nada fuera del host puede alcanzarlo. Un número sorprendente de instancias de n8n autoalojadas están en internet público en el puerto 5678 sin TLS por delante, y los motores de búsqueda de servicios expuestos las indexan. Segundo, el volumen de datos de n8n sigue montado aunque PostgreSQL ahora contenga los flujos de trabajo — ese directorio sigue conteniendo la configuración de la instancia, los archivos de registro y los recursos de control de versiones.

Levántelo:

cd /opt/n8n
docker compose up -d
docker compose logs -f caddy   # watch the certificate being issued

Un n8n que arranca, muestra el editor y ejecuta una prueba manual todavía no es un n8n que funciona. La mitad que falla en silencio son los webhooks entrantes, y falla de formas que parecen culpa del servicio de terceros.

WEBHOOK_URL. Sin ella, n8n construye las URL de webhook a partir de N8N_HOST y N8N_PORT y le entrega algo como http://localhost:5678/webhook/abc — que luego pega en Stripe o GitHub, donde nunca podrá alcanzarse. El archivo Compose de arriba fija WEBHOOK_URL a la raíz HTTPS pública, que es lo que mostrará el editor y lo que el mundo exterior realmente puede llamar.

N8N_EDITOR_BASE_URL. La URL pública que n8n usa para los enlaces en los correos que envía — restablecimientos de contraseña, invitaciones de usuario. Si esto está mal, significa un enlace de invitación que apunta a localhost, lo cual es un ticket de soporte de un compañero en lugar de una integración rota.

N8N_PROXY_HOPS. n8n lee la IP del cliente desde X-Forwarded-For, y solo confía en tantos saltos como indique este número. Con un proxy inverso delante — el Caddy de esta pila — el valor es 1. Ponga Cloudflare delante de Caddy y pasa a ser 2. Déjelo en el valor por defecto 0 y cada petición parecerá venir del propio proxy, lo que rompe silenciosamente los límites de tasa y cualquier lógica basada en IP en sus flujos de trabajo.

N8N_SECURE_COOKIE. Por defecto es true, lo que significa que la cookie de sesión solo se envía por HTTPS. Es el ajuste correcto y esta pila lo cumple. Merece la pena saberlo porque explica el síntoma clásico de un primer intento sobre http plano: el formulario de acceso acepta la contraseña y luego le devuelve al formulario de acceso, indefinidamente. La solución es TLS, no desactivar la marca.

Pruébelo como es debido. Cree un flujo de trabajo con un nodo Webhook, active el flujo de trabajo, copie la Production URL, y llámela desde una máquina que no sea el servidor:

curl -i https://n8n.example.com/webhook/<path>
# → HTTP/2 200, and a new execution visible in the editor

La distinción con la que todo el mundo tropieza al menos una vez: la Test URL solo escucha mientras tiene el editor abierto con «Listen for test event» activado. La Production URL solo existe cuando el flujo de trabajo está marcado como Active. Un webhook que funciona en el editor y da 404 en producción es casi siempre un flujo de trabajo inactivo.

Por defecto n8n se ejecuta en modo regular: el mismo proceso que sirve el editor y recibe los webhooks también ejecuta los flujos de trabajo. Es simple y es correcto hasta que un flujo de trabajo largo empieza a hacer esperar a los demás. El síntoma es inconfundible — las ejecuciones quedan en «running» durante minutos, el editor se vuelve lento, y un webhook que debería responder en 200 ms responde en ocho segundos.

El modo cola divide el trabajo. La instancia principal conserva el editor, los disparadores y los endpoints de webhook; empuja los ID de ejecución a Redis; procesos worker independientes los recogen, cargan el flujo de trabajo desde PostgreSQL, lo ejecutan y responden a través de Redis. De esa arquitectura se derivan tres reglas, y las tres muerden a quienes las pasan por alto: todas las instancias deben compartir la misma base de datos PostgreSQL, todas las instancias deben llevar la misma N8N_ENCRYPTION_KEY, y SQLite no está soportado en absoluto.

Las incorporaciones al archivo Compose son un servicio Redis y un servicio worker, que es la misma imagen de n8n ejecutada con el comando worker:

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--save", "60", "1", "--appendonly", "no"]
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker --concurrency=5
    depends_on:
      - redis
      - postgres
    environment:
      # the SAME encryption key and the SAME database as the main instance
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}

Añada también EXECUTIONS_MODE=queue y QUEUE_BULL_REDIS_HOST=redis al servicio principal de n8n — ambos lados deben coincidir en el modo. Hay dos opciones que merece la pena fijar desde el primer día: OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true, para que pulsar «Test workflow» en el editor no bloquee el proceso principal, y N8N_GRACEFUL_SHUTDOWN_TIMEOUT, que por defecto es de 30 segundos y decide cuánto tiempo se le permite a un worker terminar su tarea actual durante un redespliegue. Si sus flujos de trabajo suelen tardar más de medio minuto, auméntelo o cada despliegue matará trabajo en curso.

No empiece por aquí. El modo cola añade dos piezas móviles y una clase de fallo que el modo regular simplemente no tiene. Quédese en modo regular hasta que vea la cola crecer o un flujo de trabajo bloqueando a otro, y entonces añada un único worker en la misma máquina antes de añadir una segunda máquina. Esa progresión — Sentinel en modo regular, Garrison con un worker, Ravelin con tres — cubre todo salvo un despliegue genuinamente grande.