Self-hosted n8n in Docker: Einsteiger-Guide

10 Min. Lesezeit KIro
n8n Docker GuideSelf-Hosted n8nn8n InstallierenDockerDevOpsPostgres

Sie wollen n8n selbst hosten, aber ohne langes Herumprobieren? Dieser Guide zeigt, wie Sie n8n mit Docker produktionsreif aufsetzen – sicher, wiederholbar und updatefähig.

Wir bauen eine robuste Basis mit Postgres, richten einen Reverse Proxy mit SSL ein, klären Backup-Strategien und zeigen häufige Stolperfallen. Ideal für IT-Verantwortliche, die technische Kontrolle, Compliance und Skalierbarkeit brauchen.

Am Ende haben Sie ein betriebsfertiges Setup, das Sie in Minuten reproduzieren und in Stunden produktionsreif machen können.

TL;DR

  • Production-Setup: n8n + Postgres in Docker Compose, davor ein Reverse Proxy (HTTPS).
  • Unbedingt setzen: N8N_ENCRYPTION_KEY, Basic Auth am Proxy, regelmäßige DB-Backups.
  • Webhooks korrekt terminieren: N8N_HOST, N8N_PROTOCOL, WEBHOOK_URL passend zur externen URL.
  • Updates: Image taggen, compose pull, compose up -d, vorher Backup.
  • Skalierung: Queue Mode mit Redis und Workern; sonst Single-Node reicht fürs MVP.
  • Suchintention abgedeckt: „n8n docker guide“, „self hosted n8n“, „n8n installieren auf dem Server“.

Was bedeutet self-hosted n8n? (Definition)

Self-hosted n8n bedeutet, dass Sie die n8n-Automatisierungsplattform in Ihrer eigenen Infrastruktur (z. B. VM oder Bare Metal) betreiben, inklusive Datenhaltung, Security, Updates und Monitoring. Sie behalten damit volle Kontrolle über Datenflüsse, Integrationen und Compliance-Rahmen – im Gegensatz zu SaaS, wo Betrieb und Updates der Anbieter verantwortet.

Architektur-Optionen im Überblick

Die passende Betriebsform hängt von Sicherheitsanforderungen, Last und Teamgröße ab.

BetriebsmodellKomponentenEignungVorteileHinweise
Single-Node (Docker)n8n-Container + PostgresPilot, kleine TeamsSchnell, einfach, geringe KostenDowntime bei Updates; Scale-up statt Scale-out
Single-Node hinter Proxyn8n + Postgres + Reverse Proxy (Nginx/Traefik/Caddy)ProduktionHTTPS, Header-Security, RoutingKorrektes URL- und Proxy-Setup nötig
Queue Mode (Skalierung)n8n Main + Redis + Worker + PostgresHöhere Last, kritische SLAsHorizontal skalierbar, isolierte JobsKomplexer Betrieb, zusätzliches Monitoring

Praxis-Tipp: Starten Sie mit Single-Node, standardisieren Sie Backups und Updates, und wechseln Sie erst bei echter Last in den Queue Mode.

Voraussetzungen und Planung

  • Infrastruktur:
    • 2–4 vCPU, 4–8 GB RAM für den Start (abhängig von Workflows/Integrationen).
    • Öffentliche DNS-Domain (z. B. automation.example.com).
    • Offene Ports: 80/443 am Proxy, intern 5678 für n8n, 5432 für Postgres.
  • Software:
    • Aktuelles Docker und Docker Compose/Compose V2.
  • Sicherheit/Compliance:
    • Secrets Management (z. B. Docker Secrets, Vault).
    • Backup- und Restore-Prozess getestet.
    • Zugriffsschutz (VPN, IP-Restriktionen, Basic Auth/SSO am Proxy).

Schritt-für-Schritt: n8n in Docker installieren

So installieren Sie n8n auf dem Server – kompakt und reproduzierbar.

1) Verzeichnis und .env anlegen

mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32 > .encryption_key
cat > .env <<'EOF'
# Domain und Basis-URL
N8N_HOST=automation.example.com
N8N_PROTOCOL=https
N8N_PORT=5678
WEBHOOK_URL=https://automation.example.com/
# Sicherheit
N8N_ENCRYPTION_KEY=$(cat .encryption_key)
N8N_BASIC_AUTH_ACTIVE=true
N8N_BASIC_AUTH_USER=admin
N8N_BASIC_AUTH_PASSWORD=BitteSetzen123!
# Datenbank
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=BitteSetzenDB!
TZ=Europe/Berlin
EOF

Praxis-Tipp: Legen Sie Passwörter in Docker Secrets oder einem Vault ab. Die obige .env ist für Lab-Setups – in Produktion Secrets nie im Klartext versionieren.

2) Docker-Compose erstellen (n8n + Postgres)

