Wie Du n8n Auf Deinem Eigenen Server Ausführst

Du hast deine Zapier-Rechnung sechs Monate lang ansteigen sehen.

Jeder neue Workflow fügt einen weiteren Posten hinzu, und jeder erfolgreiche Aktionsschritt zählt als Aufgabe. Die monatliche Rechnung kostet nun mehr als dein Projektmanagement-Tool.

Du beginnst, nach Alternativen zu googeln, und stößt auf n8n, eine Automatisierungsplattform, die du auf deinem eigenen virtuellen privaten Server (VPS) zum Preis eines kleinen Servers selbst hosten kannst.

Kein Ausführungskontingent. Keine Preisgestaltung pro Aufgabe. Keine unerwarteten Rechnungen, wenn deine Automatisierungen durchstarten.

Und ja, wir begleiten dich durch den gesamten Prozess, Befehl für Befehl, von einem nackten Ubuntu-Server bis zu einer laufenden Instanz mit HTTPS, Backups und einer getesteten Wiederherstellung.

Was Ist n8n und Warum Hosten Es Viele Selbst?

n8n ist eine Plattform zur Workflow-Automatisierung, mit der du Apps verbinden, Daten zwischen Diensten verschieben und komplexe Automatisierungen über einen visuellen Editor erstellen kannst. Stell es dir als den Motor hinter „Wenn X passiert, mache Y und Z“ vor, nur dass du Knoten ziehst und Verbindungen zeichnest, anstatt Code zu schreiben.

Workflow-Diagramm, in dem eine Formulareinsendung eines Benutzers einen KI-Agenten auslöst, der den Status des Managers prüft

Das Projekt hat die Marke von 200.000 GitHub-Sternen überschritten, und sein offizielles Docker-Image verzeichnet über 100 Millionen Pulls. Auf sehr vielen Servern da draußen läuft n8n.

Die Plattform läuft unter einer Sustainable Use License, die du verstehen solltest, bevor du dich festlegst. Es ist keine traditionelle Open Source (n8n selbst verwendet den Begriff nicht, da OSI-anerkannte Lizenzen die Nutzung nicht einschränken dürfen), aber sie ist auch nicht abgeschottet. Du kannst sie frei für deine eigenen internen Geschäftszwecke betreiben. Du darfst kein Produkt, keinen Dienst und kein Modul verkaufen, dessen Wert vollständig oder im Wesentlichen auf n8n-Funktionalität beruht.

„In der Praxis bedeutet das, dass jede Nutzung erlaubt ist, es sei denn, du verkaufst ein Produkt, einen Dienst oder ein Modul, dessen Wert vollständig oder im Wesentlichen auf n8n-Funktionalität beruht.“ — Lizenz-FAQ von n8n

Viele hosten n8n selbst, weil sich die Wirtschaftlichkeit umkehrt, sobald du über die Basisnutzung hinausgehst. n8n Cloud beginnt im Starter-Plan bei 20 €/Monat (bei jährlicher Abrechnung) für 2.500 Ausführungen, und wenn du nennenswertes Volumen hast, stößt du schnell an diese Grenzen.

Auf deinem eigenen VPS? Kein Ausführungskontingent, Kontrolle über die Daten, die deine n8n-Instanz speichert, und keine Lizenz- oder Ausführungsrechnung von n8n, auch wenn Server, Domain, Backup-Speicher und Administration weiterhin Kosten verursachen. Die Ausführungen selbst kosten nichts extra; mehr Volumen braucht zwar mehr Arbeitsspeicher und Speicherplatz, aber das ist eine Frage der Dimensionierung (siehe unten), keine der Abrechnung.

Was Kannst Du Mit n8n Automatisieren?

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

Einige gängige Einsatzszenarien:

CRM und Lead-Weiterleitung. Synchronisiere Kontakte zwischen deinem CRM, deiner E-Mail-Plattform und Slack, wenn neue Leads eingehen.
Webhook-ausgelöste Workflows. Reagiere in Echtzeit auf Ereignisse von Zahlungsdienstleistern, Formulareinsendungen oder GitHub-Commits.
Automatisierung von Datenpipelines. Rufe Daten von APIs ab, transformiere sie und speise sie nach Zeitplan in Datenbanken oder Tabellen ein.
KI-Agenten-Ketten. Verbinde LLMs mit deinen internen Werkzeugen, um eigene KI-Assistenten zu erstellen, die deine Daten durchsuchen, zusammenfassen und darauf basierend handeln können.

(Beim letzten Punkt fangen deine Serverressourcen an, wichtig zu werden. Mehr dazu im Abschnitt zu den Spezifikationen.)

Wie Viel Kostet Das Selbsthosting Von n8n?

Für die selbstgehostete Community Edition fallen bei zulässiger Nutzung keine Lizenz- oder Ausführungsgebühren von n8n an. Deine Gesamtkosten umfassen den Server sowie eine eventuelle Domain, Backup-Speicher und Administrationszeit. Die Kostenaufstellung 2026 von ExpressTech beziffert einen reinen VPS mit Docker auf 4–5 $ pro Monat, einen mit Coolify verwalteten VPS auf 5–8 $ und verwaltete Ein-Klick-Plattformen für n8n auf 3–7 $.

