Selbstgehostetes n8n: So betreibst du n8n auf deinem eigenen Server

Seit sechs Monaten siehst du zu, wie deine Zapier-Rechnung steigt.

Jeder neue Workflow bringt einen weiteren Rechnungsposten, und jeder erfolgreiche Aktionsschritt zählt als Task. Die monatliche Rechnung ist inzwischen höher als die für dein Projektmanagement-Tool.

Du googelst nach Alternativen und landest bei n8n, einer Automatisierungsplattform, die du zum Preis eines kleinen Servers auf deinem eigenen Virtual Private Server (VPS) selbst hosten kannst.

Kein Ausführungskontingent. Keine Preise pro Task. Keine bösen Überraschungen auf der Rechnung, wenn deine Automatisierungen richtig loslegen.

Und ja, wir führen dich durch alles, Befehl für Befehl: vom nackten Ubuntu-Server bis zur laufenden Instanz mit HTTPS, Backups und einer getesteten Wiederherstellung.

Was ist n8n und warum hosten es so viele selbst?

n8n ist eine Plattform zur Workflow-Automatisierung. Damit verbindest du Apps, verschiebst Daten zwischen Diensten und baust komplexe Automatisierungen in einem visuellen Editor. Stell sie dir als den Motor hinter Wenn X passiert, mach Y und Z vor. Der Unterschied: Du ziehst Nodes und zeichnest Verbindungen, statt Code zu schreiben.

Das Projekt hat die Marke von 200.000 GitHub-Sternen überschritten, und das offizielle Docker-Image verzeichnet über 100 Millionen Pulls. Da draußen laufen also jede Menge Server mit n8n.

Die Plattform steht unter einer Sustainable Use License, die du verstehen solltest, bevor du dich festlegst. Es ist kein klassisches Open Source: n8n selbst verwendet den Begriff nicht, da OSI-zertifizierte Lizenzen die Nutzung nicht einschränken dürfen. Abgeschottet ist die Software aber auch nicht. Für deine eigenen internen Geschäftszwecke kannst du sie frei nutzen. Verkaufen darfst du dagegen kein Produkt, keinen Dienst und kein Modul, dessen Wert ganz oder im Wesentlichen auf n8n-Funktionen beruht.

Viele entscheiden sich, n8n selbst zu hosten, weil sich die Rechnung umdreht, sobald du über die Grundnutzung hinauskommst. n8n Cloud beginnt bei 20 €/Monat (jährliche Abrechnung) für 2.500 Ausführungen im Starter-Plan. Bei echtem Volumen stößt du schnell an diese Grenzen.

Und auf deinem eigenen VPS? Kein Ausführungskontingent, Kontrolle über die Daten, die deine n8n-Instanz speichert, und keine Lizenz- oder Ausführungsrechnung von n8n. Server, Domain, Backup-Speicher und Administration kosten aber trotzdem etwas. Die Ausführungen selbst kosten nichts extra. Mehr Volumen braucht allerdings mehr Arbeitsspeicher und Speicherplatz. Das ist eine Frage der Dimensionierung (siehe unten), nicht der Abrechnung.

Was kannst du mit n8n automatisieren?

Die über 400 Integrationen von n8n decken ein breites Spektrum ab, und Nodes aus der Community erweitern die Liste noch. n8n ist außerdem nur eine von vielen selbstgehosteten Alternativen zu SaaS-Tools. Dieselbe Logik gilt für alles von CRM bis Projektmanagement.

Einige gängige Setups:

• CRM und Lead-Routing. Synchronisiere Kontakte zwischen deinem CRM, deiner E-Mail-Plattform und Slack, sobald neue Leads eingehen.
• Webhook-gesteuerte Workflows. Reagiere in Echtzeit auf Ereignisse von Zahlungsanbietern, Formularübermittlungen oder GitHub-Commits.
• Automatisierte Datenpipelines. Hol dir Daten aus APIs, wandle sie um und schreibe sie nach Zeitplan in Datenbanken oder Tabellen.
• KI-Agenten-Ketten. Verbinde LLMs mit deinen internen Tools und baue eigene KI-Assistenten, die deine Daten durchsuchen, zusammenfassen und darauf reagieren können.

(Beim letzten Punkt fangen deine Serverressourcen an, eine Rolle zu spielen. Mehr dazu im Abschnitt zu den Spezifikationen.)

Was kostet es, n8n selbst zu hosten?

Für die selbstgehostete Community Edition fallen bei erlaubter Nutzung keine Lizenz- oder Ausführungsgebühren von n8n an. Deine Gesamtkosten umfassen den Server sowie gegebenenfalls Domain, Backup-Speicher und den Zeitaufwand für die Administration. Die Kostenaufstellung 2026 von ExpressTech beziffert ein einfaches VPS mit Docker auf 4–5 $ pro Monat, ein mit Coolify verwaltetes VPS auf 5–8 $ und verwaltete Ein-Klick-Plattformen für n8n auf 3–7 $.

