Categories

n8n mit Docker und Caddy: HTTPS per IP im LAN

n8n mit Docker und Caddy sicher im LAN betreiben: HTTPS direkt über eine IP-Adresse

 

n8n ist eine leistungsfähige Plattform zur Workflow-Automatisierung, die sich mit Docker schnell auf einem eigenen Linux-Server betreiben lässt. Ein einfacher Containerstart reicht für erste Tests aus. Sobald jedoch weitere Computer im lokalen Netzwerk auf die n8n-Weboberfläche zugreifen sollen, sollte die Verbindung per HTTPS verschlüsselt werden. Genau hier kommt Caddy als Reverse Proxy ins Spiel.

Diese Anleitung zeigt eine vollständig funktionsfähige Installation von n8n und Caddy auf einem Ubuntu-Docker-Host. Der Zugriff erfolgt bewusst direkt über die private IP-Adresse 10.10.5.162 ohne öffentliche Domain und ohne lokalen DNS-Namen. Caddy erstellt dafür eine interne Zertifizierungsstelle und übernimmt die TLS-Verschlüsselung auf Port 443. Die Anleitung eignet sich für Einsteiger, Entwickler, Linux-Administratoren und Windows-Systemadministratoren, die n8n sicher in einem Heimnetz, Labor oder Unternehmens-LAN bereitstellen möchten.

Überblick: Was bewirkt dieses n8n-Docker-Setup?

Bei dieser Lösung handelt es sich nicht um ein einzelnes Bash-Skript, sondern um eine reproduzierbare Folge von Docker-Befehlen und eine kleine Caddy-Konfigurationsdatei. Docker betreibt zwei voneinander getrennte Container:

Der n8n-Container stellt die Automatisierungsplattform intern auf Port 5678 bereit.

Der caddy-Container nimmt verschlüsselte HTTPS-Verbindungen auf Port 443 entgegen.

Ein benutzerdefiniertes Docker-Netzwerk verbindet beide Container.

Ein persistentes Docker-Volume schützt die n8n-Daten vor dem Verlust bei Containerupdates.

Caddys Daten-Volume speichert die interne Zertifizierungsstelle, Zertifikate und private Schlüssel.

Ein Client öffnet https://10.10.5.162. Docker leitet Port 443 an Caddy weiter. Caddy entschlüsselt die Anfrage und überträgt sie innerhalb des isolierten Docker-Netzwerks an n8n:5678. Der n8n-Port wird nicht auf dem Docker-Host veröffentlicht und ist deshalb nicht direkt aus dem LAN erreichbar.

Die wichtigsten Vorteile sind eine verschlüsselte Weboberfläche, ein automatischer Start nach Serverneustarts, persistente Daten und eine klare Trennung zwischen dem öffentlich erreichbaren Reverse Proxy und der internen Anwendung.

Typische Einsatzbereiche für n8n mit HTTPS im lokalen Netzwerk

Dieses Setup eignet sich für verschiedene technische Umgebungen:

• Einsteiger und Homelab-Betreiber: n8n kann sicher von mehreren PCs genutzt werden, ohne eine öffentliche Domain zu registrieren.
• Entwickler: Webhooks, APIs und Automatisierungsabläufe lassen sich in einer kontrollierten Testumgebung entwickeln.
• Linux-Administratoren: Container, Volumes und Netzwerke können mit bekannten Docker-Werkzeugen verwaltet werden.
• Windows-Administratoren: Die n8n-Oberfläche ist über einen normalen Browser erreichbar; Caddys Stammzertifikat lässt sich in den Windows-Zertifikatsspeicher importieren.
• Kleine Unternehmen: Interne Prozesse können automatisiert werden, ohne n8n direkt ins Internet zu stellen.
• Schulungs- und Laborumgebungen: Die Architektur demonstriert verständlich das Zusammenspiel von Docker, Reverse Proxy, TLS und interner PKI.

Wichtig: Eine private Adresse wie 10.10.5.162 ist aus dem Internet nicht erreichbar. Externe Cloud-Dienste können Webhooks an diese Adresse nur aufrufen, wenn eine geeignete VPN-, Tunnel- oder öffentliche Proxy-Lösung ergänzt wird.

Voraussetzungen und Abhängigkeiten

Für die Installation werden ein Linux-Server, Docker Engine, Administratorrechte und eine feste LAN-IP benötigt. Die hier dokumentierte Installation wurde auf Ubuntu mit der Server-IP 10.10.5.162 umgesetzt.

Folgende Punkte sollten vorab erfüllt sein:

1. Docker Engine läuft auf dem Linux-Server.
2. Der Benutzer darf Docker mit sudo ausführen.
3. Die IP-Adresse 10.10.5.162 ist statisch oder per DHCP reserviert.
4. TCP-Port 443 ist auf dem Server noch frei.
5. Der zugreifende Windows- oder Linux-PC erreicht die Server-IP.
6. Auf dem Router existiert keine Portweiterleitung aus dem Internet auf Port 443.

