Kompletter Self-Hosted-AI-Stack auf Ubuntu 24.04 VPS: Docker + Portainer + Ollama + Open WebUI + n8n – bebilderte Anleitung

Dieser Pillar-Ratgeber fasst den kompletten Stack zusammen, den wir auf einem realen Ubuntu-VPS aufgebaut haben: Ubuntu 24.04 LTS, Docker Engine + Compose, Portainer, Ollama, qwen3:4b, Open WebUI, n8n, Nginx und Let’s Encrypt. Die Anwendungen laufen in getrennten Docker-Containern und kommunizieren über das private Bridge-Netz eka-ai.

Öffentlich erreichbar sind nur die Nginx-Ports 80 und 443. Portainer 9443, Ollama 11434, Open WebUI 3000 und n8n 5678 werden am Host auf 127.0.0.1 gebunden. Verwaltung und KI-Dienste sind damit nicht direkt aus dem Internet erreichbar; Domains werden über Reverse Proxy und TLS bereitgestellt.

Internet :443
  ↓
Nginx + Let's Encrypt
  ├─ portainer.ekasunucu.com → 127.0.0.1:9443
  ├─ openwebui.ekasunucu.com → 127.0.0.1:3000
  └─ n8n.ekasunucu.com → 127.0.0.1:5678

Docker eka-ai
  ├─ Portainer
  ├─ Ollama → qwen3:4b
  ├─ Open WebUI → ollama:11434
  └─ n8n AI Agent → ollama:11434

Der reale Test-VPS verfügte über 8 vCPU, rund 31 GiB RAM und ein 99-GB-Root-Dateisystem. Als CPU wurde ein AMD Ryzen 9 7950X angezeigt. Da kein dediziertes NVIDIA- oder ROCm-GPU-Passthrough vorhanden war, lief Ollama im CPU-Modus. qwen3:4b funktionierte in dieser Umgebung, allerdings langsamer als auf einem geeigneten GPU-System.

Mit größeren Modellen steigen RAM-, Speicher- und gegebenenfalls VRAM-Anforderungen. Open WebUI kann beim ersten Start zusätzlich Embedding- und Cache-Dateien laden. Planen Sie daher auch Platz für Docker-Images, Volumes, Execution-Daten und Caches ein.

lscpu | grep -E 'Model name|CPU\(s\)'
free -h
df -h /
nvidia-smi || true
ls -la /dev/dri 2>/dev/null || true

Wenn der VPS noch Ubuntu 22.04 verwendet, aktualisieren Sie zuerst alle Pakete und erstellen Sie Backup oder Snapshot. Für Ubuntu Server ist do-release-upgrade das Werkzeug für den Versionssprung. Unser realer Ablauf zeigte Recovery-SSH auf Port 1022, Paketplan, openssh-server-Konfigurationsabfrage, Entfernung veralteter Pakete und den abschließenden Neustart.

Nach dem Reboot prüfen Sie /etc/os-release, Kernel, APT-Status und fehlgeschlagene systemd-Units. Unser finales System lief mit Ubuntu 24.04.4 LTS, Noble und Kernel 6.8.0-137-generic.

apt update
apt full-upgrade -y
reboot

do-release-upgrade

cat /etc/os-release
uname -r
apt update
systemctl --failed

Das offizielle Docker-Repository liefert eine berechenbare Engine- und Compose-Plugin-Installation. Im realen Test liefen Docker Engine 29.7.2 und Docker Compose v5.4.0; dies sind dokumentierte Testversionen und keine Aussage über die jeweils neueste Version.

Unser erstes Automationsskript endete mit Exit-Code 141, weil set -o pipefail mit apt-cache policy | head einen SIGPIPE auslöste. Docker selbst war nicht defekt. Nach dem Wechsel auf sed lief die Installation weiter; anschließend bestätigte hello-world die Funktionsfähigkeit.

docker --version
docker compose version
systemctl is-active docker

docker run --rm hello-world

Für Portainer wurde das Named Volume portainer_data erstellt und der Docker-Socket eingebunden. Die Verwaltungsoberfläche nutzt im Container HTTPS auf Port 9443. Beim ersten Setup trat der Sicherheits-Timeout/Setup-Token-Ablauf auf; nach Neustart wurde das Admin-Konto fertig eingerichtet.

Im finalen Aufbau bindet der Host Port 9443 nur an 127.0.0.1. Externer Zugriff erfolgt ausschließlich über portainer.ekasunucu.com hinter Nginx und HTTPS.

docker volume create portainer_data

docker run -d --name portainer --restart=always -p 127.0.0.1:9443:9443 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:lts

docker ps --filter name='^/portainer$'

Bevor der Reverse Proxy bereit war, lieferte die Portainer-Domain Cloudflare 521. Nach Erstellung des Nginx-Serverblocks und Weiterleitung auf 127.0.0.1:9443 funktionierte der Origin. Bei Certbot kam es zunächst zu einem Timeout beim Download von core24; ein späterer Versuch war erfolgreich.

