n8n selbst hosten und DSGVO-konform betreiben

Seit dem 5. September 2026 läuft meine eigene n8n-Instanz auf einem gemieteten Server. Hier steht, wie sie aufgebaut ist, was die DSGVO trotz Selbst-Hosting von dir verlangt und woran ich beim Einrichten hängen geblieben bin.

Die Kurzantwort

Ja, n8n lässt sich DSGVO-konform selbst betreiben, und für die Nutzung im eigenen Unternehmen kostet die Software nichts. Selbst hosten löst aber nur einen Teil der Aufgabe. Deine Daten liegen dann auf deinem Server, doch sobald ein Workflow OpenAI, Anthropic oder Google aufruft, verlassen sie ihn wieder. Die Pflichten aus der DSGVO bleiben also bestehen, sie liegen nur bei dir.

• Lizenz: Die Sustainable Use License erlaubt die Nutzung „only for your own internal business purposes or for non-commercial or personal use“. n8n als bezahlten Dienst für andere zu betreiben, deckt sie nicht ab.
• Technik: Docker Compose, PostgreSQL 17 oder 18, davor ein Reverse Proxy mit TLS. Der n8n-Container selbst gibt keinen Port nach außen frei.
• Pflichten: Auftragsverarbeitungsvertrag mit dem Hoster (Art. 28 DSGVO), Eintrag im Verarbeitungsverzeichnis (Art. 30), technische und organisatorische Maßnahmen (Art. 32) und eine Prüfung jeder Übermittlung in ein Drittland (Art. 44 ff.).
• Betrieb: mindestens einmal im Monat aktualisieren. Zwischen Ende 2025 und Anfang 2026 wurden mehrere kritische Lücken bekannt, eine davon mit CVSS 10.

Warum ich n8n nicht in der Cloud nutze

n8n gibt es gemietet und zum Selbstbetrieb. Die Preise stammen von n8n.io und haben den Stand vom 13. September 2026, jeweils bei jährlicher Abrechnung:

Der Preis war für mich trotzdem nicht der Hauptgrund. Workflows greifen auf Postfächer, Kundenanfragen und Belege zu. Läuft n8n auf meinem Server, weiß ich, wo diese Daten liegen, wer darauf zugreifen kann und wie lange die Protokolle der Ausführungen aufgehoben werden. n8n Cloud stellt einen Auftragsverarbeitungsvertrag auf Anfrage bereit und veröffentlicht eine Liste der Unterauftragsverarbeiter. Das lässt sich sauber lösen, es ist aber ein Glied mehr in der Kette, das ich prüfen müsste.

Was der kostenlosen Community Edition fehlt, solltest du vorher kennen: Single Sign-on, getrennte Umgebungen für Test und Produktion, Versionierung über Git, externe Speicher für Zugangsdaten und Log-Streaming gibt es erst ab Business. Für einen Kleinbetrieb mit einer Handvoll Workflows habe ich davon bisher nichts vermisst. Die Workflows lege ich zusätzlich als JSON-Dateien in einem eigenen Ordner ab, damit ich sie ohne Git-Funktion in n8n wieder importieren kann.

Mein Aufbau mit Docker, PostgreSQL und Caddy

Die Instanz läuft auf einem VPS bei IONOS, der ohnehin schon andere Dienste in Docker trägt. Dazu gehören zwei Container in einem Compose-Projekt: n8n selbst und die Datenbank. Beide schreiben ihre Daten per Bind-Mount in feste Ordner auf dem Host. So kann ich sie sichern, ohne erst in Docker-Volumes suchen zu müssen.

So würde ich die Compose-Datei heute anlegen. Sie ist gekürzt, die Adresse ist ein Platzhalter, und die Zugangsdaten stehen in einer eigenen .env:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:2.37.10
    restart: unless-stopped
    env_file: .env
    environment:
      N8N_EDITOR_BASE_URL: https://n8n.example.de/
      N8N_WEBHOOK_URL: https://n8n.example.de/
      N8N_PROXY_HOPS: "1"
      GENERIC_TIMEZONE: Europe/Berlin
      N8N_DIAGNOSTICS_ENABLED: "false"
      EXECUTIONS_DATA_MAX_AGE: "168"
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: n8n-db
    volumes:
      - /srv/n8n/n8n:/home/node/.n8n
    networks: [intern, proxy]

  n8n-db:
    image: postgres:17-alpine
    restart: unless-stopped
    env_file: .env
    volumes:
      - /srv/n8n/db:/var/lib/postgresql/data
    networks: [intern]

networks:
  intern:
  proxy:
    external: true