Das sind Hosting-Schätzungen des Drittanbieters ExpressTech. Hier eine Zahl aus erster Hand: Der Plan, den wir unten empfehlen, DreamHost VPS Hosting Stack 4, kostet bei monatlicher Abrechnung in den ersten 3 Monaten 8,99 $/Monat. Danach verlängert er sich automatisch zu 15,99 $/Monat (Stand August 2026). Die gesamte Laufzeit plus Steuern wird beim Checkout berechnet. Die aktuellen Preise findest du auf der n8n-VPS-Seite.

Vergleiche das mit den gehosteten und lizenzierten Plänen von n8n selbst, wie sie auf der Preisseite von n8n stehen. n8n rechnet in Euro ab. Das hier sind die Preise bei jährlicher Abrechnung:

Der Abstand wird noch größer, wenn du berücksichtigst, wie jede Plattform die Nutzung zählt. n8n berechnet eine Ausführung pro Workflow-Durchlauf, regardless of complexity,, und jeder Plan enthält unlimitierte Schritte. Zapier dagegen zählt jeden erfolgreichen Aktionsschritt als Task.

Ein Workflow mit vier Aktionsschritten, der 100-mal am Tag läuft, ergibt also 3.000 n8n-Ausführungen pro Monat, aber rund 12.000 Zapier-Tasks.

Echte Zahlen bestätigen das. Die Analyse von ExpressTech rechnet ein Beispiel mit vier Workflows und insgesamt etwa 7.000 Ausführungen pro Monat durch. Dieser Workload ist zu groß für n8n Cloud Starter und braucht den Pro-Tarif (dort mit 60 $/Monat bei monatlicher Abrechnung angegeben). Ein selbstgehostetes Setup für 3–7 $/Monat bewältigt ihn dagegen ohne Limits. ExpressTech beziffert den Unterschied auf 636–684 $ pro Jahr.

Die versteckten Kosten des Selbsthostens

Die Ersparnis ist real. Aber selbst zu hosten ist nicht in jeder Hinsicht kostenlos.

Das kostet es dich:

Deine Zeit. Der Wartungsaufwand hängt von deinem Workload und deiner Erfahrung im Serverbetrieb ab. Du bist aber für Updates, Backups, Monitoring und Wiederherstellungstests verantwortlich. Aufwendigere Setups mit KI-gestützten Automatisierungen verlangen mehr.

Hürden beim OAuth-Setup. Um Dienste wie Google Workspace oder Microsoft 365 zu verbinden, musst du OAuth-Zugangsdaten konfigurieren. Plane für jeden Anbieter zusätzliche Einrichtungszeit ein und halte dich an die Dokumentation seiner Konsole. (Wenn du schon mal auf einen Ladekreisel gestarrt hast, während ein Zustimmungsbildschirm überlegt, ob er deiner App vertraut, kennst du das Gefühl.)

TLS: Vertrauen ist gut, Kontrolle ist besser. Der Caddy-Proxy im folgenden Setup bezieht und erneuert automatisch ein öffentlich vertrauenswürdiges Zertifikat über einen Aussteller wie Let’s Encrypt oder ZeroSSL. Automatisch heißt aber nicht unfehlbar: Prüfe nach Änderungen an DNS oder Proxy, ob sich das Zertifikat weiterhin erneuert.

Einarbeitung, wenn Server neu für dich sind. Die folgende Anleitung setzt voraus, dass du dich per SSH auf einem Server anmelden, eine Datei bearbeiten und Befehle ausführen kannst. Wenn du das noch nie gemacht hast, plane zusätzlich zum Deployment Zeit zum Lernen ein.

Welche Serverspezifikationen braucht n8n?

n8n selbst ist schlank. Am nächsten an eine offizielle Dimensionierung kommen die Beispielwerte in der OEM-Deployment-Dokumentation von n8n. n8n kennzeichnet sie als for illustrative purposes only,, und sie basieren auf n8n Cloud: ein Arbeitsspeicherbereich von 320 MB bis 2 GB, eine SSD-gestützte Datenbank mit 512 MB bis 4 GB und rund 100 MB Arbeitsspeicher für eine Instanz im Leerlauf. Als vorsichtige Startgröße, nicht als offizielles Minimum von n8n, kannst du 2 GB zum Testen einplanen. Sobald PostgreSQL und Produktions-Workflows dazukommen, solltest du mit 4 GB rechnen. Überwache repräsentative Workflows und erweitere den Arbeitsspeicher, wenn er dauerhaft knapp wird.

Denk außerdem daran, dass n8n meist eher durch den Arbeitsspeicher als durch die CPU begrenzt wird. Die Dokumentation von n8n sagt es klar: Die Plattform ist isn’t CPU intensive,, und usually, memory requirements supersede CPU requirements.. Was den Speicherbedarf in die Höhe treibt, sind deine Workflows: das Datenvolumen, Code-Nodes (die Daten vor und nach der Verarbeitung kopieren) und große Binärdateien.

Hier unsere schnelle Überschlagsrechnung für ausreichend Reserven:

Dimensioniere nach der Anzahl gleichzeitiger Ausführungen und dem Datenvolumen, das jeder Workflow verarbeitet. Überwache dann die Speichernutzung unter einem repräsentativen Workload. Code-Nodes und große binäre Payloads können den Speicherbedarf erhöhen. Plane also Reserven ein und skaliere das VPS, wenn das Monitoring dauerhaft hohe Auslastung zeigt.

Neu bei VPS-Hosting? Beginne mit dem Einsteigerleitfaden zu VPS von DreamHost, um die Grundlagen zu verstehen, bevor du deinen Server dimensionierst.

Welchen VPS solltest du für selbstgehostetes n8n wählen?

n8n veröffentlicht keine festen RAM-Stufen je Workload. Dimensioniere nach gleichzeitigen Ausführungen und Datenvolumen und plane Reserven für Docker und PostgreSQL ein. Überwache dann repräsentative Workflows und skaliere, wenn der Speicher dauerhaft knapp ist.

So würden wir das auf die Pläne von DreamHost übertragen:

Neben dem RAM lohnt es sich, auf ein paar weitere Spezifikationen zu achten: n8n nennt SSD-Speicher als Best Practice für die Datenbank. Der Bedarf an Arbeitsspeicher wiegt meist schwerer als der an CPU. Wo der Engpass tatsächlich liegt, hängt aber davon ab, wie viele Workflows gleichzeitig laufen, wie groß die Datenmengen sind und welche Nodes du nutzt. Unbegrenzte Bandbreite ist wichtig, wenn du webhook-lastige Workloads mit einem ständigen Strom eingehender HTTP-Anfragen betreibst.

Wähle eine Hosting-Umgebung, in der du Docker ausführen und Datenbank, Networking, persistenten Speicher und Reverse Proxy konfigurieren kannst. Klassisches Shared Hosting bietet dieses Maß an Kontrolle in der Regel nicht.

Die VPS-Hosting-Tarife von DreamHost erfüllen die wichtigsten Anforderungen (NVMe-SSD-Speicher, unbegrenzte Bandbreite, voller Root-Zugriff und Docker-Unterstützung). Außerdem ist n8n in der Bibliothek mit One-Click-Apps enthalten, vorinstalliert mit PostgreSQL und automatischem SSL, falls du dir die manuelle Einrichtung unten sparen möchtest.

Unsere Empfehlung für einen n8n-Server mit Produktions-Workflows ist Stack 8, der Plan, den unsere Seiten für Apps im Produktivbetrieb ausweisen. Stack 4 erfüllt die Startgröße von 4 GB für einen ersten, leichten Server. Stand August 2026 kostet er bei monatlicher Abrechnung in den ersten 3 Monaten 8,99 $/Monat und verlängert sich dann automatisch zu 15,99 $/Monat. Die gesamte Laufzeit plus Steuern wird beim Checkout berechnet. Die aktuellen Preise zeigt immer die n8n-VPS-Seite. Dieser Verlängerungspreis ist die ehrliche Zahl für den Vergleich mit den 20 €/Monat von n8n Cloud Starter.

Ach ja, und eine Sache solltest du dir für später merken: Wenn deine Nutzung wächst, unterstützt n8n den Queue-Modus. Diese Skalierungsarchitektur trennt die Hauptinstanz (UI, Trigger, Webhooks) von der Workflow-Ausführung. Redis dient dabei als Message Broker, und Worker-Instanzen arbeiten die Jobs ab. Die Dokumentation von n8n bezeichnet ihn als den Modus, der provides the best scalability..

Wie richtest du n8n auf einem VPS ein?

Das Deployment einer selbstgehosteten n8n-Instanz umfasst 11 Schritte: DNS, SSH-Härtung, eine Firewall, Docker, Secrets, eine Compose-Datei für den Stack aus drei Containern (n8n, PostgreSQL und Caddy), das Caddyfile, Start und Überprüfung, Updates, Backups und einen Wiederherstellungstest. Caddy ist unser Reverse Proxy, also der Server, der zwischen dem Internet und deiner Anwendung sitzt und sich um TLS und Routing kümmert. Wir liefern dir die Befehle für das grundlegende Deployment und für einen manuellen Backup-und-Wiederherstellungstest.

Die Befehle sind für Ubuntu 22.04 oder neuer gedacht. Ersetze an den angegebenen Stellen die Beispieldomain, die geheimen Werte, den Volume-Namen und die datierten Backup-Dateinamen. Die Docker-Compose-Dokumentation von n8n behandelt dieselben Schritte mit einem Traefik-Proxy, falls du lieber der Vorlage von n8n folgst.

Was du vor dem Start brauchst

• Ein VPS mit Root-Zugriff mit Ubuntu 22.04 oder neuer und mindestens 2 GB RAM (für den Produktivbetrieb empfehlen wir vorsichtshalber 4 GB)
• Ein Domainname, den du auf die IP-Adresse deines Servers verweisen lassen kannst (für TLS und den Zugriff auf den n8n-Editor)
• Grundkenntnisse im Terminal: Du solltest wissen, wie du dich per SSH mit einem Server verbindest, eine Datei bearbeitest und Befehle ausführst