Das sind Hosting-Schätzungen des Drittanbieters ExpressTech. Eine Zahl aus erster Hand: Der Plan, den wir unten empfehlen, DreamHost VPS Hosting Stack 4, kostet bei monatlicher Abrechnung 8,99 $/Monat für die ersten 3 Monate und verlängert sich danach automatisch zu 15,99 $/Monat (Stand August 2026), wobei die gesamte Laufzeit plus Steuern beim Checkout berechnet wird (aktuelle 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 aufgeführt sind. n8n gibt Preise in Euro an, und dies sind die Tarife bei jährlicher Abrechnung:

Plan	Monatliche Kosten	Ausführungslimit
n8n Cloud Starter	20 €/Monat	2.500 Ausführungen
n8n Cloud Pro	50 €/Monat	10.000 Ausführungen
n8n Business (selbstgehostete Lizenz)	667 €/Monat	40.000 Ausführungen
Selbstgehostete Community Edition auf einem VPS	Keine Lizenz- oder Ausführungsgebühren von n8n bei zulässiger Nutzung; Kosten für VPS, Domain, Backup-Speicher und Administration können anfallen	Kein Kontingent

Die Lücke vergrößert sich, wenn du berücksichtigst, wie die Plattformen die Nutzung zählen. n8n berechnet eine Ausführung pro Workflow-Durchlauf, „unabhängig von der Komplexität“, und jeder Plan enthält unbegrenzt viele Schritte. Zapier dagegen zählt jeden erfolgreichen Aktionsschritt als Aufgabe.

Ein Workflow mit vier Aktionsschritten, der 100 Mal pro Tag läuft, entspricht also 3.000 n8n-Ausführungen pro Monat, aber rund 12.000 Zapier-Aufgaben.

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: Diese Last sprengt n8n Cloud Starter und erfordert die Pro-Stufe (dort mit 60 $/Monat bei monatlicher Abrechnung aufgeführt), während ein selbstgehostetes Setup für 3–7 $/Monat sie ohne Limits bewältigt, ein Unterschied, den sie auf 636–684 $ pro Jahr beziffern.

Die Versteckten Kosten Des Selbsthostings

Die Einsparungen in Dollar sind real. Aber Selbsthosting ist nicht in jeder Hinsicht kostenlos.

Das kostet es dich:

Deine Zeit. Der Wartungsaufwand hängt von deiner Arbeitslast und deiner Betriebserfahrung ab, aber du bist für Updates, Backups, Überwachung und Wiederherstellungstests verantwortlich. Aufwendigere Setups mit KI-gestützten Automatisierungen verlangen mehr.

Reibung bei der Einrichtung von OAuth. Die Verbindung von Diensten wie Google Workspace oder Microsoft 365 erfordert das Konfigurieren von OAuth-Anmeldeinformationen. Plane für jeden Anbieter zusätzliche Einrichtungszeit ein und folge der Dokumentation seiner Konsole. (Wenn du jemals auf einen Ladekreisel gestarrt hast, während ein Zustimmungsbildschirm entscheidet, ob er deiner App vertraut, kennst du das Gefühl.)

TLS, dem du vertrauen, das du aber überprüfen musst. Der Caddy-Proxy in der folgenden Einrichtung bezieht und erneuert automatisch ein öffentlich vertrauenswürdiges Zertifikat und nutzt dafür einen Aussteller wie Let’s Encrypt oder ZeroSSL. Automatisch heißt nicht unzerstörbar: Prüfe nach DNS- oder Proxy-Änderungen, ob das Zertifikat weiterhin erneuert wird.

Einarbeitung, wenn du neu im Serverbereich bist. Die folgende Anleitung setzt voraus, dass du dich per SSH mit einem Server verbinden, eine Datei bearbeiten und Befehle ausführen kannst. Wenn du das noch nie gemacht hast, plane zusätzlich zur eigentlichen Bereitstellung Lernzeit ein.

Welche Server-Spezifikationen Benötigt n8n?

n8n selbst ist schlank. Am nächsten an einer offiziellen Dimensionierung kommen die Beispielwerte in der OEM-Bereitstellungsdokumentation von n8n, die n8n als „nur zur Veranschaulichung“ kennzeichnet und die auf n8n Cloud basieren: ein Speicherbereich von 320 MB bis 2 GB, eine SSD-gestützte Datenbank mit 512 MB bis 4 GB und etwa 100 MB Arbeitsspeicher für eine Instanz im Leerlauf. Als vorsichtige Startausstattung, nicht als offizielles Minimum von n8n, kannst du 2 GB für Tests und 4 GB einplanen, sobald PostgreSQL und produktive Workflows hinzukommen. Überwache repräsentative Workflows und erweitere den Arbeitsspeicher, wenn anhaltender Druck auftritt.

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 sei „nicht CPU-intensiv“, und „in der Regel übersteigen die Speicheranforderungen die CPU-Anforderungen“. Was den Speicherbedarf in die Höhe treibt, sind deine Workflows: Datenvolumen, Code-Knoten (die Daten vor und nach der Verarbeitung kopieren) und große Binärdateien.

Hier ist unsere schnelle Überschlagsrechnung für den Spielraum bei der Dimensionierung:

Dimensioniere nach der Gleichzeitigkeit der Ausführungen und dem Datenvolumen, das jeder Workflow verarbeitet, und überwache dann die Speichernutzung unter einer repräsentativen Last. Code-Knoten und große binäre Nutzdaten können den Speicherbedarf erhöhen, also lass Spielraum und skaliere den VPS, wenn die Überwachung anhaltenden Druck zeigt.

Diagramm mit RAM-Empfehlungen für selbstgehostetes n8n: etwa 100 MB im Leerlauf laut dem illustrativen Beispiel von n8n, 2 GB als vorsichtige Startausstattung für Tests, 4 GB für den Produktivbetrieb mit PostgreSQL und 8 GB für zusätzlichen Spielraum

Neu bei VPS-Hosting? Beginne mit DreamHosts Anfängerleitfaden zu VPS, 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 nach Arbeitslast. Dimensioniere nach der Gleichzeitigkeit der Ausführungen und dem Datenvolumen, lass Spielraum für Docker und PostgreSQL, überwache dann repräsentative Workflows und skaliere, wenn der Speicherdruck anhält.

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

Plan	Spezifikationen	Wann du ihn wählen solltest
DreamHost VPS Hosting Stack 4	4 GB RAM, 2 vCPU, 75 GB NVMe-SSD	Eine nicht per Benchmark geprüfte, aber vorsichtige Startausstattung mit 4 GB für einen ersten n8n-Server.
DreamHost VPS Hosting Stack 8	8 GB RAM, 2 vCPU, 150 GB NVMe-SSD	Die Option mit 8 GB für zusätzlichen Speicherspielraum, wenn die Überwachung anhaltenden Druck zeigt, mit doppelt so viel RAM und Speicherplatz.
DreamHost VPS Hosting Stack 16	16 GB RAM, 4 vCPU, 250 GB NVMe-SSD	Die Option mit 16 GB für mehr Gleichzeitigkeit, größere Datenmengen oder zusätzliche Redis-Worker im Queue-Modus.

Einige Spezifikationen, auf die du neben dem RAM achten solltest: n8n führt SSD-Speicher als Best Practice für Datenbanken auf. Der Speicherbedarf überwiegt meist den CPU-Bedarf, aber der tatsächliche Engpass hängt von der Gleichzeitigkeit der Workflows, dem Datenvolumen und den verwendeten Knoten ab. Unbegrenzte Bandbreite ist wichtig, wenn du webhook-intensive Arbeitslasten mit einem ständigen Strom eingehender HTTP-Anfragen betreibst.

Wähle eine Hosting-Umgebung, in der du Docker ausführen und die Datenbank, das Netzwerk, persistenten Speicher und den Reverse Proxy konfigurieren kannst. Herkömmliches Shared Hosting bietet dieses Maß an Kontrolle in der Regel nicht.

Die VPS-Hosting-Pläne von DreamHost erfüllen die wesentlichen Kriterien (NVMe-SSD-Speicher, unbegrenzte Bandbreite, voller Root-Zugang und Docker-Unterstützung), und n8n ist in der Ein-Klick-App-Bibliothek enthalten, vorinstalliert mit PostgreSQL und automatischem SSL, falls du dir die folgende manuelle Einrichtung lieber sparen willst.

Unsere Wahl für einen ersten n8n-Server ist Stack 4. Stand August 2026 kostet er bei monatlicher Abrechnung 8,99 $/Monat für die ersten 3 Monate und verlängert sich automatisch zu 15,99 $/Monat, wobei die gesamte Laufzeit plus Steuern beim Checkout berechnet wird; die n8n-VPS-Seite zeigt immer die aktuellen Preise. Dieser Verlängerungspreis ist die ehrliche Zahl für den Vergleich mit den 20 €/Monat von n8n Cloud Starter.

Ach, und eine Sache, die du für später im Hinterkopf behalten solltest: Wenn deine Nutzung wächst, unterstützt n8n den Queue-Modus, eine Skalierungsarchitektur, die die Hauptinstanz (UI, Trigger, Webhooks) von der Workflow-Ausführung trennt und dabei Redis als Message Broker sowie Worker-Instanzen zur Abarbeitung der Jobs nutzt. Die Dokumentation von n8n nennt ihn den Modus, der „die beste Skalierbarkeit bietet“.

Wie Richtest Du n8n Auf Einem VPS Ein?

Die Bereitstellung 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 Prüfung, Updates, Backups und einen Wiederherstellungstest. Caddy ist unser Reverse Proxy: der Server, der zwischen dem Internet und deiner Anwendung sitzt und TLS sowie Routing übernimmt. Wir liefern die Befehle für die Kernbereitstellung und einen manuellen Backup-und-Wiederherstellungstest.

Architekturdiagramm einer selbstgehosteten n8n-Einrichtung mit Datenbank und n8n-App

Die Befehle sind für Ubuntu 22.04 oder neuer gedacht, aber ersetze die Beispieldomain, die Secret-Werte, den Volume-Namen und die datierten Backup-Dateinamen, wo angegeben. Die Docker-Compose-Dokumentation von n8n behandelt dasselbe mit einem Traefik-Proxy, falls du lieber der eigenen Vorlage von n8n folgen möchtest.

Was Du Brauchst, Bevor Du Beginnst

Ein VPS mit Root-Zugang mit Ubuntu 22.04 oder neuer und mindestens 2 GB RAM (4 GB ist unsere vorsichtige Empfehlung für den Produktivbetrieb)
Ein Domainname, den du auf die IP-Adresse deines Servers zeigen lassen kannst (für TLS und den Zugriff auf den n8n-Editor)
Grundkenntnisse im Umgang mit dem Terminal — du solltest wissen, wie man sich per SSH mit einem Server verbindet, eine Datei bearbeitet und Befehle ausführt

Noch eine Voraussetzung, die auf keiner offiziellen Liste steht: Sichere deinen N8N_ENCRYPTION_KEY in dem Moment, in dem du ihn erzeugst. Deshalb erzeugst du den Schlüssel in Schritt 5 mit openssl rand -hex 32 vor dem ersten Start, statt n8n stillschweigend einen generieren zu lassen. Dieser Schlüssel verschlüsselt alle deine gespeicherten Zugangsdaten, einschließlich jedes API-Schlüssels, OAuth-Tokens und Datenbankpassworts, die du verbunden hast. Die eigene Docker-Dokumentation von n8n warnt: Wenn der Schlüssel beim Start nicht gefunden wird, erstellt n8n einen neuen, und vorhandene Zugangsdaten lassen sich nicht mehr entschlüsseln — du baust dann jede einzelne Integration von Grund auf neu auf (und bedauerst deine Lebensentscheidungen). Kopiere ihn an einen sicheren Ort, getrennt von deinen Datenbank-Backups.

Wenn dein Anbieter dir nur einen Root-Login gegeben hat, lege zuerst einen Benutzer für die Bereitstellung an, über die Konsole des Anbieters oder eine Root-SSH-Sitzung, 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: Richte Deine Domain Auf Den Server Aus

Lege für eine eigene Subdomain (n8n.example.com in diesem gesamten Leitfaden) einen DNS-A-Record an, der auf die IP-Adresse deines Servers zeigt, genau 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 möglicherweise einen Sicherheitsfehler statt des n8n-Editors.

Schritt 2: Härte Den SSH-Zugang

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

Stelle sicher, dass du dich mit dem Schlüssel anmelden kannst. Schalte dann auf dem Server Passwort- und Root-Logins ab und prüfe, was sshd tatsächlich durchsetzen wird:

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, und Cloud-Server-Images bringen oft frühere Drop-ins im selben Verzeichnis mit (cloud-init etwa schreibt seine SSH-Einstellungen nach 50-cloud-init.conf). Nennst du deine Datei 99-hardening.conf, kann eines dieser Snippets stillschweigend gewinnen. sshd -t prüft die Konfiguration auf Fehler; sshd -T gibt die effektiven Einstellungen aus, nachdem alle Dateien zusammengeführt wurden. Stelle sicher, 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 entfernten Server dich aussperren kann. Lass deine aktuelle Sitzung offen und teste eine neue Anmeldung in einem zweiten Terminal, bevor du irgendetwas schließt.

Schritt 3: Aktiviere Die Firewall

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

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 selbst: Ports, die Docker auf dem Host veröffentlicht, umgehen UFW-Regeln vollständig. Deshalb veröffentlicht die Compose-Datei in Schritt 6 Host-Ports nur für Caddy: 80 und 443 sind die einzigen Container-Ports, die Compose veröffentlicht (SSH auf 22 ist ebenfalls offen), und n8n und PostgreSQL erhalten überhaupt keine veröffentlichten Host-Ports.

Schritt 4: Installiere Docker Und Docker Compose

Installiere Docker Engine aus dem offiziellen apt-Repository von Docker, nicht mit dem Komfortskript get.docker.com, das die Dokumentation von Docker 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. Dieser Befehl schreibt die Repository-Datei aus dem Ubuntu-Installationsleitfaden von Docker und setzt dein Ubuntu-Release automatisch ein:

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 prü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 bereit.

Schritt 5: Lege Das Projektverzeichnis Und Die Secrets An

Lege das Projektverzeichnis an und erzeuge dann deinen Verschlüsselungsschlüssel — lass n8n beim ersten Start nicht stillschweigend einen erfinden:

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). 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

