In der heutigen Welt transformieren Automatisierung und künstliche Intelligenz Arbeitsabläufe. n8n ist eine fantastische Open-Source-Plattform für die Workflow-Automatisierung, aber die Ausführung sensibler Automatisierungen erfordert oft Self-Hosting aus Gründen der Privatsphäre und Kontrolle. Gleichzeitig bietet das lokale Ausführen von Großen Sprachmodellen (LLMs) mit Tools wie Ollama ähnliche Vorteile für KI-Aufgaben.
Was wäre, wenn wir beides kombinieren könnten? Stellen Sie sich vor, Sie lösen komplexe n8n-Workflows aus, die die Leistung eines lokal gehosteten, GPU-beschleunigten LLMs nutzen, und das alles sicher über HTTPS bereitgestellt.

Dieser Beitrag führt Sie genau durch dieses Setup: eine robuste, selbst gehostete n8n-Instanz mittels Docker, gesichert durch automatisches HTTPS über Caddy und die DNS-Challenge von Cloudflare, und integriert mit einer lokal laufenden Ollama-Instanz, die durch eine NVIDIA GPU beschleunigt wird. Wir werden auch tief in die praxisnahen Troubleshooting-Schritte eintauchen, die dabei aufgetreten sind – denn seien wir ehrlich, Setups funktionieren selten auf Anhieb perfekt!
Unser Ziel-Stack:
- n8n: Workflow-Automatisierung (via Docker)
- PostgreSQL: n8n-Datenbank (via Docker)
- Caddy: Reverse-Proxy & automatisches HTTPS (via Docker, Custom Build)
- Cloudflare: DNS-Anbieter (für Caddys TLS-Zertifikats-Challenge)
- Ollama: Lokaler LLM-Server (via Docker)
- NVIDIA GPU: Hardware-Beschleunigung für Ollama
- Docker & Docker Compose: Container-Orchestrierung

Voraussetzungen: Werkzeuge zusammenstellen
Bevor wir beginnen, stellen Sie sicher, dass Sie Folgendes haben:
- Server/Rechner: Ein Linux-Rechner (physisch oder VM), auf dem Sie die Docker-Container ausführen werden. Für einige Befehle wird Ubuntu/Debian angenommen; passen Sie diese bei Bedarf für andere Distributionen an.
- Docker & Docker Compose: Installiert und lauffähig. Beachten Sie die offizielle Docker-Dokumentation für Installationsanweisungen.
- Domainname: Ein registrierter Domainname, der Ihnen gehört (z. B. ihre-n8n-domain.de).
- Cloudflare-Konto: Ein kostenloses Cloudflare-Konto, das das DNS für Ihre Domain verwaltet.
- Cloudflare API-Token: Generieren Sie einen über Ihr Cloudflare-Dashboard -> My Profile -> API Tokens -> Create Token. Verwenden Sie die Vorlage „Edit zone DNS“. Beschränken Sie ihn nach Möglichkeit auf die spezifische Zone (Ihre Domain). Er benötigt die Berechtigungen Zone:Zone:Read und Zone:DNS:Edit für die relevante Domain. Kopieren Sie den generierten Token sicher.
- NVIDIA GPU: Eine NVIDIA-Grafikkarte, die mit CUDA kompatibel ist.
- NVIDIA-Treiber: Passende NVIDIA-Treiber, die auf dem Host-Rechner installiert sind.
- NVIDIA Container Toolkit: Dies ermöglicht Docker-Containern den Zugriff auf die NVIDIA GPU. Installieren Sie es auf Ihrem Host-Rechner mit:
sudo apt-get install -y nvidia-container-toolkit
- Grundlegende Kenntnisse der Kommandozeile: Vertrautheit mit dem Navigieren in Verzeichnissen, dem Bearbeiten von Dateien und dem Ausführen von Befehlen.