Wichtig ist hier vor allem, was fehlt, nämlich ein ports-Eintrag. n8n hängt in zwei Docker-Netzen. Im internen Netz sieht es nur seine Datenbank, im Proxy-Netz nur Caddy. Von außen erreichbar ist allein Caddy, an der Firewall musste ich deshalb nichts ändern. Die Datenbank hat überhaupt keinen Weg nach draußen.

Caddy holt das Zertifikat bei Let’s Encrypt selbst und leitet HTTP auf HTTPS um. Der Block für n8n ist kurz:

n8n.example.de {
  reverse_proxy n8n:5678 {
    flush_interval -1
  }
}

Die Zeile flush_interval -1 sieht nach einer Kleinigkeit aus. Warum ich ohne sie nicht auskam, steht weiter unten bei den Fallstricken.

Die Einstellungen, auf die es ankommt

Die Beschreibungen folgen der offiziellen n8n-Dokumentation. Die Werte sind die, mit denen meine Instanz läuft oder die ich nach der Recherche ändern würde.

• N8N_ENCRYPTION_KEY verschlüsselt alle Zugangsdaten, die du in Workflows hinterlegst. Setzt du ihn nicht, erzeugt n8n selbst einen und legt ihn im Datenordner ab. Ich erzeuge ihn mit openssl rand und lege ihn in die .env mit den Rechten 600. Er muss in jede Sicherung, denn ohne ihn ist ein Backup der Datenbank wertlos.
• N8N_EDITOR_BASE_URL und N8N_WEBHOOK_URL tragen die öffentliche Adresse. Hinter einem Proxy weiß n8n sonst nicht, unter welcher Adresse es erreichbar ist. Die ältere Schreibweise WEBHOOK_URL ist seit Version 2.35.0 veraltet. Sie funktioniert noch, schreibt aber eine Warnung ins Log. Bei mir steht sie noch drin.
• N8N_PROXY_HOPS nennt die Zahl der Reverse Proxies vor n8n. Voreingestellt ist 0, mit Caddy davor gehört eine 1 hinein.
• GENERIC_TIMEZONE steht ab Werk auf America/New_York. Zeitgesteuerte Workflows laufen dann nach New Yorker Zeit, deshalb Europe/Berlin.
• N8N_DIAGNOSTICS_ENABLED=false schaltet die anonyme Telemetrie ab. Als Nebenwirkung fällt im Code-Knoten die Funktion „Ask AI“ weg.
• Ausführungsdaten: n8n speichert zu jedem Lauf, was durch die Knoten gelaufen ist, also auch Namen, Mailadressen und Inhalte. EXECUTIONS_DATA_PRUNE ist ab Werk aktiv und löscht nach EXECUTIONS_DATA_MAX_AGE Stunden, voreingestellt sind 336, also 14 Tage. Mit EXECUTIONS_DATA_SAVE_ON_SUCCESS=none werden erfolgreiche Läufe gar nicht erst gespeichert, fehlgeschlagene bleiben zur Fehlersuche erhalten. Für die Datenminimierung nach Art. 5 DSGVO ist das der wirksamste Hebel.

Ein Hinweis für alle, die ältere Anleitungen abschreiben: N8N_RUNNERS_ENABLED taucht dort oft auf, ist aber seit n8n 2.0 als veraltet markiert.

Was die DSGVO trotzdem verlangt

Wer selbst hostet, gibt die Verantwortung nicht ab. Er holt sie zu sich.

Die folgenden Punkte gelten für jeden Workflow, der personenbezogene Daten verarbeitet. Das ist meine Arbeitsliste und keine Rechtsberatung.

• Auftragsverarbeitung, Art. 28: Der Hoster verarbeitet die Daten auf deinem Server in deinem Auftrag. Mit ihm brauchst du einen Auftragsverarbeitungsvertrag, auch wenn du nur Rechenleistung mietest.
• Verarbeitungsverzeichnis, Art. 30: Jeder Workflow mit personenbezogenen Daten ist eine Verarbeitung. Dazu gehören ein Eintrag mit Zweck, Datenkategorien, Empfängern und Löschfristen.
• Technische und organisatorische Maßnahmen, Art. 32: Zugriffsschutz, Verschlüsselung, Sicherungen, Updates und Löschfristen für Protokolle. Die Einstellungen oben sind genau das, du musst sie nur aufschreiben.
• Drittlandübermittlung, Art. 44 ff.: Jeder Knoten, der eine API in den USA aufruft, schickt Daten aus der EU hinaus. Dafür brauchst du eine Rechtsgrundlage.

