n8n self-hosted: quan té sentit i quan t'estàs creant un problema

Porto temps fent servir n8n self-hosted per a automatitzacions internes i projectes personals. És una eina que m’ha estalviat hores de feina, però també m’ha donat algun ensurt que s’hauria pogut evitar si hagués estat més disciplinat des del principi. El que explicaré aquí no és un tutorial d’instal·lació ni un pamflet de màrqueting. És una anàlisi honesta de quan muntar n8n a la teva pròpia infra val la pena i quan t’estàs comprant un problema que no necessites.

La versió cloud de n8n existeix i funciona. Si l’opció self-hosted segueix sent popular és per tres raons: control total sobre les dades, flexibilitat per a personalitzacions, i que no té cost de llicència per execució. Però cadascun d’aquests avantatges ve amb una responsabilitat que molta gent subestima.

Quan sí que té sentit anar self-hosted

No diré “sempre” perquè seria mentida. Hi ha escenaris concrets on muntar n8n al teu propi servidor té tot el sentit.

Automatitzacions internes d’equip

Si el teu equip necessita connectar eines internes ---base de dades, Slack, repositoris, dashboards--- i no vols pagar per cada execució, self-hosted és ideal. El tràfic és predictible, els usuaris són coneguts, i el risc d’escalat descontrolat és baix.

Prototips i validacions ràpides

Quan necessites provar una integració nova o muntar un flux ràpid per a un client, tenir n8n a la teva màquina local o en un servidor de desenvolupament és molt més àgil que configurar una subscripció cloud per a un experiment que potser duri una setmana.

Equips petits amb cert coneixement ops

Si hi ha algú a l’equip que sap gestionar Docker, mantenir un servidor actualitzat i configurar backups, n8n self-hosted no requereix un equip d’infraestructura dedicat. Un VPS barat amb Docker Compose és suficient per a molts casos.

Dades que no poden sortir de la teva xarxa

En sectors regulats o projectes on les dades són sensibles, tenir el motor d’automatització dins de la teva infraestructura pot ser un requisit, no una preferència. Self-hosted et dona aquesta garantia que res no surt de la teva xarxa.

Quan NO té sentit

Aquí és on la conversa es posa incòmoda, perquè moltes vegades la decisió d’anar self-hosted es pren per inèrcia, per estalvi percebut o per una falsa sensació de control.

Quan necessites alta disponibilitat i no tens infra

Si el teu workflow de n8n és crític ---per exemple, processa pagaments, envia notificacions a clients o alimenta un sistema en producció--- i el teu setup és un Docker Compose en un VPS sense redundància, estàs jugant amb foc. Si el servidor cau, els workflows es perden. Si el disc s’omple, n8n deixa de funcionar sense avisar.

Si la teva automatització és crítica per al negoci i no tens capacitat per garantir disponibilitat, la versió cloud probablement et sortirà més barata que la primera caiguda.

Quan gestiones dades sensibles sense infra adequada

Self-hosted et dona control, però el control sense disciplina és pitjor que delegar-ho a un proveïdor competent. Si processaràs dades personals, credencials de clients o informació financera en un n8n muntat en un VPS sense HTTPS, sense firewall ben configurat, i amb credencials d’admin per defecte, el risc és real.

Quan ningú de l’equip el vol mantenir

n8n s’ha d’actualitzar. El servidor s’ha de parxejar. Els backups s’han de fer. Si muntes n8n self-hosted i ningú assumeix la responsabilitat de mantenir-lo, en sis mesos tindràs una versió desactualitzada amb vulnerabilitats conegudes i sense backups. Ho he vist passar.

Quan el cost real supera el del cloud

Fes el compte honest. Un VPS, el temps d’un dev mantenint el setup, el risc de downtime, el temps de debugging quan alguna cosa falla. Si l’equip és de tres persones i l’alternativa cloud costa 20 euros al mes, el self-hosted pot sortir més car en hores de feina encara que el servidor sigui barat.

Docker setup: un punt de partida realista

Si després d’avaluar els riscos decideixes que self-hosted és el teu camí, aquest és un docker-compose.yml que faig servir com a base. No és l’exemple mínim de la documentació; té les configuracions que considero necessàries per a alguna cosa que va més enllà d’un experiment.

# docker-compose.yml
version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      # Configuración básica
      - N8N_HOST=n8n.tudominio.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.tudominio.com/

      # Base de datos externa (NO usar SQLite en producción)
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}

      # Seguridad
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=${N8N_USER}
      - N8N_BASIC_AUTH_PASSWORD=${N8N_PASSWORD}

      # Zona horaria
      - GENERIC_TIMEZONE=Europe/Madrid
      - TZ=Europe/Madrid

      # Encryption key para credenciales (IMPORTANTE: no perder esta clave)
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - n8n-network

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