Noch eine Voraussetzung, die auf keiner offiziellen Liste steht: Sichere deinen N8N_ENCRYPTION_KEY, sobald du ihn generierst. Deshalb erstellst du den Schlüssel in Schritt 5 vor dem ersten Start mit openssl rand -hex 32, statt n8n stillschweigend einen generieren zu lassen. Dieser Schlüssel verschlüsselt alle gespeicherten Zugangsdaten, also jeden API-Schlüssel, jedes OAuth-Token und jedes Datenbankpasswort, das du verbunden hast. Die Docker-Dokumentation von n8n warnt: Wenn der Schlüssel beim Start nicht gefunden wird, erstellt n8n einen neuen, und bestehende Zugangsdaten lassen sich nicht mehr entschlüsseln. Dann baust du jede einzelne Integration von Grund auf neu auf (und bereust so einige Entscheidungen). Kopiere ihn an einen sicheren Ort, getrennt von deinen Datenbank-Backups.

Falls dein Anbieter dir nur einen Root-Login gegeben hat, lege zuerst einen Benutzer für das Deployment an. Das geht über die Konsole des Anbieters oder eine Root-SSH-Sitzung. Erledige das, bevor du die lokalen SSH-Befehle in Schritt 2 ausführst:

adduser deploy
usermod -aG sudo deploy

Alles Folgende läuft als dieser Benutzer, bei Bedarf mit sudo.

Schritt 1: Domain auf den Server verweisen

Erstelle einen DNS-A-Record für eine eigene Subdomain (in dieser Anleitung durchgehend n8n.example.com), der auf die IP-Adresse deines Servers zeigt, genau so, wie es der Docker-Compose-Leitfaden von n8n beschreibt. Erledige das zuerst: Wenn sich der DNS-Eintrag noch nicht verbreitet hat, kann Caddy kein Zertifikat beziehen, und dein Browser zeigt womöglich einen Sicherheitsfehler statt des n8n-Editors an.

Schritt 2: SSH-Zugang absichern

Erzeuge auf deinem lokalen Rechner ein Schlüsselpaar (die OpenSSH-Dokumentation von Ubuntu empfiehlt ed25519) und kopiere es auf den Server:

ssh-keygen -t ed25519
ssh-copy-id deploy@your_server_ip

Prüfe, ob du dich mit dem Schlüssel anmelden kannst. Deaktiviere dann auf dem Server die Anmeldung per Passwort und als root und prüfe, was sshd tatsächlich durchsetzt:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
EOF
sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin) '

Das Präfix 00- ist Absicht. Laut dem sshd_config-Handbuch verwendet OpenSSH für jedes Schlüsselwort den ersten Wert, den es liest. Cloud-Server-Images bringen oft frühere Drop-in-Dateien im selben Verzeichnis mit (cloud-init etwa schreibt seine SSH-Einstellungen nach 50-cloud-init.conf). Nennst du deine Datei 99-hardening.conf, kann sich eines dieser Snippets stillschweigend durchsetzen. sshd -t prüft die Konfiguration auf Fehler; sshd -T gibt die effektiven Einstellungen aus, nachdem alle Dateien zusammengeführt wurden. Vergewissere dich, dass der letzte Befehl passwordauthentication no und permitrootlogin no ausgibt, bevor du weitermachst. Starte sshd dann neu:

sudo systemctl restart ssh.service

Die Dokumentation von Ubuntu warnt, dass eine fehlerhafte sshd-Konfiguration auf einem Remote-Server dich aussperren kann. Lass deine aktuelle Sitzung offen und teste in einem zweiten Terminal eine neue Anmeldung, bevor du irgendetwas schließt.

Schritt 3: Firewall aktivieren

Ubuntu liefert UFW (Uncomplicated Firewall) standardmäßig deaktiviert aus. Erlaube SSH, bevor du die Firewall aktivierst, damit sie deine eigene Sitzung nicht kappt:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable
sudo ufw status

Drei Ports, sonst nichts. Eine Docker-spezifische Warnung aus der Installationsdokumentation von Docker: Ports, die Docker auf dem Host veröffentlicht, umgehen die UFW-Regeln komplett. Deshalb veröffentlicht die Compose-Datei in Schritt 6 nur für Caddy Host-Ports: 80 und 443 sind die einzigen Container-Ports, die Compose veröffentlicht (SSH auf 22 ist ebenfalls offen). n8n und PostgreSQL erhalten überhaupt keine veröffentlichten Host-Ports.

Schritt 4: Docker und Docker Compose installieren

Installiere Docker Engine aus dem offiziellen apt-Repository von Docker, nicht über das Komfortskript get.docker.com, das die Docker-Dokumentation nur für Tests und Entwicklung empfiehlt. Zuerst die Voraussetzungen und der Signaturschlüssel von Docker:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Registriere als Nächstes das Repository selbst. Damit wird die Repository-Datei aus dem Ubuntu-Installationsleitfaden von Docker geschrieben, wobei dein Ubuntu-Release automatisch eingesetzt wird:

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Dann installieren und überprüfen:

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world

