n8n self-hosted – Installation mit Docker Schritt für Schritt

n8n lässt sich mit Docker Compose und überschaubarem Aufwand auf einem eigenen Server betreiben, mit Postgres als Datenbank und Caddy als Reverse Proxy für automatisches HTTPS. Sie brauchen dafür einen Linux-VPS, eine Subdomain und grundlegende Kenntnisse der Kommandozeile. Diese Anleitung führt Schritt für Schritt durch Installation, Umgebungsvariablen, Updates, Backups und Basis-Absicherung; die Konfigurationsdateien können Sie direkt übernehmen.

Self-hosted oder n8n Cloud?

Bevor Sie installieren, lohnt eine ehrliche Abwägung. Self-Hosting spart Lizenzkosten, verlagert aber Verantwortung zu Ihnen.

Kriterium	Self-hosted (Community Edition)	n8n Cloud
Kosten	Server und Domain, dazu eigene Arbeitszeit	Monatlicher Tarif, abgerechnet nach Workflow-Ausführungen
Wartung	Updates, Backups und Sicherheit liegen bei Ihnen	Übernimmt n8n
Datenhaltung	Auf Ihrem Server bei einem Hoster Ihrer Wahl	Bei n8n
Community-Nodes	Frei installierbar	Eingeschränkt auf geprüfte Nodes
Skalierung	Selbst planen, bis hin zum Queue-Modus	Je nach Tarif

Self-Hosting passt, wenn Sie Daten im eigenen Einflussbereich halten wollen, viele Ausführungen erwarten oder Community-Nodes brauchen, und wenn jemand im Team die Wartung zuverlässig übernimmt. Einen Überblick, wo n8n im Zusammenspiel mit CRM und Marketing Automation steht, gibt der Ratgeber Marketing Automation im B2B.

Voraussetzungen

• VPS mit aktuellem Linux, etwa Ubuntu LTS oder Debian, als Ausgangspunkt 2 vCPUs und 2 bis 4 GB RAM
• Subdomain wie n8n.ihre-domain.de mit einem A-Record auf die IP-Adresse des Servers
• Offene Ports 80 und 443 für HTTP und HTTPS
• SSH-Zugang mit Schlüssel statt Passwort
• Docker Engine und Docker Compose v2

Schritt 1 – Server vorbereiten

Aktualisieren Sie das System und installieren Sie Docker. Das Installationsskript von Docker richtet Engine und Compose-Plugin gemeinsam ein:

sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
docker compose version

Aktivieren Sie anschließend die Firewall und lassen Sie nur SSH, HTTP und HTTPS zu:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Wichtig: Docker veröffentlicht Ports an der ufw-Firewall vorbei. Deshalb geben Sie in der Compose-Datei später nur die Ports von Caddy frei, nicht die von n8n oder Postgres.

Schritt 2 – Projektordner und .env anlegen

Legen Sie einen Projektordner an und erzeugen Sie zwei Zufallswerte, einen für den Verschlüsselungsschlüssel von n8n und einen für das Datenbankpasswort:

mkdir -p ~/n8n && cd ~/n8n
openssl rand -hex 32
openssl rand -hex 24

Erstellen Sie dann die Datei .env mit Ihren Werten:

N8N_DOMAIN=n8n.ihre-domain.de
N8N_VERSION=stable
GENERIC_TIMEZONE=Europe/Berlin
N8N_ENCRYPTION_KEY=erster-zufallswert
POSTGRES_USER=n8n
POSTGRES_PASSWORD=zweiter-zufallswert
POSTGRES_DB=n8n

Schützen Sie die Datei mit chmod 600 .env. Der N8N_ENCRYPTION_KEY verschlüsselt alle gespeicherten Zugangsdaten. Geht er verloren, sind die Credentials in einem wiederhergestellten Backup nicht mehr lesbar. Statt stable sollten Sie für den Produktivbetrieb eine konkrete Versionsnummer aus den Release Notes eintragen.

Schritt 3 – docker-compose.yml erstellen

Die Compose-Datei definiert drei Dienste: Postgres, n8n und Caddy. Nur Caddy ist von außen erreichbar.

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

  n8n:
    image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
    restart: unless-stopped
    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_HOST: ${N8N_DOMAIN}
      N8N_PORT: "5678"
      N8N_PROTOCOL: https
      N8N_WEBHOOK_URL: https://${N8N_DOMAIN}/
      N8N_EDITOR_BASE_URL: https://${N8N_DOMAIN}/
      N8N_PROXY_HOPS: "1"
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: "true"
      GENERIC_TIMEZONE: ${GENERIC_TIMEZONE}
      TZ: ${GENERIC_TIMEZONE}
      NODE_ENV: production
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      N8N_DOMAIN: ${N8N_DOMAIN}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - n8n