Das chmod 600 ist wichtig: Diese Datei enthält Secrets, also sollte nur ihr Besitzer (root) sie lesen können. In der Compose-Datei wendet N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true dieselbe Idee innerhalb des Containers an: Laut der Referenz der Sicherheitsvariablen von n8n versucht n8n damit, für seine eigene Einstellungsdatei die Berechtigungen 0600 zu setzen.

Schritt 6: Schreibe Die Docker-Compose-Datei

Lege /opt/n8n-compose/docker-compose.yml an (zum Beispiel mit sudo nano /opt/n8n-compose/docker-compose.yml) und füge Folgendes ein, wobei du in beiden URL-Zeilen n8n.example.com durch deine eigene Domain ersetzt und deine Zeitzone einstellst:

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 wertvoll:

Das Image ist auf eine bestimmte Version gepinnt (2.36.7 ist zum Zeitpunkt dieses Artikels das aktuelle stabile Release, laut der Installationsdokumentation von n8n), sodass Upgrades nur stattfinden, wenn du es entscheidest.
n8n veröffentlicht keinen Host-Port. Es ist für Container im Compose-Netzwerk erreichbar, einschließlich Caddy, aber nicht über einen veröffentlichten Host-Port, sodass der Editor immer nur über den Reverse Proxy erreichbar ist, 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 eigenen 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. n8n bildet Webhook-URLs normalerweise aus Protokoll, Host und Port, und laut der Dokumentation von n8n funktioniert das hinter einem Reverse Proxy nicht. Deshalb setzt du die Webhook-URL manuell, damit n8n „die korrekten Webhook-URLs bei externen Diensten registrieren“ kann, setzt N8N_PROXY_HOPS auf 1 und stellst sicher, dass der Proxy die Header X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto weitergibt. (Dieselbe Seite weist darauf hin, dass N8N_WEBHOOK_URL das ältere WEBHOOK_URL ersetzt, das ab n8n 2.35.0 veraltet ist.)
TZ und GENERIC_TIMEZONE erfüllen unterschiedliche Aufgaben. Laut der Docker-Dokumentation von n8n steuert GENERIC_TIMEZONE Zeitplanungsknoten wie Schedule, während TZ die Systemzeitzone des Containers festlegt (das, was Befehle wie date melden). Setze beide auf denselben Wert.

