Autoaloja n8n en un VPS con Docker

n8n es la clase de herramienta que empiezas a usar ligeramente y luego enrutas en silencio la mitad de tus operaciones. En ese punto «corre en el asiento cloud de alguien, medido por ejecución, con mis claves de API viviendo en sus servidores» empieza a sentirse menos genial. Autoalojar arregla las tres — coste plano, sin tope de ejecuciones, y tus claves se quedan en una máquina que posees. Con Docker es un trabajo de quince minutos.

Cuánto servidor necesita de verdad

Números honestos primero, para que no compres de más o de menos:

• ~2 GB de RAM es el sweetspot — n8n más su base de datos Postgres más workflows normales caben cómodamente aquí.
• 1 GB funciona si tus workflows son ligeros, pero lo notarás en ejecuciones más grandes.
• 4 GB si haces ejecuciones paralelas pesadas o empujas payloads grandes.

n8n no es hambriento de CPU en reposo; pica durante las ejecuciones. Una máquina de 2 núcleos está bien para la mayoría de las configuraciones. (Más sobre casar especificaciones con workload en la guía de dimensionamiento.)

La configuración con Docker

En una máquina Ubuntu/Debian nueva, instala Docker:

curl -fsSL https://get.docker.com | sudo sh

Crea una carpeta y un docker-compose.yml — n8n con un volumen persistente y Postgres:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_PASSWORD=change-me
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on: [db]
  db:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=n8n
    volumes:
      - ./db-data:/var/lib/postgresql/data

sudo docker compose up -d

Dos cosas que vale la pena señalar: los volúmenes (n8n-data, db-data) son lo que mantiene tus workflows vivos a través de reinicios y actualizaciones — no los saltes. Y n8n está atado a 127.0.0.1, no a 0.0.0.0 — no está expuesto a internet directamente. Eso es deliberado; el siguiente paso maneja el acceso de forma segura.

Acceso: HTTPS o un túnel

• URL pública (necesaria para nodos OAuth y webhooks): apunta una subdominio al servidor y ejecuta un reverse-proxy (Caddy es el de menor esfuerzo — HTTPS automático) delante de 127.0.0.1:5678. Aquí es donde encaja un plan con IP dedicada, ya que controlas puertos y DNS.
• Solo para ti, sin dominio: sáltate el proxy y alcánzalo por un túnel SSH — ssh -L 5678:127.0.0.1:5678 user@server, luego abre localhost:5678. Funciona bien en un VPS NAT.

Ciérralo bien y mantenlo arriba

n8n mantiene tus claves de API y credenciales, así que la máquina debe estar cerrada: haz la checklist de seguridad (claves SSH, firewall, sin login por contraseña) antes de poner credenciales reales. restart: always en el archivo compose ya significa que Docker trae n8n de vuelta tras un fallo o reinicio — eso es tu disponibilidad manejada.

¿Merece la pena?

Sé honesto contigo mismo sobre el volumen. Si ejecutas automatizaciones constantemente, autoalojar gana en coste (plano vs por ejecución) y elimina cualquier límite de workflows/ejecuciones. Si disparas unos pocos flujos al mes, un asiento alojado es menos follón. Pero el argumento del control se sostiene independientemente: tus workflows, tus datos, tus claves — en tu servidor, no alquilados. Para la mayoría de la gente que se puso seria con n8n, ese es el factor decisivo.

Una máquina de 2 GB, un archivo compose, un dominio (o un túnel), y estás ejecutando tu propio hub de automatización — pagable en cripto sin KYC, en línea en minutos.

Configuración lista: mira VPS para n8n — el plan recomendado y un despliegue cripto en un minuto.