volumes:
  db_data:
  n8n_data:
  caddy_data:
  caddy_config:

Die Caddyfile im selben Ordner ist kurz. Caddy holt das TLS-Zertifikat automatisch und setzt die Weiterleitungs-Header, die n8n hinter einem Proxy erwartet:

{$N8N_DOMAIN} {
    reverse_proxy n8n:5678
}

Die wichtigsten Umgebungsvariablen

• N8N_HOST, N8N_PROTOCOL, N8N_PORT: Hostname, Protokoll und interner Port von n8n.
• N8N_WEBHOOK_URL: Öffentliche Basis-URL für Webhooks. Ältere Anleitungen nennen hier WEBHOOK_URL. Laut Dokumentation ist dieser Name seit n8n 2.35 veraltet, funktioniert aber weiter als Alias.
• N8N_PROXY_HOPS: Anzahl der vorgeschalteten Proxys, hier 1 für Caddy.
• N8N_ENCRYPTION_KEY: Schlüssel für die Verschlüsselung der Credentials.
• GENERIC_TIMEZONE und TZ: Zeitzone für Zeitpläne und Logs. Ohne diese Angabe laufen Schedule-Trigger in der Standardzeitzone von n8n, die nicht Europe/Berlin ist.

Das Image docker.n8n.io/n8nio/n8n ist identisch mit n8nio/n8n auf Docker Hub, das die aktuelle Dokumentation verwendet. Alle Variablen beschreibt die n8n-Dokumentation zu Umgebungsvariablen, die Proxy-Einstellungen erklärt die Seite zu Webhook-URLs hinter einem Reverse Proxy.

Schritt 4 – Starten und Owner-Konto anlegen

docker compose up -d
docker compose ps
docker compose logs -f n8n

Sobald die Logs melden, dass der Editor erreichbar ist, öffnen Sie Ihre Subdomain im Browser. Legen Sie sofort das Owner-Konto an: Wer die Ersteinrichtung zuerst abschließt, wird Eigentümer der Instanz. Aktivieren Sie danach die Zwei-Faktor-Authentifizierung für Ihr Konto.

Updates einspielen

n8n veröffentlicht häufig neue Versionen. Planen Sie Updates bewusst und nicht automatisch:

1. Backup erstellen, wie im nächsten Abschnitt beschrieben.
2. Release Notes auf Breaking Changes prüfen.
3. Neue Versionsnummer in N8N_VERSION eintragen.
4. Image laden und Container neu starten:

cd ~/n8n
docker compose pull
docker compose down
docker compose up -d

Für Postgres gilt eine Ausnahme: Ein Sprung auf eine neue Hauptversion gelingt nicht durch einfaches Ändern des Image-Tags. Dafür ist ein Dump mit anschließendem Import nötig. Alle Varianten für n8n selbst beschreibt die Update-Anleitung von n8n.

Backups richtig aufsetzen

Laut n8n-Dokumentation zu Backups besteht ein vollständiges Backup aus zwei Teilen: der Datenbank und dem Ordner .n8n, der unter anderem die Konfiguration mit dem Verschlüsselungsschlüssel enthält. Sichern Sie außerdem .env, docker-compose.yml und die Caddyfile.

mkdir -p ~/n8n-backups && cd ~/n8n
docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \
  > ~/n8n-backups/n8n-db-$(date +%F).dump
docker run --rm -v n8n_n8n_data:/data -v "$HOME/n8n-backups:/backup" alpine \
  tar czf /backup/n8n-data-$(date +%F).tar.gz -C /data .

Der Volume-Name setzt sich aus Projektordner und Volume zusammen, prüfen Sie ihn mit docker volume ls. Zusätzlich können Sie Workflows und Credentials als JSON exportieren, etwa für Versionierung:

docker compose exec -u node n8n n8n export:workflow --backup --output=/home/node/.n8n/backups/workflows/
docker compose exec -u node n8n n8n export:credentials --backup --output=/home/node/.n8n/backups/credentials/

Automatisieren Sie die Sicherung per Cronjob, kopieren Sie die Dateien auf ein zweites System außerhalb des Servers und testen Sie die Wiederherstellung mindestens einmal. Ein Backup, das nie zurückgespielt wurde, ist nur eine Hoffnung.