(Beginne von Anfang an mit PostgreSQL. n8n verwendet standardmäßig SQLite, was zum Testen funktioniert, aber die Hosting-Vorlagen von n8n empfehlen PostgreSQL für den Produktivbetrieb, und eine spätere Migration ist schmerzhaft auf die „Ich wünschte, ich hätte das von Anfang an richtig gemacht“-Weise.)

Schritt 7: Schreibe Das Caddyfile

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

n8n.example.com {
    reverse_proxy n8n:5678
}

Das ist 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, vorausgesetzt, dein DNS-A-Record zeigt auf den Server und die Ports 80 und 443 sind offen (Schritte 1 und 3). Caddy ist außerdem einer der Reverse Proxies in den offiziellen Hosting-Beispielen von n8n.

Schritt 8: Starten Und Prü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, und prüfe dann von einem beliebigen Rechner aus die Eingangstür:

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; beendet sich curl stattdessen mit einem Fehler, 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 lege dein Owner-Konto an.

Schritt 9: Aktualisiere n8n Bewusst

n8n veröffentlicht fast jede Woche eine neue Minor-Version, und seine Update-Anleitung fordert dich auf, vor dem Upgrade das Changelog der Breaking Changes zu lesen. Wenn du bereit bist: Ändere den 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

Mit einem fest gepinnten Tag ändert ein Pull allein nichts: Du entscheidest über jedes Upgrade, indem du den Tag änderst, und genau darum geht es beim Pinnen. Erstelle vor größeren Versionsupdates ein Backup (Schritt 10).