Wenn hello-world seine Bestätigungsmeldung ausgibt, sind Docker und das Compose-Plugin startklar.

Schritt 5: Projektverzeichnis und Secrets anlegen

Erstelle das Projektverzeichnis und generiere dann deinen Verschlüsselungsschlüssel. Lass n8n beim ersten Start nicht stillschweigend selbst einen erzeugen:

sudo mkdir -p /opt/n8n-compose
cd /opt/n8n-compose
openssl rand -hex 32

Kopiere die Ausgabe jetzt sofort an einen sicheren Ort außerhalb des Servers. Lege sie dann zusammen mit einem starken Datenbankpasswort in einer geschützten .env-Datei neben deiner Compose-Datei ab (Docker Compose liest sie automatisch ein). Ersetze beide Platzhalterwerte durch deine eigenen:

sudo tee /opt/n8n-compose/.env > /dev/null <<'EOF'
POSTGRES_PASSWORD=choose_a_strong_password
N8N_ENCRYPTION_KEY=paste_the_64_character_key_you_just_generated
EOF
sudo chmod 600 /opt/n8n-compose/.env

Auf chmod 600 kommt es an: Diese Datei enthält Secrets, daher sollte nur ihr Eigentümer (root) sie lesen können. In der Compose-Datei setzt N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true dieselbe Idee innerhalb des Containers um: Laut der Referenz der Sicherheitsvariablen von n8n versucht n8n damit, für die eigene Einstellungsdatei die Berechtigungen 0600 zu setzen.

Schritt 6: Docker-Compose-Datei schreiben

Erstelle /opt/n8n-compose/docker-compose.yml (zum Beispiel mit sudo nano /opt/n8n-compose/docker-compose.yml) und füge Folgendes ein. Ersetze dabei in beiden URL-Zeilen n8n.example.com durch deine eigene Domain und stelle deine Zeitzone ein:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.36.7
    restart: unless-stopped
    expose:
      - "5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://n8n.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - GENERIC_TIMEZONE=America/New_York
      - TZ=America/New_York
      - EXECUTIONS_DATA_MAX_AGE=168
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - n8n_data:/home/node/.n8n

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

volumes:
  caddy_data:
  caddy_config:
  n8n_data:
  postgres_data:

Fünf Details darin sind besonders wichtig:

• Das Image ist auf eine bestimmte Version festgelegt (2.36.7 ist laut der Installationsdokumentation von n8n zum Zeitpunkt des Schreibens das aktuelle stabile Release). Upgrades passieren also nur dann, wenn du es entscheidest.
• n8n veröffentlicht keinen Host-Port. Container im Compose-Netzwerk, einschließlich Caddy, können n8n erreichen, aber nicht über einen veröffentlichten Host-Port. Der Editor ist also nur über den Reverse Proxy erreichbar, niemals direkt aus dem Internet.
• Der Healthcheck lässt n8n auf PostgreSQL warten. Ein bloßes depends_on wartet nur darauf, dass der Container startet, nicht darauf, dass die Datenbank Verbindungen annimmt. Das Muster condition: service_healthy stammt direkt aus der Beispiel-Compose-Datei für Postgres von n8n, die ebenfalls PostgreSQL 18 bereitstellt.
• Das Paar N8N_WEBHOOK_URL / N8N_PROXY_HOPS ist hinter einem Proxy wichtig. Normalerweise baut n8n Webhook-URLs aus Protokoll, Host und Port zusammen. Laut der Dokumentation von n8n funktioniert das hinter einem Reverse Proxy nicht. Deshalb legst du die Webhook-URL manuell fest, damit n8n register the correct webhook URLs with external services,. Außerdem setzt du N8N_PROXY_HOPS auf 1 und stellst sicher, dass der Proxy die Header X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto weitergibt. (Auf derselben Seite steht, dass N8N_WEBHOOK_URL das ältere WEBHOOK_URL ersetzt, das ab n8n 2.35.0 veraltet ist.)
• TZ und GENERIC_TIMEZONE haben unterschiedliche Aufgaben. Laut der Docker-Dokumentation von n8n steuert GENERIC_TIMEZONE Zeitplan-Nodes wie Schedule, während TZ die Systemzeitzone des Containers festlegt (also das, was Befehle wie date anzeigen). Setze beide auf denselben Wert.

(Starte vom ersten Tag an mit PostgreSQL. Standardmäßig nutzt n8n SQLite, was für Tests funktioniert. Die Hosting-Vorlagen von n8n empfehlen für den Produktivbetrieb aber PostgreSQL, und eine spätere Migration ist schmerzhaft, und zwar auf die Art Hätte ich das bloß gleich richtig gemacht.)

Schritt 7: Caddyfile schreiben