Docker sollte können Sie über diese Anleitung installieren.

Installation

*Die IP 10.10.5.162 muss durch Ihre IP ersetzt werden.

Schritt 1: Persistentes n8n-Volume erstellen

Zuerst wird das benannte Volume n8n_data angelegt:

sudo docker volume create n8n_data

Dieses Volume wird später unter /home/node/.n8n in den Container eingebunden. Dort speichert n8n unter anderem seine SQLite-Datenbank, Workflows, Zugangsdaten, Benutzerkonfiguration und den automatisch erzeugten Verschlüsselungsschlüssel. Ein Container kann dadurch gelöscht und neu erstellt werden, ohne dass die n8n-Konfiguration verloren geht.

Der Befehl ist bei einer Erstinstallation erforderlich. Wird er erneut ausgeführt, verwendet Docker das bereits vorhandene Volume weiter.

Schritt 2: Internes Docker-Netzwerk anlegen

Nun wird ein separates Bridge-Netzwerk für n8n und Caddy erstellt:

sudo docker network create n8n_net

Container im gleichen benutzerdefinierten Netzwerk können sich über ihre Namen erreichen. Caddy benötigt deshalb weder die dynamische Container-IP von n8n noch einen veröffentlichten n8n-Port. Als Ziel genügt später n8n:5678.

Diese Namensauflösung gilt nur innerhalb von Docker. Sie hat nichts mit DNS-Einträgen im lokalen Netzwerk zu tun.

Schritt 3: n8n dauerhaft im Hintergrund starten

Der folgende Befehl startet n8n im Hintergrund und verbindet den Container mit Volume und Netzwerk:

sudo docker run -d --restart unless-stopped --name n8n --network n8n_net -e N8N_HOST=10.10.5.162 -e N8N_PROTOCOL=https -e N8N_EDITOR_BASE_URL=https://10.10.5.162/ -e N8N_WEBHOOK_URL=https://10.10.5.162/ -e N8N_PROXY_HOPS=1 -e TZ=Europe/Zurich -e GENERIC_TIMEZONE=Europe/Zurich -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

Die Optionen haben folgende Aufgaben:

Option	Funktion
-d	Startet den Container im Hintergrund statt in einer interaktiven Terminalsitzung.
--restart unless-stopped	Startet n8n nach Abstürzen und Serverneustarts automatisch, ausser der Administrator hat den Container bewusst gestoppt.
--name n8n	Vergibt einen eindeutigen Namen, den Caddy später als internes Ziel verwendet.
--network n8n_net	Verbindet n8n mit dem privaten Docker-Netzwerk.
N8N_PROTOCOL=https	Teilt n8n mit, dass Benutzer die Anwendung über HTTPS erreichen.
N8N_EDITOR_BASE_URL	Definiert die externe URL der Weboberfläche.
N8N_WEBHOOK_URL	Sorgt dafür, dass n8n Webhook-Adressen mit HTTPS und der richtigen IP erzeugt.
N8N_PROXY_HOPS=1	Berücksichtigt genau einen vorgeschalteten Reverse Proxy.
TZ und GENERIC_TIMEZONE	Setzen System- und Workflow-Zeitzone auf Europe/Zurich.

Bewusst fehlt -p 5678:5678. n8n bleibt dadurch vom LAN abgeschirmt und ist nur für Caddy im gemeinsamen Netzwerk erreichbar.

Schritt 4: Caddy für HTTPS per IP-Adresse konfigurieren

Zuerst wird ein dauerhaftes Konfigurationsverzeichnis erstellt:

sudo mkdir -p /opt/caddy

Anschliessend wird der Caddyfile geöffnet:

sudo nano /opt/caddy/Caddyfile

Der Inhalt lautet:

{
    default_sni 10.10.5.162
    auto_https disable_redirects
    skip_install_trust
}

10.10.5.162 {
    tls internal
    reverse_proxy n8n:5678
}

default_sni 10.10.5.162 ist für den direkten IP-Zugriff entscheidend. Bei einer TLS-Verbindung zu einer IP-Adresse übermitteln Clients häufig keinen Server Name Indication-Wert. Ohne Vorgabe kann Caddy im Docker-Netz versuchen, ein Zertifikat anhand seiner internen Container-IP auszuwählen. Das Ergebnis ist der Fehler tlsv1 alert internal error. Die Option default_sni weist Caddy an, bei leerem SNI das Zertifikat für 10.10.5.162 zu verwenden.