Für die USA ist das derzeit meist das EU-US Data Privacy Framework, also der Angemessenheitsbeschluss der EU-Kommission vom 10. Juli 2023. Er gilt für Anbieter, die sich darunter zertifiziert haben. Das Gericht der EU hat die Klage Latombe gegen die Kommission (T-553/23) am 3. September 2025 abgewiesen. Gegen das Urteil ist ein Rechtsmittel beim Europäischen Gerichtshof anhängig (C-703/25 P). Heute trägt der Beschluss also, eine Garantie für die nächsten Jahre ist er nicht.

Wer die Frage ganz umgehen will, hat mehrere Wege. Mistral verarbeitet API-Daten nach eigener Aussage standardmäßig in der EU. Bei Azure OpenAI bleibt die Verarbeitung mit der EU Data Zone innerhalb der EU-Datengrenze. OpenAI selbst bietet Geschäftskunden eine Datenresidenz in Europa an. Am weitesten geht ein lokales Modell über den Ollama-Knoten, der zu n8n gehört. Dafür braucht der Server allerdings genug Rechenleistung.

Der erste echte Workflow: Sprachmemos werden Aufgaben

Seit dem 11. September 2026 läuft auf der Instanz der erste Workflow, der jeden Tag Arbeit abnimmt. Ich diktiere eine Sprachnotiz am Handy, die Datei landet per Syncthing in einem Ordner auf dem Server, und n8n sieht jede Minute nach. Ist eine Datei 30 Sekunden lang unverändert, geht es los: Transkription mit whisper-1 von OpenAI, danach zerlegt gpt-4.1-mini den Text in einzelne Einträge und ordnet jeden einem von drei Projekten zu. Heraus kommen Aufgaben in meinem selbst gehosteten Vikunja. Liegt die Sicherheit der Zuordnung unter 0,6, landet der Eintrag in der Spalte „Unklar“, statt still im falschen Projekt zu verschwinden. Die Audiodatei wandert danach in den Ordner „Verarbeitet“ oder „Fehler“.

Hier gehört auch die DSGVO-Frage ehrlich hin. Dieser Workflow schickt meine Stimme an OpenAI in die USA. Eine selbst gehostete Transkription mit faster-whisper hatte ich geprüft und verworfen, weil der Server keine Grafikkarte hat. Für meine eigenen Notizen ist das eine bewusste Entscheidung. Sobald Gespräche mit Kunden hineinkämen, müsste die Drittlandfrage neu geprüft werden, oder die Transkription wandert auf einen EU-Dienst oder eigene Hardware.

Drei weitere Workflows liegen als Gerüst in der Instanz und sind noch nicht aktiv. Einer erinnert mich an eine Kundenanfrage, wenn ich sie nach sieben Tagen noch nicht erledigt habe. Einer entwirft Beiträge für Social Media, und einer sammelt Belege aus einem Postfach ein. Bei allen dreien stehen noch Entscheidungen aus, die nichts mit n8n zu tun haben, zum Beispiel wohin die Belege am Ende gehören.

Wo ich hängen geblieben bin

PostgreSQL 16 ist nur noch geduldet

Ich habe mit postgres:16-alpine angefangen. n8n 2.37 meldet beim Start, dass Version 16 außerhalb des unterstützten Bereichs liegt und nur noch Kompatibilitätsunterstützung bekommt. Die Dokumentation nennt als unterstützt die zwei aktuell gepflegten Hauptversionen, Stand Juli 2026 sind das 17 und 18, dazu 16 zur Kompatibilität. Der Betrieb läuft, der Wechsel steht bei mir noch aus. Wer neu anfängt, sollte gleich 17 oder 18 nehmen und sich den Umzug der Datenbank sparen.

Caddy puffert den Live-Kanal des Editors

Ohne eine Zusatzzeile meldet die Oberfläche hinter Caddy ständig einen Verbindungsverlust. Die Ursache: Der Editor hält unter /rest/push einen dauerhaften Datenstrom (Server-Sent Events) offen, und Caddy puffert ihn, statt ihn sofort weiterzureichen. flush_interval -1 im reverse_proxy-Block schaltet das Puffern ab.

Dateizugriff ist ab Werk gesperrt

Für die Sprachmemos muss n8n Dateien lesen und verschieben. n8n 2.37 lehnte jeden Zugriff mit „Access to the file is not allowed“ ab, obwohl der Ordner korrekt in den Container eingebunden war. Nötig war N8N_RESTRICT_FILE_ACCESS_TO mit dem erlaubten Ordner. Für die Dateifunktionen im Code-Knoten kam NODE_FUNCTION_ALLOW_BUILTIN=fs,path dazu. Die Sperre ist sinnvoll, weil ein Workflow sonst im ganzen Container lesen könnte. Also nur freigeben, was wirklich gebraucht wird.