Erstelle /opt/n8n-compose/Caddyfile mit deiner Domain (ersetze auch hier n8n.example.com):

n8n.example.com {
    reverse_proxy n8n:5678
}

Das ist schon die gesamte Reverse-Proxy-Konfiguration. Laut der Dokumentation zu automatischem HTTPS von Caddy bezieht und erneuert Caddy automatisch ein öffentlich vertrauenswürdiges Zertifikat über einen Aussteller wie Let’s Encrypt oder ZeroSSL und leitet HTTP auf HTTPS um. Voraussetzung ist, dass dein DNS-A-Record auf den Server zeigt und die Ports 80 und 443 offen sind (Schritte 1 und 3). Caddy ist außerdem einer der Reverse Proxys in den offiziellen Hosting-Beispielen von n8n.

Schritt 8: Starten und überprüfen

cd /opt/n8n-compose
sudo docker compose up -d
sudo docker compose ps

Warte, bis ps den postgres-Container als healthy und n8n als laufend anzeigt. Prüfe dann von einem beliebigen Rechner aus den Zugang:

curl -fsS -o /dev/null -w '%{http_code}' https://n8n.example.com/

Ein 2xx-Code (oder eine 3xx-Weiterleitung) bedeutet, dass Caddy TLS terminiert und n8n geantwortet hat. Bricht curl stattdessen mit einem Fehler ab, solltest du dir DNS, das Zertifikat oder die Container ansehen (sudo docker compose logs caddy und sudo docker compose logs n8n sind die ersten Anlaufstellen). Öffne https://n8n.example.com in einem Browser und erstelle dein Eigentümerkonto.

Schritt 9: n8n gezielt aktualisieren

n8n veröffentlicht fast jede Woche eine neue Minor-Version, und die Update-Anleitung empfiehlt, vor einem Upgrade das Changelog mit den Breaking Changes zu prüfen. Wenn du so weit bist, bearbeite das Versions-Tag in docker-compose.yml und führe dann Folgendes aus:

cd /opt/n8n-compose
sudo docker compose pull
sudo docker compose up -d

Bei einem festgelegten Tag ändert ein Pull allein nichts: Du entscheidest über jedes Upgrade, indem du das Tag änderst. Genau darum geht es beim Festlegen. Erstelle vor größeren Versionsupdates ein Backup (Schritt 10).

Schritt 10: Backups planen

Für eine brauchbare Wiederherstellung sind drei Dinge nötig: die PostgreSQL-Datenbank, das Volume n8n_data und die Datei .env, die N8N_ENCRYPTION_KEY bereitstellt. Die Docker-Dokumentation von n8n stellt klar, dass der Ordner /home/node/.n8n (unser Volume n8n_data) auch bei Verwendung von PostgreSQL wichtige Daten enthält, darunter das Material des Verschlüsselungsschlüssels. Sichere alle drei und bewahre docker-compose.yml und Caddyfile auf, damit du den Stack wiederherstellen kannst. Das folgende Skript kümmert sich um die Datenbank und das Volume. Wie du die Konfigurationsdateien auf einen anderen Rechner kopierst, folgt direkt danach. Erstelle das Skript als Datei, die root gehört:

sudo tee /opt/n8n-compose/backup.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
cd /opt/n8n-compose
STAMP=$(date +%Y-%m-%d)
mkdir -p /opt/n8n-backups
docker compose exec -T postgres pg_dump -U n8n -d n8n > "/opt/n8n-backups/n8n-db-${STAMP}.sql"
docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  tar czf "/backup/n8n-data-${STAMP}.tar.gz" -C /data .
find /opt/n8n-backups -name 'n8n-db-*.sql' -mtime +30 -delete
find /opt/n8n-backups -name 'n8n-data-*.tar.gz' -mtime +30 -delete
EOF
sudo chmod 700 /opt/n8n-compose/backup.sh
sudo /opt/n8n-compose/backup.sh

Hinweise zum Skript: n8n-compose_n8n_data ist der Volume-Name, den Compose für ein Projektverzeichnis namens n8n-compose erstellt. Prüfe deinen mit sudo docker volume ls und passe ihn an, falls er abweicht. Die beiden find-Zeilen bewahren Backups 30 Tage lang auf. Wähle eine andere Aufbewahrungsdauer, wenn sie besser zu deinem Speicherplatz und deinen Anforderungen an die Wiederherstellung passt.

Plane es über die Crontab von root. Der Cron von root sollte immer nur ein Skript ausführen, das root gehört (chmod 700, mit .env unter 600), niemals eine Datei, die ein anderer Benutzer bearbeiten kann. Führe sudo crontab -e aus und füge eine Zeile für einen täglichen Lauf um 3 Uhr morgens hinzu:

0 3 * * * /opt/n8n-compose/backup.sh

Das Skript sichert die PostgreSQL-Datenbank und das Volume n8n_data nach Zeitplan. Kopiere die Datei .env (die deinen Verschlüsselungsschlüssel enthält) sowie die Compose- und Caddy-Dateien jetzt und nach jeder Änderung auf ein anderes System. Erstelle auf dem Server ein temporäres, geschütztes Archiv:

sudo tar -C /opt/n8n-compose -czf /home/deploy/n8n-config.tar.gz .env docker-compose.yml Caddyfile
sudo chown deploy:deploy /home/deploy/n8n-config.tar.gz
chmod 600 /home/deploy/n8n-config.tar.gz

Lade dann von deinem lokalen Rechner aus das Konfigurationsarchiv zusammen mit den Backups herunter und lösche die temporäre Kopie auf dem Server:

scp deploy@your_server_ip:/home/deploy/n8n-config.tar.gz .
scp -r deploy@your_server_ip:/opt/n8n-backups .
ssh deploy@your_server_ip 'rm /home/deploy/n8n-config.tar.gz'

Ein Backup, das nur auf dem Server existiert, den es schützen soll, verschwindet zusammen mit dem Server.

Schritt 11: Wiederherstellung auf einem Test-VPS prüfen

Mit diesem Backup-und-Wiederherstellungsverfahren prüfst du, ob deine Backups tatsächlich brauchbar sind. Teste die Wiederherstellung auf einem frischen Test-VPS, niemals auf deinem Produktivserver. Richte einen Wegwerf-Server ein, wiederhole dort Schritt 4 (Docker) und kopiere deine Projektdateien (docker-compose.yml, Caddyfile, .env) sowie deine neuesten datierten Backups in dieselben Pfade.

Tausche zuerst den Hostnamen aus: Trage einen Test-Hostnamen (zum Beispiel n8n-restore-test.example.com, mit einem A-Record, der auf den Test-VPS zeigt) in N8N_HOST, N8N_WEBHOOK_URL und die Caddyfile ein. Führe dann Folgendes aus und ersetze dabei die datierten Dateinamen durch deine eigenen:

cd /opt/n8n-compose
sudo docker compose create
sudo docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  sh -c "cd /data && tar xzf /backup/n8n-data-2026-08-25.tar.gz"
sudo docker compose up -d --wait postgres
sudo docker compose exec -T postgres psql -U n8n -d n8n < /opt/n8n-backups/n8n-db-2026-08-25.sql
sudo docker compose run --rm n8n unpublish:workflow --all
sudo docker compose up -d

Die Zeile unpublish:workflow --all nutzt die integrierte Server-CLI von n8n, um die Veröffentlichung aller wiederhergestellten Workflows aufzuheben, bevor die Instanz startet. So lösen wiederhergestellte Zeitpläne und Trigger auf dem Testsystem nichts in deinen Produktivsystemen aus. Schließe mit derselben curl-Prüfung wie in Schritt 8 ab, diesmal mit dem Test-Hostnamen.

Sei ehrlich zu dir selbst, was ein grünes Häkchen bedeutet: Es bestätigt, dass Datenbank und Volume wiederhergestellt wurden und der Stack sauber startet. Deine Workflows werden dabei nicht im Editor durchgespielt. Melde dich also auf der Testinstanz an und prüfe stichprobenartig die Workflows, auf die du auf keinen Fall verzichten kannst.

Wie hältst du eine selbstgehostete n8n-Instanz sicher?

Eine selbstgehostete n8n-Instanz ist so sicher wie der Server, auf dem sie läuft, und diesen Server kontrollierst du.

Sicherheit läuft auf sechs Punkte hinaus. Keiner davon ist für sich genommen kompliziert, aber wenn du auch nur einen auslässt, entsteht eine echte Lücke. Die Einrichtung oben setzt die ersten drei bereits um.

1. HTTPS über einen Reverse Proxy. Greife niemals über unverschlüsseltes HTTP auf den n8n-Editor zu. Die Caddy-Konfiguration aus Schritt 7 bezieht und erneuert automatisch ein öffentlich vertrauenswürdiges Zertifikat über einen Aussteller wie Let’s Encrypt oder ZeroSSL und leitet HTTP auf HTTPS um.
2. Streng konfigurierte Firewall. UFW lässt nur SSH (22), HTTP (80) und HTTPS (443) zu. Mach den Standardport 5678 von n8n niemals direkt aus dem Internet zugänglich. Die Compose-Datei oben setzt das durch, indem sie n8n keinen veröffentlichten Host-Port gibt. So können nur Container im Compose-Netzwerk n8n erreichen.
3. Netzwerkisolation mit Docker. PostgreSQL und n8n kommunizieren über das interne Compose-Netzwerk. Dein Datenbankport wird nie auf dem Host veröffentlicht und ist daher von außen nie erreichbar.
4. Starke Authentifizierung. Verwende ein starkes Passwort für das Eigentümerkonto und aktiviere die Zwei-Faktor-Authentifizierung. Der Sicherheitsleitfaden von n8n führt 2FA unter den empfohlenen Schutzmaßnahmen für selbstgehostete Instanzen auf.
5. Regelmäßige Updates. Aktualisiere das Versions-Tag in deiner Compose-Datei, ziehe dann das neue Image und starte neu (Schritt 9). Lies vorher das Changelog, denn n8n-Updates können Breaking Changes enthalten.
6. Backups, die du tatsächlich wiederhergestellt hast. Die Schritte 10 und 11 liefern dir den Zeitplan und den Test. Ein Backup, das du nie getestet hast, ist eine Hoffnung, kein Plan.