Schritt 10: Plane Backups Ein

Für eine brauchbare Wiederherstellung sind drei Dinge nötig: die PostgreSQL-Datenbank, das Volume n8n_data und die .env-Datei, 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, einschließlich des Schlüsselmaterials für die Verschlüsselung. Sichere alle drei und bewahre docker-compose.yml und Caddyfile auf, damit du den Stack rekonstruieren kannst. Das folgende Skript kümmert sich um die Datenbank und das Volume; das Kopieren der Konfigurationsdateien vom Host folgt direkt danach. Lege das Skript als Datei im Besitz von root an:

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 erzeugt; 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; lege eine andere Aufbewahrungsdauer fest, die zu deinem Speicherplatz und deinen Wiederherstellungsanforderungen passt.

Plane es über die crontab von root ein. Der Cron von root sollte immer nur ein Skript im Besitz von root ausführen (chmod 700, mit der .env auf 600), niemals eine Datei, die ein anderer Benutzer bearbeiten kann. Führe sudo crontab -e aus und füge eine Zeile für eine tägliche Ausführung 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 .env (die deinen Verschlüsselungsschlüssel enthält) sowie die Compose- und Caddy-Dateien jetzt und bei jeder Änderung vom Host weg. 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ützt, verschwindet mit dem Server.

