n8n selbst hosten: Docker, Backups, Updates & Sicherheit

Dieser Leitfaden bündelt erprobte Self‑Hosting‑Tipps für n8n – ohne Over‑Engineering, mit klaren Defaults. Ziel: stabiler Betrieb, nachvollziehbare Backups, stressfreie Updates und saubere Absicherung.

Hinweis: Wenn du n8n noch nicht installiert hast, starte mit meinem Setup‑Artikel für den Raspberry Pi:

n8n auf dem Raspberry Pi einrichten → /blog/n8n-setup

Ziele & Setup‑Überblick

Stabiler Betrieb via Docker Compose (einfaches Deployment, reproduzierbar)
Datenintegrität: konsistente Backups der n8n‑Daten und Konfiguration
Sichere Erreichbarkeit: TLS, Basis‑Absicherung, sauberes Exposure
Updates ohne Herzklopfen: Versionen pinnen, Rollback parat

Empfohlene Startarchitektur:

Single‑Container n8n + benanntes Volume (einfach, schnell)
Optional: Reverse‑Proxy (Caddy/Traefik) oder Cloudflare Tunnel für TLS/Exposure
Optional: Externe DB (PostgreSQL) für größere Installationen

Docker Compose: solide Defaults für n8n

version: "3.9"
services:
  n8n:
    image: n8nio/n8n:1.72.0 # Version pinnen, nicht :latest
    container_name: n8n
    restart: unless-stopped
    environment:
      - GENERIC_TIMEZONE=Europe/Berlin
      - N8N_HOST=n8n.example.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=${N8N_BASIC_AUTH_USER}
      - N8N_BASIC_AUTH_PASSWORD=${N8N_BASIC_AUTH_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      # bei externer DB: DB_POSTGRESDB_HOST, DB_POSTGRESDB_USER, DB_POSTGRESDB_PASSWORD, DB_POSTGRESDB_DATABASE
    ports:
      - "5678:5678"
    volumes:
      - n8n_data:/home/node/.n8n
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:5678/healthz"]
      interval: 30s
      timeout: 5s
      retries: 5
 
volumes:
  n8n_data:

Best Practices:

Version pinnen: vermeidet Überraschungen bei Major/Minor‑Releases.
.env nutzen: Secrets (User, Passwort, Encryption Key) nicht in Git commiten.
Healthcheck: erleichtert Monitoring/Restart‑Logik.
Expose bewusst: Port 5678 nur freigeben, wenn kein Reverse‑Proxy/Tunnel vorgeschaltet ist.

Siehe auch: Basissetup und docker compose up -d im Setup‑Artikel (Schritt 3) → /blog/n8n-setup

Backups für n8n: was, wie, wie oft

Zu sichern:

Volume n8n_data (enthält Workflows, Credentials‑Vault, ggf. SQLite‑DB)
.env mit Secrets und docker-compose.yml (für Disaster‑Recovery)
Bei PostgreSQL: Datenbank‑Dump zusätzlich zum Volume

Beispiel: Volume‑Backup mit tar (als Cronjob nutzbar)

# Lokalverzeichnis für Backups
mkdir -p ~/backups/n8n
 
# Backup des Docker-Volumes (Zeitstempel im Dateinamen)
docker run --rm \
  -v n8n_data:/data:ro \
  -v $HOME/backups/n8n:/backup \
  alpine sh -c "tar -czf /backup/n8n_$(date +%F_%H-%M).tgz -C / data"

PostgreSQL‑Dump (falls verwendet):

docker exec -t postgres pg_dump -U $POSTGRES_USER $POSTGRES_DB \
  | gzip > ~/backups/n8n/pg_$(date +%F_%H-%M).sql.gz

Tipps:

Rotation: 7 tägliche, 4 wöchentliche, 3 monatliche Backups behalten.
Offsite: zusätzlich verschlüsselt extern speichern (z. B. S3/Backblaze, rclone).
Wiederherstellung testen: 1× pro Quartal Restore in Testumgebung durchführen.

Im Setup‑Artikel verwende ich das Volume n8n_data – genau das sicherst du hier. Details zum Anlegen findest du in Schritt 3 → /blog/n8n-setup

n8n updaten: kontrolliert und reversibel

Grundablauf:

# neue Images ziehen
docker compose pull
 
# aktualisieren (behält Daten/Volumes)
docker compose up -d
 
# Health prüfen
docker ps --format "table {{.Names}}\t{{.Status}}" | grep n8n

Empfehlungen:

Changelog lesen und zuerst in Staging testen (identisches Compose, andere Domain).
Image‑Tag bewusst wählen (z. B. 1.72.x) und erst später auf neue Minor/Major springen.
Rollback parat: vorherigen Tag notieren und bei Bedarf zurückwechseln (image: n8nio/n8n:1.71.x).

Sicherheit: Exposure minimieren, Zugang absichern

Ziel: Oberfläche nur für dich/Team, Webhooks sicher erreichbar.

Transportverschlüsselung: TLS erzwingen (Proxy oder Cloudflare Tunnel). In n8n N8N_PROTOCOL=https und WEBHOOK_URL korrekt setzen.
Zugriffsschutz: N8N_BASIC_AUTH_ACTIVE=true mit starkem Passwort; zusätzlich IP‑Allowlist via Proxy oder Cloudflare Access (Zero‑Trust) vorschalten.
Credentials absichern: eigenen N8N_ENCRYPTION_KEY setzen und sicher aufbewahren (ohne Key sind Credentials nicht wiederherstellbar).
Oberfläche nicht unnötig exponieren: Wenn Reverse‑Proxy/Tunnel genutzt wird, Port 5678 nicht öffentlich öffnen.
Trennung per Netzwerk: n8n in ein internes Docker‑Netz; nur Proxy/Tunnel veröffentlicht Ports.
Secrets sauber handeln: .env mit restriktiven Rechten (600) und nie ins Repo pushen.
Telemetrie/Diagnose: je nach Policy deaktivieren; entsprechende Env‑Optionen laut n8n‑Doku setzen.

Wenn du einen Cloudflare Tunnel verwendest: Die Einrichtung ist in meinem Setup‑Artikel (Schritt 4) beschrieben → /blog/n8n-setup

Beispiel: Caddy als Reverse‑Proxy (Auto‑TLS via Let’s Encrypt)

n8n.example.com {
  reverse_proxy n8n:5678
  encode gzip zstd
  header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
}

Oder Cloudflare Tunnel (kein offener Ingress nötig):

cloudflared:
  image: cloudflare/cloudflared:latest
  command: tunnel run --token ${CLOUDFLARE_TUNNEL_TOKEN}
  restart: unless-stopped
  network_mode: host

Optional: PostgreSQL & Scale‑Up

Für viele Setups genügt die Standard‑DB (SQLite im Volume). Gründe für PostgreSQL:

größere Datenmengen, viele Ausführungen/Logs
parallele Ausführung mit Worker/Queues
externe Backups/Monitoring

Wichtig: DB‑Backups zusätzlich zum n8n_data‑Volume anlegen und Restore testen.

Monitoring & Logs (nice to have)

Container‑Logs: docker logs -f n8n (Fehler/Workflow‑Failures prüfen)
Healthcheck beobachten: docker ps Status und Restart‑Counts im Blick behalten
Reverse‑Proxy‑Access‑Logs: 4xx/5xx Muster erkennen, Ratenlimit ggf. justieren
Optional: leichtgewichtiges Monitoring (z. B. Uptime‑Kuma) für HTTP‑Checks

Häufige Fehler & schnelle Fixes

WEBHOOK_URL vergessen/inkorrekt: Webhooks schlagen extern fehl → Domain inkl. Protokoll setzen.
Image :latest verwendet: unerwartete Breaking Changes → Version pinnen und Rollback bereithalten.
Keine Verschlüsselung der Credentials: N8N_ENCRYPTION_KEY fehlt → unbedingt setzen und sicher ablegen.
Oberfläche öffentlich ohne Schutz: Mindestens Basic Auth, besser Proxy/IP‑Allowlist oder Cloudflare Access.
Nur Volume gesichert, aber externe DB im Einsatz: Zusätzlich DB‑Dump sichern und Restore testen.

Checkliste (Start‑Defaults)

Compose mit Versions‑Pin, Healthcheck, benanntem Volume
.env mit N8N_ENCRYPTION_KEY + Basic‑Auth‑Credentials
TLS via Proxy oder Cloudflare Tunnel; WEBHOOK_URL korrekt
Regelmäßige Volume‑Backups + Rotation + Offsite
Update‑Routine: pull → up -d → Healthcheck, Rollback‑Plan vorhanden

FAQ

Reicht Basic Auth als alleinige Absicherung? Für private Setups oft ja. Besser: zusätzlich IP‑Allowlist oder Cloudflare Access.

Muss ich die Oberfläche öffentlich machen, um Webhooks zu empfangen? Nein. Mit Reverse‑Proxy/Router kannst du nur die benötigten Routen/Webhooks nach außen freigeben – oder einen Tunnel nutzen.

Wie sichere ich mich gegen Datenverlust durch Fehlbedienung? Backups versionieren, regelmäßige Restores testen und vor riskanten Änderungen Snapshots anlegen.

Fazit

Mit wenigen, klaren Defaults bekommst du eine robuste, sichere n8n‑Instanz: Versionen pinnen, Backups ernst nehmen, TLS/Access sauber setzen – und Updates bewusst fahren. So bleibt dein Automations‑Hub wartungsarm und zuverlässig.

Externe Referenzen:

Offizielle n8n Doku (Self‑Hosting): https://docs.n8n.io/hosting/
n8n Docker Images & Tags: https://hub.docker.com/r/n8nio/n8n/tags

n8n Self‑Hosting: Docker Compose, Backups, Updates & Sicherheit