Deploy y
self-hosting

Panorama: las formas de correr n8n

Ya viste el resumen narrado en 04 · n8n desde cero. Acá está la versión de consulta rápida, con foco en self-hosting: qué elegir según cuánto control necesitás y cuánto querés administrar vos.

Instalación con Docker

La imagen oficial es docker.n8n.io/n8nio/n8n. El comando mínimo para levantar una instancia con datos persistentes:

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -e GENERIC_TIMEZONE="America/Argentina/Buenos_Aires" \
  -e TZ="America/Argentina/Buenos_Aires" \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Para correr un comando único sin quedar pegado a la terminal, usá -d (detached) en vez de -it --rm, y agregá --restart unless-stopped para que vuelva a levantarse solo si el servidor reinicia.

Docker Compose: n8n + Postgres

Para producción conviene separar n8n de la base de datos desde el principio. Un compose.yml realista, con Postgres y un .env aparte para los secretos:

# compose.yml
volumes:
  n8n_data:
  db_storage:

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

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_HOST: n8n.tudominio.com
      N8N_PROTOCOL: https
      N8N_PORT: 5678
      N8N_WEBHOOK_URL: https://n8n.tudominio.com/
      GENERIC_TIMEZONE: America/Argentina/Buenos_Aires
      TZ: America/Argentina/Buenos_Aires
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

Y el .env con los secretos, que nunca se sube al repo:

# .env
POSTGRES_USER=n8n
POSTGRES_PASSWORD=cambiar-esta-clave
POSTGRES_DB=n8n
N8N_ENCRYPTION_KEY=generar-una-clave-larga-y-guardarla-aparte

Arriba con docker compose up -d. Nota: si ya tenías una instancia corriendo con SQLite, los datos no migran solos a Postgres — este setup es para arrancar limpio o para migrar a mano.

Base de datos: SQLite vs. PostgreSQL

n8n usa SQLite por defecto (DB_TYPE=sqlite): un archivo dentro del volumen, cero configuración, perfecto para arrancar o para instancias personales. Para producción con volumen real de ejecuciones, PostgreSQL es lo recomendado: soporta mejor la concurrencia y es el motor que usa n8n Cloud internamente.

Variables de entorno: la tabla completa

n8n se configura enteramente por variables de entorno. Están agrupadas por familia; nombres verificados contra la documentación oficial de n8n.

Host / URL

Seguridad

Zona horaria

Ejecuciones

Nodo Code

Task runners

Otros

La clave de cifrado: lo más crítico de todo

Reverse proxy y HTTPS

Si ponés n8n detrás de un reverse proxy (Nginx, Caddy, Traefik) para servirlo con HTTPS en un dominio propio, dos variables son las que evitan el dolor de cabeza más común:

N8N_PROXY_HOPS le dice a n8n cuántos proxies hay delante suyo, para que interprete correctamente headers como X-Forwarded-For (necesario, por ejemplo, para que el rate-limiting y los logs vean la IP real del cliente y no la del proxy).

Escalar: modo cola (queue mode)

Para volumen alto de ejecuciones, una sola instancia de n8n deja de alcanzar. El modo cola separa el problema en dos roles: una instancia main que recibe triggers y encola el trabajo, y uno o más workers que lo van tomando de la cola y ejecutando en paralelo. La cola vive en Redis.

Actualizar y hacer backups

Actualizar una instancia con Docker es simple: bajar la imagen nueva y recrear el contenedor (no reconstruirlo desde cero, solo apuntarlo a la imagen nueva):

docker pull docker.n8n.io/n8nio/n8n
docker compose up -d

Como los datos viven en el volumen y en Postgres (no en el contenedor), recrearlo no pierde nada. Igual conviene revisar el changelog antes de saltar versiones grandes.