Das gleiche Muster wurde für Open WebUI und n8n verwendet. Für WebSocket-Anwendungen müssen Upgrade- und Connection-Header erhalten bleiben. Danach testen Sie die automatische Zertifikatserneuerung mit certbot renew --dry-run.

nginx -t
systemctl reload nginx

certbot --nginx -d portainer.ekasunucu.com

certbot renew --dry-run

Container erreichen einen anderen Container nicht über ihr eigenes localhost. Deshalb wurde das user-defined Bridge-Netz eka-ai erstellt. Da der Ollama-Container ollama heißt, erreichen Open WebUI und n8n ihn per Docker-DNS unter http://ollama:11434.

Named Volumes ollama_data, openwebui_data und n8n_data halten Daten unabhängig vom Container-Lebenszyklus. Vor Image-Updates oder Neuaufbau der Container sollten diese Volumes gesichert werden.

docker network create eka-ai 2>/dev/null || true

docker volume create ollama_data
docker volume create openwebui_data
docker volume create n8n_data

docker network inspect eka-ai

Das offizielle Ollama-Image wurde mit dem Volume ollama_data für /root/.ollama gestartet. Ohne GPU-Passthrough wählte Ollama den CPU-Backend. Im Container lauscht der Dienst zwar auf 11434, am Host wird er jedoch nur über 127.0.0.1:11434:11434 bereitgestellt.

Der erste /api/tags-Test antwortete mit HTTP 200 und leerer Modellliste. Damit lässt sich die Runtime-Verfügbarkeit von späteren Modell-Download-Problemen trennen.

docker pull ollama/ollama:latest

docker run -d --name ollama --restart=always --network eka-ai -p 127.0.0.1:11434:11434 -v ollama_data:/root/.ollama ollama/ollama:latest

curl -sS http://127.0.0.1:11434/api/tags

Im realen Aufbau wurde qwen3:4b mit ungefähr 2,5 GB geladen. Die Ollama-Metadaten zeigten die 4.0B-Klasse, Q4_K_M-Quantisierung sowie Tools/Thinking-Fähigkeiten. Im CPU-Test belegte das geladene Modell ungefähr 3 GiB RAM.

Nur ollama list reicht nicht. Wir sendeten einen echten /api/chat-Request und erhielten EKA-OLLAMA-TEST-BASARILI. Dadurch konnten spätere Open-WebUI- und n8n-Probleme klar von der Modell-Runtime getrennt werden.

docker exec ollama ollama pull qwen3:4b

docker exec ollama ollama list

curl -sS http://127.0.0.1:11434/api/chat -H 'Content-Type: application/json' -d '{"model":"qwen3:4b","messages":[{"role":"user","content":"Nur EKA-OLLAMA-TEST-BASARILI schreiben"}],"stream":false}'

Die lokale Ollama-API ist allein keine vollständige Authentifizierungsschicht für öffentliche Benutzer. Deshalb lauscht Port 11434 am Host nur auf 127.0.0.1. Open WebUI und n8n erreichen Ollama privat über Docker-DNS im eka-ai-Netz.

Für externen Zugriff sollten Authentifizierung, TLS, Reverse Proxy, VPN oder ein privates Netz vorgeschaltet werden. Prüfen Sie die Bindung mit ss.

ss -lntp | grep 11434

docker network inspect eka-ai --format '{{range .Containers}}{{.Name}} {{.IPv4Address}}{{println}}{{end}}'

Open WebUI startete mit persistentem openwebui_data, festem WEBUI_SECRET_KEY und dem eka-ai-Netz. Der Host-Port wurde auf 127.0.0.1:3000 beschränkt, die Ollama-Verbindung auf http://ollama:11434 gesetzt.

/health lieferte anfangs nicht sofort 200. Der Container führte Datenbankmigrationen aus und lud sentence-transformers/all-MiniLM-L6-v2-Dateien von Hugging Face. Nach der Initialisierung wurde der Container healthy. Ein kurzer Health-Timeout beim ersten Start bedeutet daher nicht automatisch einen Fehler.

docker run -d --name open-webui --restart=always --network eka-ai -p 127.0.0.1:3000:8080 -e OLLAMA_BASE_URL=http://ollama:11434 -v openwebui_data:/app/backend/data ghcr.io/open-webui/open-webui:main

curl -sS http://127.0.0.1:3000/health

Nach erfolgreichem Healthcheck leitete Nginx openwebui.ekasunucu.com auf localhost:3000 weiter und übernahm die WebSocket-Header. Let’s Encrypt stellte das Zertifikat erfolgreich bereit; Origin- und Domain-HTTPS antworteten mit 200.

Das erste Open-WebUI-Konto erhielt Administratorrechte. qwen3:4b erschien im Modellwähler und bestätigte damit die Ollama-Verbindung auch in der Oberfläche.

nginx -t
systemctl reload nginx

certbot --nginx -d openwebui.ekasunucu.com

curl -I https://openwebui.ekasunucu.com

Für n8n wurden n8n_data und ein stabiler N8N_ENCRYPTION_KEY verwendet. Der Container trat dem eka-ai-Netz bei und veröffentlichte Port 5678 am Host nur auf 127.0.0.1. Host-, Protokoll-, Editor-URL-, Proxy/Webhook- und Zeitzonenwerte lagen in einer Environment-Datei.

