Wie du n8n auf einem Hetzner-Server in der EU betreibst: Compose-Setup, TLS, Backups, Queue-Mode mit Workern und der Wartungsaufwand, den dir keiner vorher sagt.
Warum ein EU-Server der Ausgangspunkt ist
n8n ist ein Open-Source-Automatisierungstool, mit dem du Datenflüsse zwischen APIs ohne festen Anbieter baust. Sobald durch diese Flüsse personenbezogene Daten laufen, also Namen, E-Mail-Adressen, Telefonnummern, bist du in der DSGVO. Der erste praktische Hebel ist der Serverstandort. Hetzner betreibt Rechenzentren in Nürnberg, Falkenstein und Helsinki, alle innerhalb der EU. Damit liegt der Datenverarbeitungsort dort, wo das Recht gilt, dem du ohnehin unterliegst.
Das allein macht dich nicht konform. Du brauchst einen Auftragsverarbeitungsvertrag mit Hetzner, den du im Kundenkonto abschließt. Und du musst wissen, an welche externen Dienste n8n Daten weitergibt. Ein Workflow, der Kontakte an ein US-CRM schickt, verlässt die EU, egal wie sauber dein Server steht. Der Server ist die Basis, nicht die ganze Antwort.
Das Compose-Setup
Du betreibst n8n als Docker-Container. Eine docker-compose.yml mit drei Diensten reicht für den Start: n8n selbst, eine PostgreSQL-Datenbank und ein Reverse-Proxy. SQLite als Standard-Datenbank funktioniert, skaliert aber schlecht und macht Backups unhandlich. Postgres ist der saubere Weg.
Wichtig sind die Umgebungsvariablen. Setze N8N_ENCRYPTION_KEY einmal fest und sichere ihn getrennt, denn ohne diesen Schlüssel sind deine gespeicherten Credentials nach einem Umzug nicht mehr lesbar. DB_TYPE=postgresdb verbindet n8n mit der Datenbank. Über N8N_HOST und WEBHOOK_URL legst du die öffentliche Domain fest, sonst zeigen Webhook-URLs ins Leere. Lege Datenbank-Volumes auf ein benanntes Docker-Volume, nicht in den Container, sonst ist nach einem Update alles weg.
Reverse-Proxy und TLS
n8n lauscht intern auf Port 5678 ohne Verschlüsselung. Diesen Port stellst du niemals direkt ins Internet. Davor gehört ein Reverse-Proxy, der TLS terminiert. Caddy ist hier die pragmatische Wahl, weil es Zertifikate von Let us Encrypt automatisch holt und erneuert. Zwei Zeilen Caddyfile mit deiner Domain und der internen Adresse genügen.
Wer Traefik oder nginx bevorzugt, bekommt dasselbe Ergebnis mit mehr Konfiguration. Entscheidend ist, dass nach außen nur Port 443 offen ist und der n8n-Port ausschließlich im internen Docker-Netz erreichbar bleibt. Eine Firewall-Regel auf dem Hetzner-Server, die alles außer 443 und deinem SSH-Port blockt, gehört dazu. Die Cloud-Firewall von Hetzner machst du im Webinterface, sie greift vor dem Server.
Backups, die im Ernstfall funktionieren
Ein Backup, das du nie zurückgespielt hast, ist eine Vermutung. Du sicherst zwei Dinge: die Postgres-Datenbank und den Encryption-Key. Die Datenbank dumpst du per pg_dump in einen Cron-Job, der täglich läuft und die Dumps auf einen getrennten Speicher schiebt, etwa eine Hetzner Storage Box oder einen S3-kompatiblen Bucket in der EU. Halte mehrere Generationen vor, nicht nur die letzte.
Den Encryption-Key sicherst du außerhalb des Servers in deinem Passwortmanager. Ohne ihn ist der schönste Datenbank-Dump nutzlos, weil die Credentials verschlüsselt darin liegen. Teste die Wiederherstellung einmal auf einem zweiten Server. Erst wenn ein frisch aufgesetztes n8n deine Workflows mit funktionierenden Credentials zeigt, hast du ein echtes Backup.
Queue-Mode mit Workern
Im Standardmodus führt ein einziger n8n-Prozess alles aus. Bei mehreren parallelen oder langlaufenden Workflows wird das zum Engpass und ein Absturz reißt laufende Executions mit. Der Queue-Mode trennt das auf: ein Main-Prozess nimmt Webhooks an und legt Jobs in eine Redis-Queue, mehrere Worker-Container arbeiten sie ab. Du skalierst, indem du Worker hinzufügst.
Dafür ergänzt du Redis im Compose-Stack und setzt EXECUTIONS_MODE=queue. Die Worker laufen mit demselben Image, aber dem Kommando worker. Für die meisten kleinen Setups ist das Overkill und der Standardmodus reicht. Sobald Volumen und Zuverlässigkeit zählen, ist Queue-Mode der Weg, den wir in produktiven Pipelines standardmäßig fahren.
Die Wartung, die bleibt
Selbst gehostet heißt, du bist der Betreiber. n8n veröffentlicht häufig Updates, teils mit Sicherheitsbezug. Du musst Image-Versionen pinnen, Changelogs lesen und Updates testen, bevor du sie produktiv ziehst. Ein blindes latest kann dir über Nacht einen Workflow brechen, weil sich ein Node-Verhalten geändert hat.
Dazu kommen Betriebssystem-Updates, Zertifikatsüberwachung, Monitoring auf Speicher und Festplatte sowie das Aufräumen alter Execution-Daten, die die Datenbank sonst zulaufen lassen. Das ist machbar und keine Raketenwissenschaft, aber es ist wiederkehrende Arbeit. Wer das nicht selbst tragen will, gibt den Betrieb ab. Wir setzen n8n auf, härten es und halten es aktuell, der Server und die Eigentumsrechte bleiben dabei vollständig bei dir. Was das konkret kostet, steht unter Preise, einen Termin machst du über Kontakt.