Open WebUI als Oberfläche für Ollama einrichten

Ollama stellt Sprachmodelle lokal über eine HTTP-API auf Port 11434 bereit, bringt aber keine Chat-Oberfläche mit. Open WebUI schließt diese Lücke mit Benutzerverwaltung, persistentem Chat-Verlauf und Modellauswahl im Browser. Diese Anleitung richtet beide Komponenten auf einem Linux-Host ein, inklusive Reverse Proxy, TLS und Verifikation.

Was ist Open WebUI?

Open WebUI ist eine selbst gehostete Weboberfläche für LLM-Backends, die über die Ollama-API auf Port 11434 oder eine OpenAI-kompatible API spricht und Chat-Verlauf, Benutzerkonten sowie Modellverwaltung im Browser bereitstellt.

Der Funktionsumfang geht über ein reines Chat-Fenster hinaus: Rollen und Gruppen, Modell-Presets mit eigenen Systemprompts, Dokument-Upload mit RAG-Pipeline und ein Admin-Bereich, in dem du Modelle direkt aus der Registry ziehen kannst. Wichtig für die Planung: Open WebUI rechnet nichts selbst. Die gesamte Inferenz läuft im Ollama-Daemon.

Voraussetzungen

• Linux-Host mit Ubuntu 24.04 LTS oder Debian 12, mindestens 4 vCPU und 8 GB RAM für Modelle der 7B-Klasse in 4-Bit-Quantisierung
• Docker Engine 24.0 oder neuer inklusive docker compose-Plugin
• Ein Benutzer mit sudo-Rechten
• Eine DNS-A-Record auf den Host, falls du TLS einrichtest
• Freier Speicher: rechne mit 5 GB pro Modell, 40 GB Datenträger sind ein realistischer Startwert

Für Tests mit kleinen Modellen genügt eine CPU-Instanz. Eine skalierbare Cloud-VPS mit dedizierter CPU trägt Modelle bis etwa 8B in akzeptabler Geschwindigkeit, alles darüber gehört auf eine GPU.

Wie spielen Open WebUI und Ollama zusammen?

Open WebUI enthält selbst kein Sprachmodell, sondern ruft ausschließlich die HTTP-API des Ollama-Daemons auf Port 11434 auf und speichert Benutzer, Chats und Einstellungen in einer eigenen SQLite-Datenbank unter /app/backend/data.

graph LR
    A["Browser"] --> B["nginx :443 mit TLS"]
    B --> C["Open WebUI Container :8080"]
    C -->|"HTTP /api/chat"| D["Ollama Daemon :11434"]
    D --> E["GPU oder CPU"]
    C --> F["Volume /app/backend/data"]
    D --> G["Modell-Cache auf dem Host"]

Aus dieser Aufteilung folgen zwei Konsequenzen. Erstens: Ein Neustart des Containers verliert keine Modelle, weil die Gewichte beim Host-Daemon liegen. Zweitens: Der Port 11434 darf nie ungeschützt im Internet stehen, denn die Ollama-API kennt keine Authentifizierung.

Ollama installieren und für Container erreichbar machen

Installiere den Daemon über das offizielle Skript. Es legt den systemd-Service ollama an und startet ihn direkt:

$ curl -fsSL https://ollama.com/install.sh | sh
$ ollama --version
ollama version is 0.5.7

Standardmäßig lauscht Ollama nur auf 127.0.0.1:11434. Ein Container im Docker-Bridge-Netz erreicht diese Adresse nicht. Binde den Daemon deshalb an das Gateway der Bridge, nicht an 0.0.0.0:

$ sudo mkdir -p /etc/systemd/system/ollama.service.d
$ sudo tee /etc/systemd/system/ollama.service.d/override.conf > /dev/null <<'EOF'
[Service]
Environment="OLLAMA_HOST=172.17.0.1:11434"
EOF
$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama

172.17.0.1 ist die Standardadresse der Bridge docker0. Prüfe sie mit ip -4 addr show docker0, falls dein Host ein abweichendes Subnetz nutzt. Der Vorteil gegenüber 0.0.0.0: Die API ist über das öffentliche Interface nicht erreichbar, selbst wenn die Firewall einmal falsch konfiguriert ist.

Lade anschließend ein Modell, damit die Oberfläche später nicht leer bleibt:

$ ollama pull llama3.2:3b
$ ollama list
NAME             ID              SIZE      MODIFIED
llama3.2:3b      a80c4f17acd5    2.0 GB    12 seconds ago