volumes:
  n8n_data:
  postgres_data:

networks:
  n8n-network:
    driver: bridge

I el .env corresponent:

# .env
POSTGRES_USER=n8n_user
POSTGRES_PASSWORD=una_password_segura_de_verdad
N8N_USER=admin
N8N_PASSWORD=otra_password_segura
N8N_ENCRYPTION_KEY=genera-una-clave-larga-aleatoria-aqui

Per què PostgreSQL i no SQLite

SQLite és el default de n8n i funciona per provar. Però en producció té problemes reals:

• No suporta bé escriptures concurrents. Si tens diversos workflows executant-se alhora, pots tenir bloquejos.
• Els backups són més fràgils. Copiar un arxiu SQLite mentre n8n està escrivint pot generar un backup corrupte.
• No escala. Si els teus workflows generen volum d’execucions, SQLite es converteix en un coll d’ampolla.

PostgreSQL resol tot això i n8n el suporta nativament.

Seguretat: el que no pots ignorar

La seguretat d’un n8n self-hosted no és trivial, i és probablement l’aspecte que més gent subestima. n8n executa codi, es connecta a serveis externs, i emmagatzema credencials d’APIs, bases de dades i serveis de tercers. Si algú obté accés a la teva instància, té accés a tot això.

HTTPS obligatori

No exposis n8n per HTTP. Mai. Les credencials viatgen en text pla, els webhooks són accessibles des d’internet, i qualsevol persona a la mateixa xarxa pot interceptar el tràfic.

La forma més senzilla d’afegir HTTPS és posar un reverse proxy davant. Un exemple amb Caddy, que gestiona certificats automàticament:

# Caddyfile
n8n.tudominio.com {
    reverse_proxy n8n:5678
}

O amb nginx:

server {
    listen 443 ssl;
    server_name n8n.tudominio.com;

    ssl_certificate /etc/letsencrypt/live/n8n.tudominio.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.tudominio.com/privkey.pem;

    location / {
        proxy_pass http://localhost:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket support (necesario para el editor de n8n)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Xarxa interna sempre que sigui possible

Si n8n només el fa servir el teu equip, no necessita estar exposat a internet. Posa’l en una xarxa interna i accedeix-hi per VPN. Això elimina de cop la majoria de vectors d’atac.

Autenticació

n8n té autenticació bàsica integrada, però no és sofisticada. Si necessites SSO, MFA o control d’accés per rols, la versió self-hosted comunitària es queda curta. La versió enterprise sí que ho ofereix, però té cost.

El mínim que hauries de configurar:

• Basic auth actiu amb passwords forts.
• Canviar les credencials per defecte (sembla obvi, però no ho és).
• Si fas servir webhooks públics, limitar per IP o afegir tokens d’autenticació als propis workflows.

Backups: el que no et pots permetre perdre

He vist gent perdre workflows sencers perquè el servidor va caure i no hi havia backup. La bona notícia és que fer backup de n8n és senzill si fas servir PostgreSQL.

Què necessites fer còpia de seguretat

1. La base de dades PostgreSQL. Conté els workflows, les execucions i les credencials xifrades.
2. El fitxer d’encryption key. Sense aquesta clau, les credencials emmagatzemades són irrecuperables.
3. El volum de n8n (.n8n). Conté configuració i arxius que pugen els workflows.

Script de backup automatitzat

#!/bin/bash
# backup_n8n.sh - Ejecutar con cron diariamente

BACKUP_DIR="/backups/n8n"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION_DAYS=30

mkdir -p "$BACKUP_DIR"

# 1. Backup de PostgreSQL
docker exec n8n-postgres pg_dump \
    -U n8n_user \
    -d n8n \
    --format=custom \
    > "$BACKUP_DIR/n8n_db_${DATE}.dump"

echo "[BACKUP] Base de datos exportada: n8n_db_${DATE}.dump"

# 2. Backup del volumen de n8n
docker run --rm \
    -v n8n_data:/source:ro \
    -v "$BACKUP_DIR":/backup \
    alpine tar czf "/backup/n8n_data_${DATE}.tar.gz" -C /source .

echo "[BACKUP] Volumen n8n exportado: n8n_data_${DATE}.tar.gz"

# 3. Copiar encryption key (si está en .env)
cp /path/to/your/.env "$BACKUP_DIR/env_${DATE}.bak"

# 4. Limpiar backups antiguos
find "$BACKUP_DIR" -type f -mtime +$RETENTION_DAYS -delete

echo "[BACKUP] Completado. Backups antiguos (>$RETENTION_DAYS días) eliminados."

Configura’l amb cron:

# Ejecutar backup diario a las 3:00 AM
0 3 * * * /path/to/backup_n8n.sh >> /var/log/n8n_backup.log 2>&1

L’encryption key de n8n és el més important que has de fer còpia de seguretat. Si la perds, totes les credencials emmagatzemades a n8n es tornen irrecuperables. Guarda-la en un lloc segur fora del servidor.

Gestió de credencials: com les guarda n8n i quins riscos hi ha

n8n xifra les credencials abans de guardar-les a la base de dades. Fa servir AES-256-CBC amb l’encryption key que defineixes a la configuració. Això significa que fins i tot si algú accedeix a la teva base de dades, les credencials no són llegibles directament.

Però hi ha matisos importants:

L’encryption key és un single point of failure

Si defineixes l’encryption key com a variable d’entorn i el servidor es perd sense backup d’aquesta variable, les credencials xifrades a la base de dades són inútils. He vist equips que tenien backup de la DB però no de l’encryption key. Resultat: workflows recuperats, però totes les credencials trencades.

Credencials en workflows compartits

Quan exportes un workflow de n8n, les credencials NO s’exporten. Això és bo per seguretat, però significa que en importar un workflow en una altra instància has de reconfigurar cada credencial manualment. Si tens 15 workflows amb 40 credencials, la migració no és trivial.

Rotació de credencials

n8n no té un sistema de rotació de credencials integrat. Si un token d’API caduca, has d’anar a l’editor i canviar-lo manualment. Per a equips petits això és gestionable. Per a setups amb desenes d’integracions, comença a ser un problema operatiu.

Bones pràctiques

• Documenta quines credencials fa servir cada workflow.
• Guarda l’encryption key en un gestor de secrets (Vault, AWS Secrets Manager, o almenys un fitxer xifrat fora del servidor).
• Revisa periòdicament quines credencials estan actives i quines són obsoletes.
• Mai guardis tokens o passwords directament als nodes de n8n si pots fer servir variables d’entorn o un servei de secrets extern.

Actualitzacions: el manteniment que ningú vol fer

n8n publica releases amb freqüència. Algunes inclouen correccions de seguretat. Si la teva instància self-hosted es queda sense actualitzar, acumules vulnerabilitats conegudes.

Procés d’actualització amb Docker

#!/bin/bash
# update_n8n.sh

echo "[UPDATE] Haciendo backup antes de actualizar..."
/path/to/backup_n8n.sh

echo "[UPDATE] Parando n8n..."
docker compose down

echo "[UPDATE] Descargando nueva versión..."
docker compose pull

echo "[UPDATE] Arrancando n8n..."
docker compose up -d

echo "[UPDATE] Comprobando estado..."
sleep 10
docker compose ps

echo "[UPDATE] Completado."

La meva recomanació: no fixis la imatge a latest si no vols sorpreses. Fes servir un tag concret i actualitza de forma controlada:

image: n8nio/n8n:1.42.1  # en vez de n8nio/n8n:latest

Així pots provar la nova versió en un entorn de desenvolupament abans d’actualitzar producció.

Monitorització bàsica

Un n8n self-hosted sense monitorització és un forat negre. No saps si està funcionant, no saps si els workflows fallen, no saps si el disc s’està omplint.

El mínim que jo hi poso:

#!/bin/bash
# health_check_n8n.sh

# Verificar que n8n responde
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:5678/healthz)

if [ "$HTTP_CODE" != "200" ]; then
    echo "[ALERT] n8n no responde. HTTP code: $HTTP_CODE"
    # Aquí podrías enviar alerta a Slack, email, etc.
    curl -X POST "$SLACK_WEBHOOK" \
        -H 'Content-Type: application/json' \
        -d '{"text": "n8n self-hosted no responde. Revisar urgente."}'
fi

# Verificar espacio en disco
DISK_USAGE=$(df -h / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$DISK_USAGE" -gt 85 ]; then
    echo "[ALERT] Disco al ${DISK_USAGE}%"
fi

El meu criteri resumit

El que m’hauria agradat fer des del primer dia

Si tornés a muntar un n8n self-hosted des de zero, faria tres coses abans de crear el primer workflow:

1. Configurar PostgreSQL en lloc de SQLite. La migració posterior és possible però molesta.
2. Configurar backups automàtics. No “demà ho faig”. Abans del primer workflow.
3. Guardar l’encryption key en un lloc segur. No al mateix servidor. No en un post-it. En un gestor de secrets o en un fitxer xifrat en un altre lloc.

El self-hosted de n8n és una bona opció quan saps el que estàs fent i acceptes la responsabilitat que ve amb el control. Si el que vols és muntar workflows ràpid sense pensar en servidors, backups o seguretat, la versió cloud existeix precisament per a això. No hi ha cap vergonya en fer-la servir.