Schritt 11: Teste Eine Wiederherstellung Auf Einem Wegwerf-VPS

Dies ist ein Backup-und-Wiederherstellungsverfahren, mit dem du prüfen kannst, ob deine Backups brauchbar sind. Teste diese Wiederherstellung auf einem frischen Wegwerf-VPS — niemals auf deinem Produktionsserver. Richte einen Wegwerf-Server ein, wiederhole dort Schritt 4 (Docker) und kopiere deine Projektdateien (docker-compose.yml, Caddyfile, .env) und deine neuesten datierten Backups in dieselben Pfade.

Tausche zuerst den Hostnamen aus: Trage einen Test-Hostnamen (etwa n8n-restore-test.example.com, mit einem A-Record, der auf den Wegwerf-VPS zeigt) in N8N_HOST, N8N_WEBHOOK_URL und das 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 jeden wiederhergestellten Workflow vor dem Start der Instanz auf unveröffentlicht zu setzen, damit wiederhergestellte Zeitpläne und Trigger von der Testmaschine aus nicht gegen deine Produktivsysteme auslösen. Schließe mit derselben curl-Prüfung wie in Schritt 8 ab, diesmal gegen den Test-Hostnamen.

Sei ehrlich zu dir selbst, was ein grüner Haken bedeutet: Er bestätigt, dass Datenbank und Volume wiederhergestellt wurden und der Stack sauber startet. Er testet deine Workflows nicht über den Editor, also melde dich auf der Testinstanz an und prüfe stichprobenartig die, deren Verlust du dir nicht leisten 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 du bist derjenige, der diesen Server kontrolliert.

Sicherheit basiert auf sechs Dingen. Keines davon ist für sich genommen kompliziert, aber wenn du eines überspringst, entsteht eine echte Lücke. Die obige Einrichtung setzt die ersten drei bereits um.

HTTPS über einen Reverse Proxy. Greife niemals über einfaches HTTP auf den n8n-Editor zu. Die Caddy-Konfiguration in 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.
Firewall-Abschottung. UFW erlaubt nur SSH (22), HTTP (80) und HTTPS (443). Setze den Standardport 5678 von n8n niemals direkt dem Internet aus. Die obige Compose-Datei erzwingt das, indem sie n8n keinen veröffentlichten Host-Port gibt, sodass nur Container im Compose-Netzwerk es erreichen können.
Docker-Netzwerkisolierung. PostgreSQL und n8n kommunizieren über das interne Compose-Netzwerk. Dein Datenbankport wird nie auf dem Host veröffentlicht und ist daher nie von außen erreichbar.
Starke Authentifizierung. Verwende ein starkes Owner-Passwort und aktiviere die Zwei-Faktor-Authentifizierung; der Sicherheitsleitfaden von n8n führt 2FA unter den empfohlenen Schutzmaßnahmen für selbstgehostete Instanzen auf.
Regelmäßige Updates. Ändere den Versions-Tag in deiner Compose-Datei, dann Pull und Neustart (Schritt 9). Lies zuerst das Changelog, denn Updates von n8n können Breaking Changes enthalten.
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, auf das du achten solltest, das nicht unbedingt sicherheitsrelevant ist, aber einen großen Unterschied macht. n8n speichert standardmäßig die Eingabe 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 du 10.000 gespeicherte Ausführungen überschreitest. Eine stark ausgelastete Instanz kann PostgreSQL in der Zwischenzeit trotzdem aufblähen.

Wenn deine Workflows gesprächig sind, verschärfe das: Setze EXECUTIONS_DATA_MAX_AGE=168, um Ausführungsdaten zu bereinigen, die älter als sieben Tage sind (die obige Compose-Datei tut das bereits), oder verzichte mit EXECUTIONS_DATA_SAVE_ON_SUCCESS=none ganz darauf, erfolgreiche Durchläufe zu speichern.

Welche Vor- Und Nachteile Hat Selbsthosting Gegenüber n8n Cloud?

Selbsthosting von n8n gibt dir eine Instanz ohne Ausführungskontingent und mit Kontrolle über die gespeicherten Daten, zum Preis eines kleinen VPS plus deiner eigenen Administration. n8n Cloud erspart dir jegliche Serverwartung, mit Ausführungsobergrenzen je nach Stufe. Die Entscheidung hängt davon ab, ob du deine Automatisierungsinfrastruktur selbst besitzen oder jemand anderen dafür bezahlen möchtest, sie zu betreiben.

Die n8n-Dokumentation formuliert es so: „n8n empfiehlt das Selbsthosting für erfahrene Benutzer. Fehler können zu Datenverlust, Sicherheitsproblemen und Ausfallzeiten führen. Wenn du keine Erfahrung mit der Verwaltung von Servern hast, empfiehlt n8n n8n Cloud.“

Hier ist ein Vergleich der beiden Optionen:

Faktor	Selbstgehostet	n8n Cloud
Monatliche Kosten	Deine VPS-Rechnung plus eventuelle Kosten für Domain, Backup-Speicher und Administration (DreamHost Stack 4: 8,99 $/Monat für 3 Monate, danach 15,99 $/Monat, Stand August 2026; Schätzungen des Drittanbieters ExpressTech für 2026: 4–8 $/Monat)	20–50 € (bei jährlicher Abrechnung), je nach Stufe
Ausführungen	Kein Kontingent; die Kapazität hängt von den Ressourcen deines Servers ab	2.500 (Starter) oder 10.000 (Pro)
Einrichtung	Die Anleitung in 11 Schritten oben	Minuten
Wartung	Updates, Backups und Überwachung liegen bei dir	Übernimmt n8n
Datenstandort	Dein Server	Infrastruktur von n8n
Updates	Manuell (Tag ändern, Pull, Neustart)	Automatisch
TLS	Caddy bezieht und erneuert Zertifikate automatisch (Aussteller wie Let’s Encrypt oder ZeroSSL)	Wird für dich erledigt
Skalierung	RAM hinzufügen oder Queue-Modus mit Redis-Workern verwenden	Höhere Planstufe wählen

Es gibt auch einen Mittelweg, den du kennen solltest. Verwaltete Plattformen wie PikaPods (etwa 3,80 $/Monat) und Elestio (etwa 17 $/Monat, laut dem Vergleich von ExpressTech) betreiben selbstgehostetes n8n, ohne dass du den Server selbst verwalten musst. Diese Dienste können den Aufwand für die Serveradministration verringern, du solltest aber prüfen, wer sich um Updates, Backups, Überwachung und Sicherheit von n8n kümmert.

Aber hier ist das größere Bild. Bei jedem gehosteten Plan ist deine Ausführungskapazität eine Abrechnungsstufe, und die Plattform legt die Stufen fest. Preise, Kontingente und Funktionen können sich rund um Workflows ändern, die du bereits aufgebaut hast.

Beim Selbsthosting liegen die Instanz und die von ihr 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 Treffen

Selbsthosting ergibt Sinn, wenn drei Dinge zusammenkommen:

Du betreibst so viele Automatisierungen, dass Ausführungsobergrenzen in der Cloud dich einschränken würden
Du möchtest deine Workflow-Daten auf einer Infrastruktur, die du kontrollierst
Du (oder jemand in deinem Team) bist bereit, die Verantwortung für Updates, Backups und Überwachung zu übernehmen

Ansonsten ist n8n Cloud eine vernünftige Wahl. Für den Starter-Plan zu zahlen, um nie über Docker-Logs nachdenken zu müssen, ist ein fairer Handel, insbesondere für ein kleines Team, das einfach möchte, dass seine Automatisierungen laufen.

Aber sobald du bereit bist, die Schwelle zum Selbsthosting zu überschreiten, fällt die Rechnung schnell eindeutig aus. Ein VPS mit 4 GB ist ein praxistauglicher, wenn auch nicht per Benchmark geprüfter Ausgangspunkt; die Produktionskapazität hängt von Gleichzeitigkeit, Datenvolumen und den verwendeten Knoten ab, also überwache die Instanz und skaliere sie mit wachsendem Bedarf. Beginne klein, rüste auf, wenn deine Workflows wachsen, und behalte die volle Kontrolle über deinen Stack.

Dieser letzte Teil ist wichtiger, als es scheinen mag. Du kannst jederzeit auf einen größeren Server umsteigen. Es ist jedoch viel schwieriger, dich von einer SaaS-Plattform zu lösen, nachdem diese ihre Preise rund um die Workflows geändert hat, die du bereits aufgebaut hast.

VPS

Besitze deinen gesamten Stack. Apps, KI, Datenbanken und mehr.

Behalte alle Zugangsdaten und Unterhaltungen auf einem Server, den du selbst kontrollierst – mit NVMe-Geschwindigkeit und unbegrenzter Bandbreite serienmäßig.

VPS-Hosting-Tarife entdecken

Häufig Gestellte Fragen Zum Selbsthosting Von n8n

Ist n8n wirklich kostenlos selbst zu hosten?

Die n8n-Software kannst du unter der Sustainable Use License kostenlos auf deinem eigenen Server betreiben. Für die selbstgehostete Community Edition (die Standardversion, die n8n auf GitHub veröffentlicht) fallen bei zulässiger Nutzung, etwa für interne Geschäftsautomatisierung, keine Lizenz- oder Ausführungsgebühren von n8n an. Der „kostenlose“ Teil bezieht sich auf die Software; du zahlst trotzdem für deinen Server sowie für eine eventuelle Domain, Backup-Speicher und Administrationszeit.

Die Lizenz schränkt den Verkauf eines Produkts, eines Dienstes oder eines Moduls ein, dessen Wert vollständig oder im Wesentlichen auf n8n-Funktionalität beruht. Lies die Lizenz-FAQ von n8n, wenn du vorhast, Kunden n8n-gestützte Funktionen anzubieten.