• auto_https disable_redirects deaktiviert die automatische Weiterleitung von Port 80, da diese Installation ausschliesslich Port 443 veröffentlicht.
• Die Zertifikatsverwaltung bleibt aktiv. skip_install_trust verhindert den erfolglosen Versuch, Caddys Stammzertifikat innerhalb des schlanken Containers in lokale Browser-Zertifikatsspeicher einzutragen.
• tls internal aktiviert Caddys interne Zertifizierungsstelle. reverse_proxy n8n:5678 leitet die entschlüsselten Anfragen an n8n weiter.

Die Optionen sind in der offiziellen Caddyfile-Referenz dokumentiert.

Schritt 5: Caddyfile validieren und Caddy starten

Vor dem eigentlichen Start wird die Konfiguration geprüft:

sudo docker run --rm -v /opt/caddy:/etc/caddy:ro caddy:2 caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile

--rm löscht den kurzlebigen Prüfcontainer nach dem Test. Der Zusatz :ro bindet das Verzeichnis nur lesbar ein. Die Meldung Valid configuration bestätigt eine gültige Konfiguration. Ein Hinweis auf einen nicht formatierten Caddyfile ist lediglich kosmetisch.

Nun wird Caddy dauerhaft gestartet:

sudo docker run -d --restart unless-stopped --name caddy --network n8n_net -p 443:443 -p 443:443/udp -v /opt/caddy:/etc/caddy:ro -v caddy_data:/data -v caddy_config:/config caddy:2 caddy run --config /etc/caddy/Caddyfile --adapter caddyfile

-p 443:443 veröffentlicht HTTPS über TCP. -p 443:443/udp stellt HTTP/3 beziehungsweise QUIC bereit. Die Volumes caddy_data und caddy_config werden beim ersten Start automatisch erzeugt. Besonders /data ist wichtig, weil dort die lokale CA, Zertifikate und Schlüssel liegen.

Schritt 6: HTTPS testen und Zertifikat unter Windows installieren

Ein Test direkt auf dem Docker-Host ignoriert zunächst das noch nicht vertrauenswürdige Zertifikat:

curl -vk https://10.10.5.162/

Wenn TLS funktioniert, zeigt curl Zertifikats- und HTTP-Informationen statt tlsv1 alert internal error. Die Weboberfläche ist nun unter https://10.10.5.162 erreichbar; Port 443 muss nicht ausdrücklich angegeben werden.

Caddys öffentliches Stammzertifikat wird aus dem Container kopiert:

sudo docker cp caddy:/data/caddy/pki/authorities/local/root.crt ./caddy-root.crt

Nur caddy-root.crt wird auf den Windows-PC übertragen. Private Schlüssel dürfen das Caddy-Volume nicht verlassen. In einer als Administrator gestarteten Windows-Eingabeaufforderung lässt sich das Zertifikat importieren:

certutil -addstore -f ROOT caddy-root.crt

Alternativ erfolgt der Import über den Zertifikatsassistenten in den Speicher „Vertrauenswürdige Stammzertifizierungsstellen“ des lokalen Computers. Anschliessend müssen alle Browserfenster vollständig geschlossen und neu geöffnet werden.

Vergleich mit alternativen n8n-HTTPS-Lösungen

Merkmal	Caddy + IP	Direktes n8n-TLS	Caddy + Domain	Nginx + IP
Direkter IP-Zugriff	Ja	Ja	Normalerweise nein	Ja
Automatische lokale Zertifikate	Ja	Manuell	Ja	Manuell
Öffentlich vertrauenswürdig	Nein, CA-Import nötig	Nein, CA-Import nötig	Ja	Nein, CA-Import nötig
Reverse-Proxy-Funktionen	Ja	Nein	Ja	Ja
Einrichtungsaufwand im LAN	Niedrig bis mittel	Mittel	Mittel	Mittel bis hoch

Caddy mit interner CA bietet für ein reines LAN eine gute Balance aus Komfort, Sicherheit und Wartbarkeit. Eine öffentliche Domain ist vorzuziehen, wenn externe Dienste n8n erreichen müssen oder Zertifikate ohne manuellen CA-Import auf beliebigen Endgeräten funktionieren sollen.

Fazit: n8n sicher über eine private IP bereitstellen

Mit Docker und Caddy lässt sich n8n ohne öffentliche Domain sicher im lokalen Netzwerk betreiben. Das persistente Volume schützt die Anwendungsdaten, das private Docker-Netzwerk hält Port 5678 vom LAN fern und Caddy stellt modernes HTTPS auf Port 443 bereit. Die Besonderheit beim Zugriff über eine reine IP-Adresse ist default_sni: Diese Option stellt sicher, dass Caddy trotz fehlendem SNI das Zertifikat für die gewünschte Server-IP auswählt.

Nach dem einmaligen Import von Caddys Stammzertifikat öffnet Windows die n8n-Weboberfläche ohne Zertifikatswarnung. Damit entsteht eine übersichtliche, wartbare und für interne Automatisierungsprojekte gut geeignete Self-Hosting-Lösung.