# docker-compose.yml
version: "3.9"

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

  n8n:
    image: n8nio/n8n:latest
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=${N8N_HOST}
      - N8N_PORT=${N8N_PORT}
      - N8N_PROTOCOL=${N8N_PROTOCOL}
      - WEBHOOK_URL=${WEBHOOK_URL}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_BASIC_AUTH_ACTIVE=${N8N_BASIC_AUTH_ACTIVE}
      - N8N_BASIC_AUTH_USER=${N8N_BASIC_AUTH_USER}
      - N8N_BASIC_AUTH_PASSWORD=${N8N_BASIC_AUTH_PASSWORD}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - GENERIC_TIMEZONE=${TZ}
    volumes:
      - n8n_data:/home/node/.n8n
    restart: unless-stopped

volumes:
  n8n_data:
  pg_data:

Praxis-Tipp: Pinnen Sie Images auf geprüfte Versionen (z. B. n8nio/n8n:1.76.x), um Überraschungen bei Minor-Releases zu vermeiden.

3) Starten und testen

docker compose pull
docker compose up -d
# Erreichbarkeit prüfen
curl -I https://automation.example.com/ || curl -I http://SERVER_IP:5678

Wenn Sie noch keinen Reverse Proxy haben, erreichen Sie n8n vorerst über Port 5678. Für Produktion sollten Sie zwingend einen Proxy mit HTTPS vorschalten.

Reverse Proxy und SSL (Nginx, Traefik oder Caddy)

Sie können jeden etablierten Proxy nutzen. Caddy ist für den Schnellstart angenehm, Traefik/Nginx geben maximale Kontrolle.

Beispiel Caddyfile (Auto-HTTPS)

# /etc/caddy/Caddyfile
automation.example.com {
  encode zstd gzip
  reverse_proxy 127.0.0.1:5678
  header {
    Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    X-Frame-Options "DENY"
    X-Content-Type-Options "nosniff"
    Referrer-Policy "no-referrer"
  }
}

Beispiel Nginx-Serverblock (vereinfacht)

server {
  listen 443 ssl http2;
  server_name automation.example.com;

  ssl_certificate /etc/letsencrypt/live/automation.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/automation.example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:5678;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-For $remote_addr;
  }
}

Praxis-Tipp: Setzen Sie am Proxy zusätzlich Basic Auth oder IP-Allowlists für den Editor. Webhooks können Sie gezielt per Pfad/IP freigeben.

Best Practices für Produktion

  • Sicherheit
    • Setzen Sie N8N_ENCRYPTION_KEY vor dem ersten Start und ändern Sie ihn nie ohne Migrationsplan.
    • Aktivieren Sie Basic Auth oder SSO am Proxy; Editor-Zugriff nicht öffentlich indexierbar machen.
    • Least Privilege: API-Keys und Credentials nur mit notwendigen Scopes.
  • Stabilität
    • Postgres statt SQLite; regelmäßige VACUUM/Auto-VACUUM-Einstellungen beibehalten.
    • Logs zentralisieren (z. B. Loki/ELK); n8n-Log-Level auf warn/info setzen.
  • Konfiguration
    • N8N_HOST/N8N_PROTOCOL/WEBHOOK_URL konsistent zur externen URL.
    • Timezone korrekt setzen (GENERIC_TIMEZONE), um Trigger-Zeiten vorhersehbar zu halten.
  • Observability
    • Healthchecks in Compose beibehalten; Uptime-Monitoring auf /healthz bzw. Editor-URL.
    • Prometheus-/Alerting-Integration je nach Bedarf ergänzen.

Backups, Restore, Updates

Backup-Checkliste

  • Datenbank-Backup (voll + inkrementell je nach Tool).
  • n8n-App-Daten-Volume (/home/node/.n8n).
  • Export der .env/.encryption_key (aber nicht im Klartext in VCS).
  • Test-Restore mindestens auf einer Staging-VM.

Befehle (Beispiele)

# Postgres-Dump
docker exec -t $(docker ps -qf name=_db) \
  pg_dump -U ${POSTGRES_USER} ${POSTGRES_DB} > /backup/n8n_$(date +%F).sql

# Restore (vereinfacht)
cat /backup/n8n_YYYY-MM-DD.sql | docker exec -i $(docker ps -qf name=_db) \
  psql -U ${POSTGRES_USER} -d ${POSTGRES_DB}

# Updates
docker compose pull n8n
docker compose up -d n8n
docker image prune -f

Praxis-Tipp: Führen Sie Schema-Änderungen mit Staging-Update + Smoke-Tests (kritische Flows manuell anstoßen) durch. Erst danach Produktion aktualisieren.

Skalierung: Queue Mode (Kurzüberblick)

Wenn Workflows lange laufen oder viele Webhooks gleichzeitig ankommen, nutzen Sie den Queue Mode:

  • Ergänzungen: Redis (Queue) und ein oder mehrere Worker-Container.
  • Main-Container nimmt Webhooks an, Worker verarbeiten Jobs asynchron.
  • Achten Sie auf Idempotenz Ihrer Flows und Timeout-/Retry-Strategien am Rand-System.