Im Test lief n8n 2.33.7 und /healthz antwortete mit status ok. Startup-Logs enthielten Hinweise zum Python Task Runner und zukünftigen Konfigurationsänderungen, blockierten aber den verwendeten AI-Agent-Workflow nicht.

docker volume create n8n_data

openssl rand -hex 32

docker run -d --name n8n --restart=always --network eka-ai --env-file /root/n8n.env -p 127.0.0.1:5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n:latest

curl -sS http://127.0.0.1:5678/healthz

n8n Port 5678 wurde nicht direkt öffentlich freigegeben. Nginx leitete n8n.ekasunucu.com auf localhost:5678 weiter und setzte Forwarded- sowie WebSocket-Header. Nach Let’s Encrypt lieferte die Domain HTTPS 200.

Mit ss prüfen Sie, dass 5678, 11434, 3000 und 9443 weiterhin nur Loopback verwenden und Nginx die öffentlichen Ports 80/443 besitzt.

certbot --nginx -d n8n.ekasunucu.com

ss -lntp | grep -E ':80 |:443 |:9443 |:11434 |:3000 |:5678 '

Da n8n und Ollama getrennte Container sind, zeigt localhost:11434 innerhalb von n8n zurück auf den n8n-Container. Beide Container befinden sich im eka-ai-Netz; daher verwendeten wir http://ollama:11434. Ein /api/tags-Aufruf aus n8n lieferte HTTP 200 und qwen3:4b.

Im ersten importierten Workflow fehlte die Ollama-Credential-Referenz, wodurch der Sub-Node Ollama Qwen3 4B fehlschlug. Nach Anlegen der Credentials mit der richtigen Docker-DNS-Adresse funktionierte der Workflow.

docker exec n8n node -e "fetch('http://ollama:11434/api/tags').then(r=>r.text()).then(console.log)"

Der Hauptfluss führt vom Chat Trigger zum AI Agent. Am Chat-Model-Eingang hängt Ollama qwen3:4b, am Memory-Eingang Simple Memory. Die System Message nennt qwen3:4b explizit als reales Modell, damit kein erfundener Runtime- oder Modellname ausgegeben wird.

Im finalen Lauf wurden Chat Trigger, AI Agent, Ollama Chat Model und Memory erfolgreich abgeschlossen. Der Agent nannte Ollama und qwen3:4b korrekt.

Prompt: {{ $json.chatInput }}

Ollama Base URL: http://ollama:11434
Model: qwen3:4b

Calculator wurde mit dem Tool-Eingang des AI Agent verbunden. Bei 3478 × 129 rief der Agent das Tool auf und gab deterministisch 448662 zurück.

Der erste HTTP-Test nutzte den älteren Node-Typ @n8n/n8n-nodes-langchain.toolHttpRequest und scheiterte mit “supplyData method but no execute method”. Nach Wechsel auf das aktuelle n8n HTTP Request Tool wurde eine reale JSONPlaceholder-Antwort geladen und vom Agenten erfolgreich zusammengefasst.

3478 × 129 kaç eder? Hesap makinesini kullan.

OrnekAPIVeriGetir aracını kullan ve gelen API verisini Türkçe açıkla.

Eine vollständige Prüfung umfasst Docker-Status, lokale Health-Endpunkte, öffentliche Domains, Loopback-Portbindungen, Named Volumes, fehlgeschlagene systemd-Units und Certbot-Renewal. Starten Sie den VPS neu und bestätigen Sie, dass restart policies die Container wieder hochfahren.

Sichern Sie portainer_data, ollama_data, openwebui_data und n8n_data sowie Nginx-Site-Dateien, Let’s-Encrypt-Daten und den n8n Encryption Key. Modellfiles können erneut geladen werden; n8n-Credentials/Workflows und Open-WebUI-Benutzerdaten sind meist kritischer.

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

curl -fsS http://127.0.0.1:11434/api/tags >/dev/null && echo OLLAMA_OK
curl -fsS http://127.0.0.1:3000/health >/dev/null && echo WEBUI_OK
curl -fsS http://127.0.0.1:5678/healthz >/dev/null && echo N8N_OK

certbot renew --dry-run

systemctl --failed

Die Infrastruktur ist nun vollständig: Portainer verwaltet Container, Ollama liefert das lokale LLM, Open WebUI die Browser-Oberfläche und n8n Automatisierung sowie Agent-Orchestrierung. Der nächste logische Schritt ist eine Vector Database wie Qdrant zusammen mit einem Embedding-Modell.

Der RAG-Aufbau trennt Dokumentimport, Chunking, Embeddings, Vector Store, Retrieval und Quellenbezug. qwen3:4b kann dadurch mit Ihrer aktuellen privaten Wissensbasis arbeiten statt nur mit allgemeinem Modellwissen.

Docker / eka-ai
  ├─ Ollama → qwen3:4b
  ├─ Open WebUI
  ├─ n8n AI Agent
  └─ Qdrant + Embeddings + RAG  ← nächster Ratgeber