Open WebUI im Container starten

Lege ein Compose-Projekt unter /opt/open-webui/docker-compose.yml an. Die Variante mit Compose ist der Einzelbefehl-Variante vorzuziehen, weil Umgebungsvariablen und Volume dokumentiert bleiben:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://host.docker.internal:11434
      - WEBUI_SECRET_KEY=<langes-zufaelliges-secret>
      - WEBUI_URL=https://<deine-domain>
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - open-webui-data:/app/backend/data
volumes:
  open-webui-data:

Drei Details entscheiden über einen stabilen Betrieb:

• ports: 127.0.0.1:3000:8080 veröffentlicht die Oberfläche nur lokal. Ohne das Präfix 127.0.0.1 umgeht Docker deine ufw-Regeln und stellt Port 3000 öffentlich bereit.
• WEBUI_SECRET_KEY signiert die JWT-Sitzungstokens. Fehlt der Wert, generiert der Container ihn neu und alle Benutzer werden bei jedem Neustart ausgeloggt. Erzeuge ihn mit openssl rand -hex 32.
• extra_hosts macht den Namen host.docker.internal unter Linux nutzbar. Ohne diesen Eintrag scheitert die Namensauflösung im Container.

Für produktive Installationen ersetze das Tag main durch ein Release-Tag wie v0.6.5, damit ein docker compose pull nicht unbemerkt ein Major-Update einspielt.

Starte den Stack:

$ cd /opt/open-webui
$ sudo docker compose up -d
$ sudo docker compose ps

Der erste registrierte Benutzer erhält automatisch die Rolle admin. Registriere dich deshalb sofort nach dem Start und setze anschließend unter Admin Panel → Settings → General die Option für neue Registrierungen auf pending, damit sich niemand ungeprüft ein Konto anlegt.

Warum erreicht der Container Ollama nicht auf 127.0.0.1?

Im Container zeigt 127.0.0.1 auf den Netzwerk-Namespace des Containers selbst und nicht auf den Host, deshalb muss OLLAMA_BASE_URL auf http://host.docker.internal:11434 oder direkt auf die Bridge-IP 172.17.0.1 zeigen.

Es gibt eine Alternative: Startest du den Container mit network_mode: host, teilt er den Netzwerk-Stack des Hosts und http://127.0.0.1:11434 funktioniert. Dafür verlierst du die Port-Isolation und die Oberfläche lauscht direkt auf Port 8080. Für einen Host mit Reverse Proxy ist die Bridge-Variante die sauberere Wahl.

GPU-Beschleunigung prüfen

Ollama nutzt eine NVIDIA-GPU direkt über den Host-Treiber, sobald nvidia-smi das Gerät meldet. Ein Container-Toolkit brauchst du dafür nicht, weil der Daemon nativ auf dem Host läuft.

$ nvidia-smi --query-gpu=name,memory.total --format=csv
name, memory.total [MiB]
NVIDIA L40S, 46068 MiB
$ journalctl -u ollama | grep -i "inference compute"

Ob ein Modell tatsächlich in der GPU liegt, zeigt ollama ps während einer laufenden Anfrage in der Spalte PROCESSOR:

$ ollama ps
NAME             ID              SIZE      PROCESSOR    UNTIL
qwen2.5:7b       845dbda0ea48    5.6 GB    100% GPU     4 minutes from now

Steht dort 100% CPU oder eine Mischung wie 62%/38% CPU/GPU, passt das Modell nicht vollständig in den VRAM. Wähle dann eine stärkere Quantisierung oder ein kleineres Modell. Für Modelle ab etwa 30B Parametern und für mehrere parallele Sessions sind GPU-Instanzen für LLM-Inference die praktikable Grundlage, weil dort der VRAM statt der CPU-Kerne das Limit setzt.

Zugriff mit nginx und TLS absichern

Open WebUI überträgt Anmeldedaten und Chat-Inhalte im Klartext, solange kein TLS davor liegt. Richte nginx als Reverse Proxy ein und hole ein Zertifikat mit Certbot:

$ sudo apt install nginx certbot python3-certbot-nginx
$ sudo certbot certonly --nginx -d <deine-domain>

Die Konfiguration unter /etc/nginx/sites-available/open-webui.conf:

server {
    listen 443 ssl;
    http2 on;
    server_name <deine-domain>;
    ssl_certificate     /etc/letsencrypt/live/<deine-domain>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<deine-domain>/privkey.pem;
    client_max_body_size 100M;
    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-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 600s;
        proxy_buffering off;
    }
}

Die Direktive http2 on; setzt nginx 1.25.1 oder neuer voraus. Auf älteren Versionen schreibst du stattdessen listen 443 ssl http2;. Drei Werte sind nicht optional: Die Upgrade-Header halten die WebSocket-Verbindung für Streaming-Antworten offen, proxy_read_timeout 600s verhindert Abbrüche bei langen Generierungen, und client_max_body_size 100M erlaubt Dokument-Uploads für RAG.

$ sudo ln -s /etc/nginx/sites-available/open-webui.conf /etc/nginx/sites-enabled/
$ sudo nginx -t && sudo systemctl reload nginx

Verifikation

Prüfe die Kette von unten nach oben. Zuerst der Daemon, dann der Container, dann der Proxy.

$ ss -tlnp | grep 11434
LISTEN 0  4096  172.17.0.1:11434  0.0.0.0:*  users:(("ollama",pid=1042,fd=3))

Die Adresse muss 172.17.0.1 lauten, nicht 127.0.0.1. Anschließend aus dem Container heraus:

$ sudo docker exec open-webui python -c "import urllib.request; print(urllib.request.urlopen('http://host.docker.internal:11434/api/version').read())"
b'{"version":"0.5.7"}'

Zum Schluss der Proxy von außen:

$ curl -I https://<deine-domain>/health
HTTP/2 200

Melde dich danach im Browser an. Erscheint llama3.2:3b in der Modellauswahl oben links und liefert ein Testprompt Token für Token eine Antwort, steht die Kette vollständig.

Troubleshooting

Die Modellauswahl bleibt leer. Open WebUI erreicht die Ollama-API nicht. Prüfe die Bind-Adresse mit ss -tlnp | grep 11434 und den Wert von OLLAMA_BASE_URL mit sudo docker exec open-webui env | grep OLLAMA. Nach einer Änderung an der Compose-Datei ist docker compose up -d nötig, ein restart übernimmt neue Umgebungsvariablen nicht.

Die Antwort bricht nach wenigen Sekunden ab oder die Seite lädt endlos. Dem Reverse Proxy fehlen die Header Upgrade und Connection. Ohne sie schlägt der WebSocket-Handshake fehl und der Client fällt auf Polling zurück. Kontrolliere die location-Block-Direktiven und lade nginx neu.

Nach einem Container-Neustart sind alle Konten verschwunden. Das Volume auf /app/backend/data fehlt oder wurde bei einem docker compose down -v entfernt. Sichere die Datenbank regelmäßig mit sudo docker cp open-webui:/app/backend/data/webui.db ./webui-$(date +%F).db.

Ein ollama pull bricht mit „no space left on device“ ab. Die Gewichte liegen unter /usr/share/ollama/.ollama/models. Verlagere das Verzeichnis über die Variable OLLAMA_MODELS im systemd-Override auf einen größeren Datenträger und starte den Service neu.

Fazit

Open WebUI und Ollama sind zwei klar getrennte Dienste: Der Daemon hält die Modelle auf dem Host, der Container hält Benutzer und Chats. Halte diese Trennung im Kopf, wenn du Backups planst oder Updates einspielst. Die drei Punkte, an denen Installationen typischerweise scheitern, sind die Bind-Adresse von Ollama, ein fehlender WEBUI_SECRET_KEY und die WebSocket-Header im Reverse Proxy. Sind sie gesetzt, läuft der Stack ohne weitere Pflege außer regelmäßigen Image-Updates.

Weiterlesen

• Lokales Coding-Modell mit Ollama in der IDE nutzen
• Die Ollama-API aus eigenen Anwendungen ansprechen
• Ollama auf Ubuntu 24.04 installieren und als Dienst betreiben
• Ollama im Docker-Container betreiben
• Ollama im Netzwerk freigeben: Port, Bind-Adresse und Absicherung
• Ollama, LM Studio oder llama.cpp: Welches Werkzeug wofür?
• Ollama mit MCP-Servern verbinden: Werkzeuge für lokale Modelle
• Ollama-Modelle verwalten: aktualisieren, aufräumen, Speicher sparen
• Was ist Ollama? Funktionsweise, Modelle und Einsatzgebiete