Noch etwas solltest du im Blick behalten. Es hat nicht direkt mit Sicherheit zu tun, macht aber einen großen Unterschied: n8n speichert standardmäßig Ein- und Ausgabe jeder Ausführung in seiner Datenbank. Das Bereinigen ist standardmäßig aktiv: n8n löscht Ausführungen, die älter als 336 Stunden (14 Tage) sind, oder sobald mehr als 10.000 Ausführungen gespeichert sind. Eine viel genutzte Instanz kann PostgreSQL in der Zwischenzeit trotzdem aufblähen.

Wenn deine Workflows viele Daten erzeugen, zieh die Grenzen enger: Setze EXECUTIONS_DATA_MAX_AGE=168, um Ausführungsdaten zu löschen, die älter als sieben Tage sind (die Compose-Datei oben macht das bereits), oder verzichte mit EXECUTIONS_DATA_SAVE_ON_SUCCESS=none ganz darauf, erfolgreiche Läufe zu speichern.

Selbst hosten oder n8n Cloud: Was sind die Vor- und Nachteile?

Wenn du n8n selbst hostest, bekommst du eine Instanz ohne Ausführungskontingent und Kontrolle über die gespeicherten Daten. Du zahlst dafür einen kleinen VPS und übernimmst die Verwaltung selbst. Mit n8n Cloud entfällt die Serverwartung komplett, dafür gibt es je nach Tarif Ausführungslimits. Am Ende hängt die Wahl davon ab, ob dir deine Automatisierungsinfrastruktur selbst gehören soll oder ob du jemand anderen dafür bezahlst, sie zu betreiben.

Die n8n-Dokumentation formuliert es so: n8n recommends self-hosting for expert users. Mistakes can lead to data loss, security issues, and downtime. If you aren’t experienced at managing servers, n8n recommends n8n Cloud.

So schneiden die beiden Optionen im Vergleich ab:

Es gibt auch einen Mittelweg, den du kennen solltest. Verwaltete Plattformen wie PikaPods (rund 3,80 $/Monat) und Elestio (rund 17 $/Monat, laut dem Vergleich von ExpressTech) betreiben selbstgehostetes n8n, ohne dass du den Server selbst verwalten musst. Diese Dienste können dir Arbeit bei der Serveradministration abnehmen – prüfe aber, wer sich um n8n-Updates, Backups, Monitoring und Sicherheit kümmert.

Doch jetzt zum großen Ganzen: Bei jedem gehosteten Tarif ist deine Ausführungskapazität eine Abrechnungsstufe, und die Stufen legt die Plattform fest. Preise, Kontingente und Funktionen können sich ändern – auch rund um Workflows, die du bereits aufgebaut hast.

Beim Self-Hosting liegen die Instanz und die darin gespeicherten Daten auf einer Infrastruktur, die du kontrollierst (verbundene Dienste erhalten weiterhin alles, was deine Workflows an sie senden). Volle Kontrolle, volle Verantwortung.

Die endgültige Entscheidung

Self-Hosting lohnt sich, wenn drei Dinge zusammenkommen:

1. Du betreibst so viele Automatisierungen, dass die Ausführungslimits in der Cloud dich einschränken würden
2. Du möchtest deine Workflow-Daten auf einer Infrastruktur, die du kontrollierst
3. Du (oder jemand in deinem Team) bist bereit, Updates, Backups und Monitoring zu übernehmen

Andernfalls ist n8n Cloud eine vernünftige Wahl. Für den Starter-Tarif zu zahlen, um nie über Docker-Logs nachdenken zu müssen, ist ein fairer Deal – vor allem für ein kleines Team, das einfach nur will, dass seine Automatisierungen laufen.

Sobald du aber bereit bist, den Schritt zum Self-Hosting zu gehen, spricht die Rechnung schnell eine klare Sprache. Ein VPS mit 4 GB ist ein praktischer, wenn auch nicht per Benchmark getesteter Ausgangspunkt; die Kapazität im Produktivbetrieb hängt von Parallelität, Datenvolumen und den verwendeten Nodes ab. Überwache die Instanz also und skaliere sie, wenn der Bedarf wächst. Fang klein an, rüste auf, wenn deine Workflows wachsen, und behalte die volle Kontrolle über deinen Stack.

Dieser letzte Punkt ist wichtiger, als er vielleicht scheint. Auf einen größeren Server umsteigen kannst du jederzeit. Sich von einer SaaS-Plattform zu lösen, nachdem sie ihre Preise rund um deine bestehenden Workflows geändert hat, ist dagegen deutlich schwieriger.

Häufig gestellte Fragen zum Selbsthosten von n8n