Was sind die Mindestsystemanforderungen für n8n?

n8n veröffentlicht Beispielwerte zur Dimensionierung statt eines festen Minimums und kennzeichnet diese Zahlen als illustrativ (sie stammen aus der OEM-Bereitstellungsdokumentation): etwa 100 MB Arbeitsspeicher im Leerlauf, ein beispielhafter Speicherbereich von 320 MB–2 GB und eine SSD-gestützte Datenbank mit 512 MB–4 GB. Als vorsichtige Startausstattung, nicht als offizielles Minimum von n8n, kannst du 2 GB für Tests und 4 GB einplanen, sobald PostgreSQL und produktive Workflows hinzukommen; überwache danach den Speicher und erweitere ihn, wenn anhaltender Druck auftritt.

Der Plan DreamHost VPS Hosting Stack 4 bietet 4 GB RAM mit NVMe-SSD-Speicher und vollem Root-Zugang für den Betrieb selbstgehosteter Anwendungen wie n8n. Details findest du bei den VPS-Hosting-Plänen.

Verwende für den Produktivbetrieb PostgreSQL statt SQLite und bevorzuge SSD-Speicher, denn n8n führt ihn als Best Practice für Datenbanken auf.

Kann ich n8n lokal statt auf einem VPS betreiben?

Ja — ein einziger Docker-Befehl startet n8n auf deinem eigenen Rechner, und das ist eine großartige Möglichkeit, Workflows zu testen, bevor du dich auf einen Server festlegst. Der Haken sind Webhooks: Workflows, die von externen Diensten ausgelöst werden, brauchen eine Instanz, die aus dem Internet erreichbar ist, und das ist ein Laptop hinter einem Heimrouter standardmäßig nicht. Portweiterleitung, VPNs und Tunnel können das umgehen, jeweils mit eigenem Einrichtungsaufwand und eigenen Sicherheitskompromissen.

n8n bietet einen Tunnel-Dienst, der Webhooks an eine lokale Instanz weiterleitet, aber seine Docker-Dokumentation sagt unmissverständlich, dass der Tunnel „nur für lokale Entwicklung und Tests gedacht“ ist und nicht im Produktivbetrieb verwendet werden sollte. Für alles, was rund um die Uhr läuft, verwende einen VPS.

Kann ich von Zapier zu n8n migrieren?

Erwarte keinen Ein-Klick-Import. Plane ein, deine Workflows im visuellen Editor von n8n neu aufzubauen, statt sie aus Zapier zu importieren.

Die gute Nachricht: n8n bietet über 400 Integrationen, aber prüfe jede App, jeden Trigger und jede Aktion, die deine aktuellen Workflows nutzen, bevor du die Migration planst. Einfache Workflows sind schnell nachgebaut; komplexe mehrstufige Abläufe dauern länger.

Wie aktualisiere ich eine selbstgehostete n8n-Instanz?

Ändere den Versions-Tag in deiner docker-compose.yml auf das gewünschte Release und führe dann docker compose pull und anschließend docker compose up -d aus. Mit einem fest gepinnten Tag wie docker.n8n.io/n8nio/n8n:2.36.7 ändert ein Pull allein nichts — du entscheidest über jedes Upgrade, indem du den Tag änderst, und genau darum geht es beim Pinnen. (Wenn du stattdessen den Tag latest verwendest, genügen Pull und Neustart, aber jeder Neustart wird zu einem Überraschungs-Upgrade.)

Sichere deine PostgreSQL-Datenbank vor größeren Versionsupdates. Das Backup-Skript aus der Anleitung oben erledigt das, oder du führst pg_dump direkt im PostgreSQL-Container aus.

Unachtsame Updates machen Dinge kaputt, und n8n veröffentlicht fast jede Woche eine neue Minor-Version. Die eigene Update-Anleitung von n8n fordert dich auf, vor dem Upgrade das Changelog der Breaking Changes zu lesen, also lies es, bevor du pullst. Der Neustart selbst geht schnell; das Lesen des Changelogs ist der Teil, der deine Zeit verdient.

Ist selbstgehostetes n8n sicher genug für Geschäftsdaten?

Beim Selbsthosting bestimmst du, wo n8n Workflow-Definitionen, Zugangsdaten und Ausführungsdaten speichert. Verbundene Dienste erhalten jedoch weiterhin alle Daten, die deine Workflows an sie senden, und die Absicherung des Servers bleibt deine Verantwortung.

Folge der Sechs-Punkte-Checkliste aus dem Sicherheitsabschnitt oben: HTTPS, Firewall, Docker-Isolierung, starke Authentifizierung mit 2FA, regelmäßige Updates und getestete Backups. Das n8n-Team pflegt einen Sicherheitsleitfaden, der zusätzliche Aspekte für den Produktivbetrieb abdeckt, von Sicherheitsaudits bis zur Zwei-Faktor-Authentifizierung.