Sicherheit – Basis-Härtung

• SSH absichern: Login nur per Schlüssel, Passwort-Login und Root-Login deaktivieren.
• Ports minimieren: Nur 80 und 443 über Caddy, keine veröffentlichten Ports für n8n oder Postgres.
• Updates: Betriebssystem, Docker und n8n regelmäßig aktualisieren, Sicherheitsupdates zeitnah.
• Konten: Starke Passwörter, Zwei-Faktor-Authentifizierung und nur so viele Nutzer wie nötig.
• Community-Nodes: Nur Pakete installieren, deren Herkunft Sie kennen. Sie laufen mit den Rechten Ihrer Instanz.
• Ausführungsdaten begrenzen: n8n löscht alte Ausführungen standardmäßig nach einer festen Frist. Mit EXECUTIONS_DATA_MAX_AGE in Stunden passen Sie diese an, etwa wenn Workflows personenbezogene Daten verarbeiten.
• Geheimnisse schützen: .env und Backups nie in öffentliche Repositories, Backups verschlüsselt ablegen.

Häufige Probleme und Lösungen

• Webhook-URLs zeigen localhost oder Port 5678: N8N_WEBHOOK_URL fehlt oder ist falsch gesetzt. Tragen Sie die öffentliche HTTPS-Adresse mit abschließendem Schrägstrich ein und starten Sie n8n neu.
• Caddy erhält kein Zertifikat: Meist zeigt der DNS-Eintrag noch nicht auf den Server oder Port 80 beziehungsweise 443 ist blockiert. Die Ursache steht in docker compose logs caddy.
• Zeitpläne laufen zur falschen Uhrzeit: GENERIC_TIMEZONE fehlt. Setzen Sie die Variable, starten Sie den Container neu und prüfen Sie zusätzlich die Zeitzone in den Einstellungen des jeweiligen Workflows.
• Credentials nach Wiederherstellung unlesbar: Der Verschlüsselungsschlüssel stimmt nicht mit dem der Sicherung überein. Spielen Sie den alten N8N_ENCRYPTION_KEY beziehungsweise den gesicherten .n8n-Ordner zurück.
• n8n startet nicht, Datenbankfehler im Log: Postgres ist noch nicht bereit oder die Zugangsdaten in .env stimmen nicht. Der Healthcheck in der Compose-Datei verhindert den ersten Fall.
• Code-Node langsam oder speicherhungrig: n8n führt Code in sogenannten Task Runnern aus. Für stärkere Isolation und mehr Kontrolle beschreibt die Dokumentation einen separaten Runner-Container.

Kosten – self-hosted und Cloud im Vergleich

Kleine VPS bei europäischen Hostern liegen im einstelligen bis niedrigen zweistelligen Eurobereich pro Monat, Stand 2026. Hinzu kommen Domain und Backup-Speicher. Der größte Posten ist meist nicht der Server, sondern die Zeit für Wartung, Updates und Fehlersuche. n8n Cloud rechnet nach Tarif und Anzahl der Workflow-Ausführungen ab und nimmt Ihnen diese Arbeit ab. Für wenige, einfache Workflows ist die Cloud oft wirtschaftlicher, bei vielen Ausführungen oder strengen Anforderungen an die Datenhaltung kippt die Rechnung zugunsten des Self-Hostings. Wie Sie Automatisierungskosten insgesamt bewerten, zeigt der Ratgeber Marketing-Automation-Kosten. Preise ändern sich, prüfen Sie den aktuellen Stand direkt bei den Anbietern.

Auch beim Datenschutz ersetzt Self-Hosting keine Prüfung. Schließen Sie mit dem Hoster einen Auftragsverarbeitungsvertrag und prüfen Sie jeden angebundenen Dienst, siehe DSGVO im B2B-Marketing.

Fazit und nächster Schritt

Mit Docker Compose, Postgres und Caddy steht eine produktionstaugliche n8n-Instanz mit automatischem HTTPS in überschaubarer Zeit. Entscheidend für den dauerhaften Betrieb sind feste Versionen, geplante Updates, getestete Backups und eine schlanke Angriffsfläche. Sobald die Instanz läuft, können Sie mit dem ersten produktiven Workflow starten, etwa dem n8n-Workflow zur Leadliste, der Firmendaten über Apify sammelt und angereichert an Ihr CRM übergibt. Den strategischen Rahmen liefert die Übersicht Marketing Automation und CRM.