Teil 1: Die Kernkomponenten einrichten – n8n, Caddy & HTTPS
Wir beginnen damit, n8n hinter Caddy mit automatischem HTTPS zum Laufen zu bringen.
1. Verzeichnisstruktur:
Erstellen Sie ein Verzeichnis für die Konfiguration Ihres n8n-Stacks.
mkdir /docker
cd /docker
mkdir n8n-caddy
cd n8n-caddy
touch compose.yml Dockerfile Caddyfile .env
2. .env konfigurieren:
Diese Datei speichert Ihre sensiblen Informationen und Konfigurationsvariablen. Bearbeiten Sie die .env-Datei:
# --- General ---
# Zeitzone Ihres Servers (z.B. Europe/Berlin)
N8N_TIMEZONE=Europe/Berlin
# --- Domain and Ports ---
# Ihre Domain für den Zugriff auf n8n
N8N_DOMAIN=n8n.admin-cloud.de
# Der EXTERNE HTTPS-Port, über den Sie auf n8n zugreifen möchten (z.B. 443, 1234)
N8N_EXTERNAL_HTTPS_PORT=1234
# --- Database ---
# Sicheres Passwort für den n8n-Datenbankbenutzer
POSTGRES_PASSWORD=YOUR_SECURE_POSTGRES_PASSWORD
# --- Cloudflare ---
# Ihr Cloudflare API-Token (Berechtigungen Zone:Read, DNS:Edit erforderlich)
CLOUDFLARE_API_TOKEN=YOUR_CLOUDFLARE_API_TOKEN
(Wir verwenden 1234, da andere Dienste auf unserem Host bereits Port 443 belegen)
3. Caddy Dockerfile erstellen:
Wir benötigen ein benutzerdefiniertes Caddy-Image, da das Standard-Image das Cloudflare DNS-Challenge-Modul nicht enthält. Erstellen Sie ein Dockerfile in Ihrem n8n-caddy-Verzeichnis:
ARG CADDY_VERSION=2
FROM caddy:${CADDY_VERSION}-builder AS builder
RUN xcaddy build \
--with github.com/caddy-dns/cloudflare
FROM caddy:${CADDY_VERSION}
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
4. Caddyfile schreiben:
Diese Datei konfiguriert Caddy. Bearbeiten Sie das Caddyfile:
# Caddyfile
{
# Configure Let's Encrypt to use Cloudflare DNS challenge
acme_dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
# Define your n8n site
https://{$N8N_DOMAIN} {
# Enable TLS and tell it explicitly which DNS provider to use for this domain
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
# Recommended security headers
header {
# Enable Strict Transport Security (HSTS)
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
# Prevent MIME-type sniffing
X-Content-Type-Options "nosniff"
# Prevent clickjacking
X-Frame-Options "SAMEORIGIN"
# Control referrer information
Referrer-Policy "strict-origin-when-cross-origin"
# Modern Permissions Policy
Permissions-Policy "interest-cohort=()"
# Remove Caddy's server signature
-Server
}
reverse_proxy n8n:5678
}
Wichtige Änderung: Beachten Sie, dass die Site-Adresse https://{$N8N_DOMAIN} lautet. Wir geben hier nicht den externen Port an. Caddy lauscht auf dem Standard-HTTPS-Port 443 innerhalb des Containers. Docker übernimmt das Mapping unseres gewählten externen Ports (${N8N_EXTERNAL_HTTPS_PORT}) auf diesen internen Port 443.
5. docker-compose.yml für n8n-Stack erstellen:
Diese Datei definiert die Dienste Caddy, n8n und Postgres. Bearbeiten Sie compose.yml:
services:
caddy:
# Use the image we build using the Dockerfile in this directory
build: .
image: n8n-caddy-custom
container_name: n8n_caddy_proxy
restart: unless-stopped
ports:
# Expose the custom HTTPS port on the host, mapping to Caddy's internal port 443
- "${N8N_EXTERNAL_HTTPS_PORT}:443"
environment:
- CLOUDFLARE_API_TOKEN=${CLOUDFLARE_API_TOKEN}
- N8N_DOMAIN=${N8N_DOMAIN}
- N8N_EXTERNAL_HTTPS_PORT=${N8N_EXTERNAL_HTTPS_PORT}
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- caddy_data:/data
- caddy_config:/config
networks:
- n8n_internal
depends_on:
- n8n
n8n:
image: n8nio/n8n:latest
container_name: n8n_app
restart: unless-stopped
# --- NO PORTS EXPOSED - Caddy handles external access ---
environment:
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgresdb
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n_user
- DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
- TZ=${N8N_TIMEZONE}
# --- Webhook & URL Settings ---
# IMPORTANT: Use HTTPS and the custom external port Caddy is listening on!
- WEBHOOK_URL=https://${N8N_DOMAIN}:${N8N_EXTERNAL_HTTPS_PORT}/
# Tell n8n it's behind a proxy handling TLS
- N8N_SECURE_COOKIE=true
- N8N_PROXY_SSL_HEADER=X-Forwarded-Proto # Standard header Caddy uses
volumes:
- n8n_data:/home/node/.n8n
depends_on:
- postgresdb
networks:
- n8n_internal
postgresdb:
image: postgres:15 # Or your preferred version
container_name: n8n_postgres
restart: unless-stopped
environment:
- POSTGRES_DB=n8n
- POSTGRES_USER=n8n_user
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
volumes:
- postgres_data:/var/lib/postgresql/data
networks:
- n8n_internal
volumes:
n8n_data:
driver: local
postgres_data:
driver: local
caddy_data:
driver: local
caddy_config:
driver: local
networks:
n8n_internal:
driver: bridge
6. Erster Start:
Führen Sie im Verzeichnis n8n-caddy aus:
docker compose up -d
Dies baut das Caddy-Image (dauert beim ersten Mal einen Moment) und startet alle drei Container. Überprüfen Sie die Logs von Caddy, um sicherzustellen, dass es das Zertifikat erhält: docker logs -f n8n_caddy_proxy. Warten Sie einige Minuten auf die DNS-Propagation und den Zertifikatserwerb.
Versuchen Sie, https://<N8N_DOMAIN>:<N8N_EXTERNAL_HTTPS_PORT> in Ihrem Browser aufzurufen. Sie sollten den n8n-Setup-Bildschirm oder die Anmeldeseite sehen, die sicher über HTTPS bereitgestellt wird.
Teil 2: Ollama mit GPU-Beschleunigung hinzufügen
Richten wir nun Ollama in einem eigenen Docker-Compose-Stack ein und bereiten die Kommunikation vor.
1. Geteiltes Netzwerk erstellen:
Wir brauchen eine Möglichkeit für den n8n-Container (in einem Stack), mit dem Ollama-Container (in einem anderen Stack) zu kommunizieren. Ein externes Docker-Netzwerk ist hierfür perfekt. Führen Sie dies einmal auf Ihrem Docker-Host aus:
docker network create shared-services
2. Ollama docker-compose.yml erstellen:
Erstellen Sie ein separates Verzeichnis für Ollama (z. B. /docker/ollama) und erstellen Sie darin eine compose.yml-Datei:
services:
ollama:
image: ollama/ollama:latest
container_name: ollama # Simple name for standalone
ports:
- "11434:11434"
volumes:
- /docker/ollama/ollama-models:/root/.ollama
environment:
- TZ=Europe/Berlin
restart: unless-stopped
# --- GPU Acceleration Configuration ---
deploy:
resources:
reservations:
devices:
- driver: nvidia
# count: 1 # Use 1 GPU
count: all # Use all available GPUs
# device_ids: ['GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'] # Use specific GPU by ID
capabilities: [gpu]
networks:
- shared
networks:
shared:
external: true
name: shared-services
- Ersetzen: TZ=Europe/Berlin durch Ihre Zeitzone.
- GPU: Der deploy-Abschnitt weist Docker an, das NVIDIA Container Toolkit zu verwenden, um diesem Container Zugriff auf die GPU(s) zu geben.
3. n8n Stack compose.yml aktualisieren:
Bitte kehren Sie zu Ihrer Datei n8n-caddy/compose.yml
zurück und nehmen Sie zwei Ergänzungen vor:
- Fügen Sie das gemeinsame Netzwerk zur Liste der Netzwerke des n8n-Dienstes hinzu.
- Definieren Sie das gemeinsame Netzwerk am Ende der Datei und kennzeichnen Sie es als extern.
services:
# caddy: ... (no changes)
n8n:
# ... (image, container_name, restart, environment, volumes, depends_on) ...
networks:
- n8n_internal
- shared # <--------
# postgresdb: ... (no changes)
# volumes: ... (no changes)
networks:
n8n_internal:
driver: bridge
shared: # <--------
external: true # <--------
name: shared-services # <--------
4. Ollama starten und n8n aktualisieren:
- Im Ollama-Verzeichnis: docker compose up -d
- Im n8n-caddy-Verzeichnis: docker compose down && docker compose up -d (Stoppt und startet den n8n-Stack neu, um sicherzustellen, dass n8n_app korrekt mit dem shared-Netzwerk verbunden ist).
Sie können nun ein Ollama-Modell herunterladen:
docker exec -it ollama ollama pull gemma3:27b
Teil 3: Die Lücke schließen – n8n mit Ollama verbinden
Da beide Stacks laufen und mit dem shared-services-Netzwerk verbunden sind, ermöglicht Dockers internes DNS den Containern in diesem Netzwerk, sich gegenseitig über ihre Dienstnamen zu finden.
Der Ollama-Dienst heißt ollama in seiner compose.yml. Er lauscht intern auf Port 11434.
Daher können Sie innerhalb eines n8n-Workflows eine AI Agent-Node verwenden, die mit dem Ollama Chat Model verbunden ist.
Die Zugangsdaten („Credentials“) für das Ollama Chat Model sehen wie folgt aus:

Teil 4: Die Troubleshooting-Odyssee – Gelernte Lektionen
Das Einrichten vernetzter Multi-Container-Anwendungen mit benutzerdefinierten Konfigurationen führt oft zu Hindernissen. Hier ist, was wir bewältigt haben:
Problem 1: Caddy-Verbindungsfehler (SSL_ERROR_SYSCALL / Keine Logs bei Verbindung)
- Symptome: Der Zugriff auf https://<IHRE_N8N_DOMAIN>:<IHR_EXTERNER_HTTPS_PORT> schlug mit SSL-Fehlern fehl (wie SSL_ERROR_SYSCALL in curl). Die Caddy-Logs (docker logs n8n_caddy_proxy) zeigten nichts Neues bei Verbindungsversuchen. Der Host-Port lauschte jedoch (ss -tulnp | grep <EXTERNER_PORT>).
- Debugging: Wir prüften innerhalb des Caddy-Containers:
docker exec -it n8n_caddy_proxy sh
apk add --no-cache net-tools
netstat -tulnp | grep 443
Dies zeigte, dass Caddy auf der externen Portnummer (z. B. 1234) innerhalb des Containers lauschte. - Grundursache: Das ursprüngliche Caddyfile hatte https://{$N8N_DOMAIN}:{$N8N_EXTERNAL_HTTPS_PORT} als Site-Adresse. Dies wies Caddy an, intern an diese spezifische Portnummer zu binden. Der ports-Abschnitt in der docker-compose.yml leitete jedoch den externen Port auf den internen Port 443 um. Der Datenverkehr kam innerhalb des Containers auf Port 443 an, aber Caddy lauschte dort nicht.
- Lösung: Ändern Sie die Site-Adresse im Caddyfile einfach auf https://{$N8N_DOMAIN}. Dadurch lauscht Caddy auf dem standardmäßigen internen HTTPS-Port 443, passend zum Ziel der Docker-Portweiterleitung.
Problem 2: n8n kann Ollama nicht erreichen (ping: ollama: Try again)
- Symptome: Der n8n HTTP Request-Node konnte keine Verbindung zu http://ollama:11434 herstellen.
- Debugging: Wir haben eine root-Shell im n8n_app-Container erhalten (da der node-Benutzer keine Pakete installieren kann) und Netzwerk-Tools installiert:
docker exec -u root -it n8n_app sh
ping -c 3 ollama # <-- This failed with "Try again"
Anschließend haben wir das shared-services-Netzwerk auf dem Docker-Host überprüft:docker network inspect shared-services
- Grundursache: Der inspect-Befehl zeigte „Containers“: {}. Weder der n8n_app- noch der ollama-Container waren tatsächlich mit dem geteilten Netzwerk verbunden, obwohl dies in den Compose-Dateien definiert war. Dies bedeutete, dass das interne DNS von Docker den Hostnamen ollama für den n8n_app-Container nicht auflösen konnte.
- Lösung: Beide Stacks stoppen (docker compose down in jedem Verzeichnis), sicherstellen, dass das Netzwerk existiert (docker network create shared-services), die Stacks neu starten (docker compose up -d) und die Anbindung erneut mit docker network inspect shared-services überprüfen. Diesmal erschienen beide Container in der Containers-Liste, und der anschließende ping ollama aus dem n8n_app-Container war erfolgreich.
Fazit: Steigern Sie Ihre Automatisierung
Durch Befolgen dieser Anleitung haben Sie erfolgreich eine leistungsstarke, private und sichere Plattform aufgebaut, die die Automatisierungsfähigkeiten von n8n mit der lokalen KI-Stärke einer GPU-beschleunigten Ollama-Instanz kombiniert. Die Einrichtung und Verwaltung solcher integrierter Systeme, oft in containerisierten Umgebungen wie Docker, erfordert sorgfältige Planung und Ausführung.
Wenn Sie Hilfe bei der Administration Ihrer selbst gehosteten Automatisierungs-, KI- oder allgemeinen Docker-Infrastruktur benötigen, stehen wir Ihnen gerne zur Verfügung. Unsere Experten können Ihre individuellen Anforderungen besprechen und eine maßgeschneiderte Lösung für Sie entwickeln – genau wie wir Kunden bei der Verwaltung komplexer Virtualisierungsumgebungen wie Proxmox unterstützen. Kontaktieren Sie uns noch heute für eine unverbindliche Beratung, um mehr zu erfahren. Unsere Kontaktdaten finden Sie hier.
Weitere spannende Themen und Blogbeiträge zu Automatisierung, KI, Self-Hosting und Infrastrukturmanagement finden Sie hier.