Der Wechsel von der n8n-Cloud zum eigenen Server: Diese Anleitung zeigt Schritt für Schritt, wie KMU n8n mit Docker selbst hosten – inklusive HTTPS, Backup und Update-Weg.
Der erste Agent aus unserer n8n-Anleitung läuft seit ein paar Wochen. Er funktioniert gut genug, dass ein zweiter Workflow dazukommt, dann ein dritter. Und irgendwann stellt sich eine Frage, die am Anfang niemand gestellt hat: Soll die gesamte Unternehmenslogik wirklich dauerhaft auf einem gemieteten Cloud-Konto laufen – mit monatlicher Gebühr pro Workflow und den eigenen Daten auf fremden Servern?
Für viele KMU ist der Punkt, an dem n8n vom Experiment zur Infrastruktur wird, genau der richtige Moment, um selbst zu hosten. Diese Anleitung zeigt den Weg mit Docker – von der Installation bis zum ersten produktiven Neustart.
Docker verpackt eine Anwendung inklusive aller Abhängigkeiten in einen sogenannten Container: ein abgeschlossenes, überall gleich laufendes Paket. Statt n8n und seine Voraussetzungen (Node.js, Datenbank, Konfiguration) einzeln auf einem Server einzurichten, startet man einen fertigen n8n-Container mit einem einzigen Befehl.
Selbst gehostetes n8n unterscheidet sich vom Cloud-Angebot in drei Punkten:
Auf einem frischen Server (Ubuntu/Debian) installiert der offizielle Docker-Installer alles Nötige in einem Rutsch:
Danach steht der Befehl docker bereit.
n8n muss seine Daten (Workflows, Zugangsdaten, Ausführungsprotokolle) dauerhaft speichern – auch über einen Container-Neustart hinaus. Dafür legt man ein sogenanntes Volume an:
Der einfachste Start für einen ersten Test:
Damit läuft n8n unter http://ihre-server-ip:5678 – zum Ausprobieren ausreichend, für den produktiven Einsatz fehlen aber noch HTTPS und eine feste Domain (Schritt 4).
Für den dauerhaften Betrieb bündelt man die Konfiguration besser in einer docker-compose.yml, inklusive eines Reverse Proxys (z. B. Caddy), der automatisch ein HTTPS-Zertifikat besorgt:
Die zugehörige Caddyfile braucht nur zwei Zeilen:
Gestartet wird alles mit docker compose up -d. Caddy besorgt das HTTPS-Zertifikat automatisch, sobald die Domain auf den Server zeigt.
Beim ersten Aufruf von https://n8n.ihrefirma.de führt n8n selbst durch die Einrichtung des Admin-Kontos. Ab hier verhält sich die selbst gehostete Instanz genauso wie die Cloud-Version aus der ersten Anleitung – Workflows, AI-Agent-Baustein und alle Integrationen funktionieren identisch.
Das Volume n8n_data enthält alles Wichtige. Ein einfacher, täglicher Cronjob sichert es zuverlässig:
Ohne Backup ist ein selbst gehosteter Server ein Risiko, kein Vorteil – dieser Schritt gehört nicht ans Ende der To-do-Liste, sondern in die Erstinstallation.
n8n entwickelt sich schnell; Updates lohnen sich regelmäßig, sollten aber nicht ungeprüft durchlaufen:
Vor größeren Versionssprüngen lohnt ein Blick in die offiziellen Release-Hinweise von n8n – und ein frisches Backup, bevor der Befehl läuft.
Kein HTTPS von Anfang an. Webhooks und OAuth-Verbindungen (z. B. zu Google, Microsoft) verlangen meist eine sichere Verbindung. Ohne Reverse Proxy mit Zertifikat funktionieren viele Integrationen gar nicht erst.
Volume vergessen. Wer n8n ohne -v startet oder testet, verliert bei jedem Container-Neustart sämtliche Workflows. Das Volume ist keine Option, sondern die Grundvoraussetzung.
Server-Wartung unterschätzt. Ein eigener Server bedeutet eigene Verantwortung für Sicherheitsupdates des Betriebssystems, nicht nur für n8n selbst. Wer dafür keine Kapazität hat, ist mit der n8n-Cloud oder einem verwalteten Hosting-Angebot oft besser bedient.
Der Wechsel von der Cloud-Miete zum eigenen Server wirkt zunächst wie eine rein technische Entscheidung. Sie ist es nicht ganz.
Wer entscheidet, die eigene Automatisierung selbst zu hosten, entscheidet mit derselben Bewegung, wofür er die Verantwortung übernehmen will – und wofür nicht mehr. Das Backup wird plötzlich zur eigenen Aufgabe statt zum Kleingedruckten eines Anbieters. Die Update-Frage stellt sich nicht mehr automatisch, sondern muss jemand aktiv stellen. Kontrolle und Verantwortung kommen im selben Paket; das eine ist ohne das andere nicht zu haben.
Genau diese Verschiebung – von der bequemen, aber fremdbestimmten Lösung zur eigenen, aber verantworteten – begegnet einem an vielen Stellen, sobald KI-Systeme zur festen Infrastruktur werden. Wer tiefer verstehen will, warum diese Verantwortung sich nicht wegautomatisieren lässt, findet das in KI-Agenten, MCP, Context Engineering: Grenzen der Technik.
Wenn die Server-Frage größer wirkt als die Workflow-Frage: Genau dafür gibt es unser Strategiegespräch.
Wenn Sie n8n selbst hosten möchten, aber lieber jemanden beauftragen, der Ihnen die Infrastruktur einrichtet, sichert und betreibt: Unsere n8n-Agentur bietet genau diesen verwalteten Weg.
Ein kleiner Server für den Einstieg liegt bei ca. 5–10 €/Monat – unabhängig davon, wie viele Workflows oder Ausführungen laufen. Ab einer gewissen Nutzungsmenge ist das günstiger als die gestaffelten Cloud-Preise.
Die Grundinstallation ist in wenigen Minuten erledigt. Der Aufwand steckt im produktiven Feinschliff – HTTPS, Backup, Updates –, nicht in n8n selbst.
Für kleine Workflow-Mengen reicht auch sehr sparsame Hardware. Sobald mehrere Agenten mit größeren Sprachmodellen dauerhaft laufen, lohnt sich ein regulärer Cloud-Server mit mehr Arbeitsspeicher.
Ja. Workflows lassen sich exportieren und in die selbst gehostete Instanz importieren; Zugangsdaten müssen aus Sicherheitsgründen neu hinterlegt werden.