Typische Fehler und wie Sie sie vermeiden

  • Falsche URL-Variablen: Webhooks funktionieren nicht, wenn N8N_HOST/WEBHOOK_URL nicht zur externen Domain passen.
  • Keine Verschlüsselung: Ohne N8N_ENCRYPTION_KEY sind gespeicherte Credentials ungeschützt.
  • SQLite in Produktion: Begrenzt robust; wechseln Sie frühzeitig auf Postgres.
  • Offener Editor im Internet: Immer via Reverse Proxy absichern und Indexierung blocken.
  • Kein Backup-Test: Backups ohne Restore-Test sind wertlos. Mindestens quartalsweise testen.

Häufige Fragen (FAQ)

Wie sind die Hardware-Anforderungen für self-hosted n8n?

Für ein kleines Team reichen oft 2–4 vCPU und 4–8 GB RAM. Entscheidend sind Anzahl/Komplexität der Workflows und externe API-Limits. Starten Sie klein und beobachten Sie CPU, RAM und I/O, bevor Sie skalieren.

Kann ich n8n komplett ohne Internet betreiben?

Ja, solange alle genutzten Integrationen On-Prem erreichbar sind. Updates und Container-Images müssen dann über ein internes Registry/Mirror bereitgestellt werden.

Wie sichere ich den Editor-Zugang am besten ab?

Reverse Proxy mit HTTPS + Basic Auth ist der Minimalstandard. Zusätzlich eignen sich IP-Allowlists, VPN-Zugang oder SSO am Proxy. In n8n selbst sollten Sie Nutzer- und Rollenverwaltung korrekt konfigurieren.

Wie aktualisiere ich n8n ohne lange Downtime?

Pinnen Sie Versionen, erstellen Sie vor Updates ein DB-Backup und führen Sie ein Rolling-Update durch (compose pull; compose up -d). Bei kritischen Systemen nutzen Sie Blue/Green mit zwei Stacks hinter dem Proxy.

Welche Datenbank ist empfohlen?

Für Produktion ist Postgres die erste Wahl. SQLite eignet sich für Tests, hat aber Nachteile bei Parallelität und Recovery. MySQL/MariaDB wird teils unterstützt, Postgres ist jedoch am verbreitetsten für n8n.

Wie setze ich Umgebungsvariablen korrekt?

Definieren Sie N8N_HOST, N8N_PROTOCOL, N8N_PORT und WEBHOOK_URL konsistent. Stellen Sie DB_* Variablen für Postgres ein und vergeben Sie einen starken N8N_ENCRYPTION_KEY. Nutzen Sie .env/Secrets statt Klartext im Compose.

Kann ich n8n hinter einem vorhandenen Nginx/Traefik betreiben?

Ja. Routen Sie die Domain/den Pfad auf den n8n-Port 5678 und setzen Sie Forwarded-Header korrekt. Denken Sie an WebSockets-Unterstützung und an Security-Header.

Wie richte ich Backups ein?

Sichern Sie regelmäßig die Postgres-Datenbank und das n8n-Daten-Volume. Automatisieren Sie Dumps (z. B. täglich) und lagern Sie sie verschlüsselt aus. Testen Sie den Restore-Prozess wiederkehrend.

Wie gehe ich mit sensiblen Credentials um?

Speichern Sie Secrets verschlüsselt (ENCRYPTION_KEY), begrenzen Sie Berechtigungen und rotieren Sie Tokens zyklisch. Nutzen Sie, wenn möglich, einen zentralen Secret Store und binden Sie ihn per Umgebungsvariablen ein.

Wie erreiche ich bessere Performance bei vielen Webhooks?

Nutzen Sie den Queue Mode mit Redis und skalieren Sie Worker horizontal. Zusätzlich: Caching, Idempotenz, kurze Timeout-Werte und Backpressure über den Proxy.

Fazit

Mit Docker, Postgres und einem sauberen Proxy-Setup bringen Sie self-hosted n8n schnell und sicher in Produktion. Der Schlüssel sind saubere URL-Variablen, ein gesetzter ENCRYPTION_KEY, konsequente Backups und ein klarer Update-Prozess.

Wenn Sie n8n für Ihr Unternehmen evaluieren oder produktionsreif machen wollen, bieten wir Architektur-Reviews und Workshops für IT-Teams an. Kontaktieren Sie uns für einen kurzen Vorab-Check Ihrer Umgebung – wir liefern Best Practices, Hardening-Empfehlungen und einen skalierbaren Fahrplan.

Lasst uns über eure Zukunft sprechen

Habt ihr eine Idee, ein Projekt oder einfach eine Frage? Wir freuen uns auf eure Nachricht und melden uns innerhalb von 24 Stunden bei euch.

104+ Jahre Erfahrung im Team
50+ Erfolgreiche Projekte
30+ Zufriedene Kunden
Kostenlose Erstberatung
Antwort innerhalb von 24h
Unverbindlich & vertraulich

Beschreibe kurz welchen Bereich du automatisieren möchtest oder welche System du verbinden willst.

Eure Nachricht wird von unserem Vinspire KI Agent "John" bearbeitet und an das passende Team weitergeleitet.