Wer seine eigene KI mit Ollama und Open WebUI auf einem Linux-VPS betreibt, behält seine Unterhaltungen auf dem eigenen Server und zahlt nicht mehr pro Anfrage. Der Haken: Die Ollama-API hat keinerlei Authentifizierung. Ein offener Port 11434 bedeutet kostenlose KI für jeden, der ihn findet. Diese Anleitung zeigt Ihnen eine Installation, bei der nur Nginx über HTTPS von außen erreichbar ist.
Warum eine offene Ollama-Instanz ein Problem ist
Ollama bringt eine praktische REST-API mit, aber ohne Passwort und ohne Schlüssel. Wer den Port erreicht, kann Ihre Modelle auflisten, neue herunterladen, bis die Festplatte voll ist, Modelle löschen oder Generierungen starten, die die CPU Ihres VPS dauerhaft auslasten. Die Entwickler sehen die Authentifizierung als Aufgabe eines Reverse Proxys, Sie müssen sie also selbst einrichten.
Das Risiko ist real. Im Februar 2026 zählte die Leak-Suchmaschine LeakIX mehr als 12.000 Ollama-Instanzen, die ohne Authentifizierung erreichbar waren. Im selben Jahr erlaubte eine schwerwiegende Lücke (CVE-2026-7482, Spitzname „Bleeding Llama“), den Speicher eines erreichbaren Ollama-Servers ohne Zugangsdaten auszulesen. Eine Instanz, die nur lokal lauscht, ist für solche Angriffe schlicht nicht erreichbar.
Die Architektur, die wir aufbauen
- Ollama lauscht nur auf
127.0.0.1:11434. - Open WebUI läuft in Docker und lauscht nur auf
127.0.0.1:3000. - Nginx ist der einzige öffentliche Dienst: Er nimmt HTTPS-Verkehr auf Port 443 an und leitet ihn an Open WebUI weiter.
- Die Firewall erlaubt nur SSH, HTTP (für das Zertifikat) und HTTPS.
- Open WebUI verwaltet die Konten: ein Administrator, Registrierung geschlossen.
Vorausgesetzt werden ein Linux-VPS mit Ubuntu 24.04 oder Debian 12, sudo-Zugriff, ein bereits installiertes Docker und eine Subdomain wie ki.ihre-domain.de, die auf die IP-Adresse des Servers zeigt.
Welcher VPS: RAM- und CPU-Dimensionierung ohne GPU
Auf einem VPS ohne Grafikkarte entscheiden RAM und Kernzahl. Das Modell muss vollständig in den Arbeitsspeicher passen, mit Reserve für den Gesprächskontext, Open WebUI (rechnen Sie mit etwa 1 GB) und das System. Die Größen unten entsprechen den Standardversionen (4-Bit-quantisiert) aus der Ollama-Bibliothek.
| VPS | Realistische Modelle | Beispiele (Downloadgröße) | Einsatz |
|---|---|---|---|
| 4 GB RAM, 2 vCPU | 1 bis 3 Milliarden Parameter | gemma3:1b (806 MB), qwen3:1.7b (1,4 GB), llama3.2:3b (2,0 GB) | Tests, kurze Zusammenfassungen, kleiner Assistent |
| 8 GB RAM, 3 vCPU | Bis 4B bequem, 8B möglich, aber knapp | qwen3:4b (2,5 GB), gemma3:4b (3,4 GB), qwen3:8b (5,2 GB) | Tägliche private Nutzung |
| 12 GB RAM, 4 vCPU | 8B bequem, 12-14B möglich, aber knapp | qwen3:8b (5,2 GB), gemma3:12b (8,2 GB), qwen3:14b (9,3 GB) | Texte, Code, kleines Team |
| 32 GB RAM und mehr (dedizierter Server) | 27 bis 32B | gemma3:27b (17 GB), qwen3:32b (20 GB) | Höhere Qualität, langsame Antworten ohne GPU |
Bei SoLinux entspricht das dem VPS Linux 04G (4 GB, 2 Kerne, 45 GB NVMe), dem VPS Linux 08G (8 GB, 3 Kerne, 50 GB NVMe) und dem VPS Linux 12G (12 GB, 4 Kerne, 70 GB NVMe), ohne Mindestlaufzeit, ab 7 € pro Monat für den 04G, verfügbar in Frankreich, Deutschland und New York. Für regelmäßige Nutzung ist der 08G der beste Einstieg; der 12G lohnt sich, sobald Sie ein 8B-Modell mit Reserve oder mehrere Nutzer wollen.
Bleiben Sie bei der Geschwindigkeit realistisch: Ohne GPU schreibt ein 7-8B-Modell seine Antwort Wort für Wort, mit wenigen Wörtern pro Sekunde, und die CPU läuft während der Generierung auf 100 %. Modelle mit 3-4B sind oft der beste Kompromiss. NVMe-Speicher zählt vor allem beim ersten Laden des Modells in den Arbeitsspeicher.
Schritt 1: Server und Firewall vorbereiten
Aktualisieren Sie zuerst das System und schließen Sie dann alles, was nicht unbedingt nötig ist. Mit UFW:
sudo apt update && sudo apt upgrade -y
sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
Wenn Sie lieber direkt nftables verwenden (nicht zusammen mit UFW), hier das minimale Gegenstück für die Input-Chain in /etc/nftables.conf:
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
iif "lo" accept
ip protocol icmp accept
ip6 nexthdr icmpv6 accept
tcp dport { 22, 80, 443 } accept
}
}
sudo nft -c -f /etc/nftables.conf # Syntax prüfen
sudo systemctl enable --now nftables
Klassische Falle: Ein von Docker mit -p 3000:8080 veröffentlichter Port ist auf allen Schnittstellen offen und umgeht die UFW-Regeln, weil Docker eigene Firewall-Regeln schreibt. Deshalb veröffentlicht diese Anleitung keinen einzigen Docker-Port.
Schritt 2: Ollama installieren und lokal halten
Ollama wird unter Linux mit dem offiziellen Skript installiert, das einen Benutzer ollama und einen systemd-Dienst anlegt:
curl -fsSL https://ollama.com/install.sh | sh
Prüfen Sie anschließend, ob der Dienst läuft:
ollama --version
sudo systemctl enable --now ollama
sudo systemctl status ollama
Standardmäßig lauscht Ollama auf 127.0.0.1:11434. Viele Anleitungen setzen OLLAMA_HOST auf 0.0.0.0, damit Docker es erreicht: Genau das legt die API offen. Legen Sie die lokale Adresse stattdessen ausdrücklich fest, mit einem systemd-Override, das Updates übersteht:
sudo systemctl edit ollama
Fügen Sie im vorgesehenen Bereich diese Zeilen ein:
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_NUM_PARALLEL=1"
Die letzten beiden Variablen begrenzen Ollama auf ein geladenes Modell und eine Anfrage gleichzeitig, damit der RAM eines VPS ohne GPU nicht voll läuft. Neu laden und prüfen:
sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -tlnp | grep 11434
# erwartet: 127.0.0.1:11434, niemals 0.0.0.0:11434 oder [::]:11434
curl http://127.0.0.1:11434
# erwartet: Ollama is running
Laden Sie dann ein Modell, das zu Ihrem VPS passt, und testen Sie es auf der Kommandozeile:
ollama pull qwen3:4b
ollama run qwen3:4b "Erkläre in einem Satz, was ein Reverse Proxy ist."
ollama list
Schritt 3: Open WebUI mit Docker starten, ohne öffentlichen Port
Der Schnellstart-Befehl von Open WebUI veröffentlicht Port 3000 und erreicht Ollama über host.docker.internal, was Ollama zwingt, auf allen Schnittstellen zu lauschen. Wir gehen anders vor: Der Container teilt den Netzwerk-Stack des Hosts (--network=host), erreicht Ollama über 127.0.0.1 und lauscht selbst dank der Variablen HOST und PORT nur auf 127.0.0.1:3000.
# fester geheimer Schlüssel: ohne ihn gehen Sitzungen bei jedem Neustart verloren
sudo mkdir -p /etc/open-webui
openssl rand -hex 32 | sudo tee /etc/open-webui/secret > /dev/null
sudo chmod 600 /etc/open-webui/secret
DOMAIN=ki.ihre-domain.de # Ihre Subdomain
sudo docker run -d --name open-webui \
--network=host \
-e HOST=127.0.0.1 \
-e PORT=3000 \
-e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
-e WEBUI_SECRET_KEY="$(sudo cat /etc/open-webui/secret)" \
-e CORS_ALLOW_ORIGIN="https://$DOMAIN" \
-v open-webui:/app/backend/data \
--restart always \
ghcr.io/open-webui/open-webui:main
Das Volume open-webui speichert Konten, Unterhaltungen und Einstellungen. Im Produktivbetrieb können Sie das Tag main durch eine feste Versionsnummer ersetzen und so selbst bestimmen, wann Updates kommen. Prüfen Sie nach einer Minute (der erste Start dauert etwas):
sudo ss -tlnp | grep 3000
# erwartet: 127.0.0.1:3000
curl -I http://127.0.0.1:3000
Schritt 4: Admin-Konto anlegen, bevor etwas erreichbar ist
Das erste in Open WebUI angelegte Konto wird Administrator. Überlassen Sie diesen Platz keinem Fremden, der Ihre Subdomain vor Ihnen findet: Legen Sie es vor der Nginx-Konfiguration über einen SSH-Tunnel an. Von Ihrem Computer aus:
ssh -L 3000:127.0.0.1:3000 benutzer@VPS_IP
Öffnen Sie dann http://localhost:3000 im Browser Ihres Computers und legen Sie das Admin-Konto mit einem langen, einmaligen Passwort an. Gehen Sie anschließend in den Admin-Einstellungen (Bereich Benutzer bzw. Registrierung, je nach Version) so vor:
- deaktivieren Sie neue Registrierungen;
- falls sie eine Weile offen bleiben müssen, lassen Sie die Standardrolle neuer Nutzer auf ausstehend (pending), damit Sie jedes Konto selbst freigeben;
- legen Sie die Konten Ihrer Kollegen selbst in der Benutzerverwaltung an.
Deaktivieren Sie niemals die Authentifizierung (WEBUI_AUTH=False) bei einer Instanz, die aus dem Internet erreichbar ist.
Schritt 5: Nginx mit HTTPS vor Open WebUI
Installieren Sie Nginx und Certbot:
sudo apt install -y nginx certbot python3-certbot-nginx
Fügen Sie in /etc/nginx/conf.d/limits.conf eine Begrenzung der Anmeldeversuche hinzu:
limit_req_zone $binary_remote_addr zone=owui_login:10m rate=5r/m;
Erstellen Sie dann /etc/nginx/sites-available/open-webui. Open WebUI nutzt WebSockets und streamt seine Antworten. Sie brauchen also HTTP/1.1, die Upgrade-Header und ausgeschaltetes Buffering, sonst kommen Antworten am Stück oder brechen ab.
server {
listen 80;
server_name ki.ihre-domain.de;
client_max_body_size 50M;
# Passwortversuche begrenzen
location = /api/v1/auths/signin {
limit_req zone=owui_login burst=5 nodelay;
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
proxy_cache off;
proxy_read_timeout 1800s;
proxy_send_timeout 1800s;
}
}
Aktivieren Sie die Seite, testen Sie die Konfiguration und fordern Sie das Zertifikat an. Certbot ergänzt den HTTPS-Block auf Port 443 und die Weiterleitung von HTTP selbst:
sudo ln -s /etc/nginx/sites-available/open-webui /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d ki.ihre-domain.de --redirect
sudo certbot renew --dry-run
Für ein kleines Team können Sie mit auth_basic im Block location / eine zweite Hürde einbauen oder den Zugriff mit allow und deny auf wenige IP-Adressen beschränken. Diese Schutzmaßnahmen kommen zum Open-WebUI-Konto hinzu, sie ersetzen es nicht.
Prüfen, dass nichts offenliegt
Listen Sie auf dem Server die lauschenden Ports auf: Nur 22, 80 und 443 dürfen auf einer öffentlichen Adresse erscheinen.
sudo ss -tlnp
Testen Sie von Ihrem Computer aus die IP-Adresse des VPS: Die Ports 11434 und 3000 müssen die Verbindung ablehnen oder nicht antworten. Nur Ihre Subdomain über HTTPS, im Browser geöffnet, darf die Anmeldeseite zeigen.
nc -zv -w 3 VPS_IP 11434 # muss fehlschlagen
nc -zv -w 3 VPS_IP 3000 # muss fehlschlagen
Die Installation aktuell halten
- Ollama: Führen Sie das offizielle Installationsskript erneut aus. Ihr systemd-Override bleibt erhalten; prüfen Sie trotzdem nach jedem Update mit
ss -tlnp. Die Lücke CVE-2026-7482 ist seit Version 0.17.1 behoben: Prüfen Sie Ihre Version mitollama --versionund lassen Sie keine alte Version laufen. - Open WebUI:
docker pullfür das Image, danndocker stop,docker rmund denselbendocker run-Befehl erneut. Das Volume behält Ihre Daten. - Backups: Sichern Sie regelmäßig das Volume
open-webui(Konten und Unterhaltungen); Modelle lassen sich einfach neu herunterladen. - Logs:
journalctl -u ollama,docker logs open-webuiund/var/log/nginx/, um wiederholte Anmeldeversuche zu erkennen.
Häufige Fragen
Brauche ich eine GPU, um Ollama auf einem VPS zu betreiben?
Nein. Ollama läuft allein auf der CPU. Die Antworten kommen langsamer als mit Grafikkarte, aber ein Modell mit 3 bis 8 Milliarden Parametern ist auf einem VPS mit 8 bis 12 GB RAM gut nutzbar.
Wie nutze ich die Ollama-API von einem anderen Rechner, ohne sie offenzulegen?
Über einen SSH-Tunnel: ssh -L 11434:127.0.0.1:11434 benutzer@VPS_IP, danach fragen Sie http://localhost:11434 auf Ihrem Computer ab. Für Drittanwendungen kann Open WebUI auch API-Schlüssel pro Nutzer ausstellen, hinter Ihrem Nginx mit HTTPS.
Open WebUI zeigt keine Modelle an. Was tun?
Prüfen Sie, ob ollama list Modelle liefert, ob curl http://127.0.0.1:11434 antwortet und ob der Container mit --network=host und OLLAMA_BASE_URL=http://127.0.0.1:11434 gestartet wurde. Die Verbindung lässt sich auch in den Admin-Einstellungen im Bereich Verbindungen prüfen.
Wie viele Personen können es gleichzeitig nutzen?
Ohne GPU läuft eine Generierung nach der anderen; weitere Anfragen warten. Für zwei oder drei gelegentliche Nutzer reicht ein VPS 12G mit einem 4B- oder 8B-Modell; darüber hinaus wird ein dedizierter Server mit mehr Kernen und RAM nötig.