docker compose exec frisst das Skript

Ich richte Server gern über ein Skript ein, das per SSH hinübergeschickt wird. Steht darin docker compose exec -T … ohne </dev/null, liest der Befehl die Standardeingabe, und das ist der Rest des Skripts. Alle folgenden Befehle laufen dann einfach nicht, ohne jede Fehlermeldung. Genau so ist es mir beim Einrichten passiert.

Updates und bekannte Sicherheitslücken

Die n8n-Dokumentation ist beim Thema Updates deutlich: „Try to update at least once a month.“ Wie ernst das gemeint ist, zeigen drei Lücken aus den offiziellen Sicherheitsmeldungen auf GitHub:

Alle drei erlauben es, Code auf dem Server auszuführen. Die erste braucht dafür nicht einmal ein Konto. Eine selbst gehostete Instanz mit öffentlichen Webhooks ist ein Ziel, und für ihre Updates ist niemand zuständig außer dir. In der Compose-Datei oben steht deshalb eine feste Version statt latest. So passiert ein Update, wenn ich es entscheide, vorher gesichert und mit einem Blick in die Änderungsliste:

# Version in docker-compose.yml anheben, dann:
docker compose pull
docker compose up -d
docker compose logs -f n8n

Checkliste

• Lizenz geprüft: Nutzung nur für eigene interne Zwecke
• Auftragsverarbeitungsvertrag mit dem Hoster abgeschlossen
• n8n ohne eigenen Port, erreichbar nur über den Reverse Proxy mit TLS
• PostgreSQL 17 oder 18, Datenordner als Bind-Mount
• N8N_ENCRYPTION_KEY selbst erzeugt und in der Sicherung
• Öffentliche Adresse, Proxy-Hops und Zeitzone gesetzt
• Aufbewahrung der Ausführungsdaten verkürzt, erfolgreiche Läufe nach Bedarf gar nicht gespeichert
• Dateizugriff nur auf die Ordner freigegeben, die ein Workflow braucht
• Jeder Workflow mit personenbezogenen Daten im Verarbeitungsverzeichnis
• Jeder Aufruf einer US-API auf seine Rechtsgrundlage geprüft, sonst EU-Anbieter oder lokales Modell
• Feste Version statt latest, Update mindestens monatlich

Häufige Fragen

Ist n8n selbst gehostet kostenlos?

Die Community Edition ist kostenlos und begrenzt die Zahl der Ausführungen nicht. Du zahlst nur den Server. Funktionen wie Single Sign-on, getrennte Umgebungen oder Versionierung über Git gibt es erst in der Business-Variante für 667 € im Monat bei jährlicher Abrechnung.

Darf ich n8n im Unternehmen für Kunden einsetzen?

Die Sustainable Use License erlaubt die Nutzung für eigene interne Geschäftszwecke. Automatisierst du damit die Abläufe deines eigenen Betriebs, ist das gedeckt. Betreibst du n8n dagegen als bezahlten Dienst für andere, deckt die Lizenz das nicht ab. Im Zweifel lohnt ein Blick in den Lizenztext, er ist kurz.

Brauche ich PostgreSQL, oder reicht SQLite?

Ohne weitere Einstellung nutzt n8n SQLite, für den Einstieg genügt das. Ich nutze PostgreSQL in einem eigenen Container. Wenn du dich ebenfalls dafür entscheidest, nimm gleich Version 17 oder 18.

Ist n8n Cloud DSGVO-konform?

n8n stellt einen Auftragsverarbeitungsvertrag auf Anfrage bereit und nennt seine Unterauftragsverarbeiter, darunter Microsoft Azure und Hetzner. In welchem Land die Cloud-Instanzen laufen, habe ich in den öffentlichen Unterlagen nicht eindeutig gefunden. Das würde ich vor dem Vertrag direkt bei n8n erfragen.

Sind meine Daten sicher, nur weil n8n auf meinem Server läuft?

Nein. Sie bleiben nur dort, solange kein Workflow sie an einen externen Dienst schickt. Wichtiger ist deshalb der Blick auf jeden einzelnen Knoten, der eine fremde API aufruft, dazu regelmäßige Updates.

Quellen

Stand der Recherche: 13. September 2026.

• n8n Sustainable Use License
• n8n Preise
• n8n Dokumentation: Datenbank wählen
• n8n Dokumentation: n8n aktualisieren
• n8n Sicherheitsmeldungen auf GitHub
• n8n Unterauftragsverarbeiter
• Datenschutz-Grundverordnung auf EUR-Lex
• EU-Kommission: Fragen und Antworten zum EU-US Data Privacy Framework