Open WebUI einrichten: KI-Plattform in 12 Schritten [2026]

Wer lokale KI-Modelle betreibt, kommt an einem Terminal-Fenster mit Ollama-Befehlen irgendwann nicht mehr weiter. Genau hier setzt Open WebUI an: eine selbst gehostete Oberfläche, die aus einer Kommandozeilen-Übung eine Plattform macht, die aussieht und sich anfühlt wie ChatGPT, aber komplett auf eigener Hardware läuft. Mit Version 0.11.1 hat das Projekt Ende Juli 2026 einen Funktionsschub bekommen, der es endgültig zu einer Alternative für Firmen und Privatanwender macht, die ihre Daten nicht in fremde Rechenzentren schicken wollen.

In dieser Anleitung richten wir Open WebUI von Grund auf ein, verbinden es mit Ollama und optional mit einem vLLM-Backend, und zeigen, wie aktuelle Modelle wie Kimi K3 oder Mistral Nemo lokal laufen. Am Ende steht ein komplettes, funktionierendes Setup mit Nutzerverwaltung, Dateizugriff und den neuen Sicherheits-Features aus den jüngsten Releases.

Die Anleitung richtet sich an alle, die bereits mit Ollama, LM Studio oder einer Cloud-API experimentiert haben und jetzt den nächsten Schritt gehen wollen: eine Oberfläche, die mehrere Nutzer, mehrere Modelle und mehrere Backends gleichzeitig verwaltet. Zwölf konkrete Schritte führen von der leeren Docker-Installation bis zu einem produktiv nutzbaren System mit Reverse Proxy, Backup-Routine und Guardrails gegen Prompt Injection. Wer die Schritte der Reihe nach abarbeitet, hat die komplette Umgebung in rund 60 bis 90 Minuten fertig eingerichtet, je nachdem wie groß das gewählte Modell ausfällt und wie schnell die eigene Internetverbindung beim Modell-Download ist.

Was ist Open WebUI und warum lohnt sich der Aufwand

Open WebUI ist eine quelloffene Weboberfläche für den Betrieb lokaler und cloudbasierter Sprachmodelle. Das Projekt beschreibt sich selbst als “Self-Hosted AI Platform” und hat sich seit dem Fork von Ollama WebUI zu einem eigenständigen Ökosystem entwickelt, das inzwischen weit über einen simplen Chat-Client hinausgeht. Laut den offiziellen Release-Notizen auf openwebui.com bringt die aktuelle Version 0.11.1 unter anderem Tool-Call-Freigaben, einen eingebauten Terminal-Dateibrowser mit Dokumentvorschau, das neue /model-Slash-Command, eine überarbeitete Chat-Suche und Delta-Streaming zur Reduktion des Antwort-Traffics.

Der Punkt, der Open WebUI von einer reinen Bastellösung unterscheidet, ist die Release-Kadenz. Zwischen Ende Juni und Ende Juli 2026 erschienen laut GitHub-Release-Historie mehrere Versionen in kurzer Folge: 0.10.0, 0.10.1, 0.10.2 und schließlich 0.11.0 am 27. Juli 2026. Diese Geschwindigkeit zeigt, dass hinter dem Projekt eine aktive Community steht, die auf neue Modelle wie Kimi K3 oder Mistral Nemo reagiert, statt monatelang stillzustehen.

Für DACH-Nutzer kommt ein weiterer Vorteil dazu: Wer das Modell selbst hostet, verarbeitet keine Chatverläufe auf Servern in den USA. Bei Anwendungen mit Personenbezug, etwa in der Rechtsberatung oder im Gesundheitswesen, ist das oft der entscheidende Faktor gegenüber gehosteten Diensten wie ChatGPT oder Claude.

Technisch betrachtet ist Open WebUI ein Python-Backend auf FastAPI-Basis mit einem Svelte-Frontend, das komplett im Browser läuft. Diese Kombination erklärt, warum sich die Oberfläche auch auf schwacher Hardware flüssig bedienen lässt: Die eigentliche Rechenlast trägt das angebundene Modell-Backend, nicht die Weboberfläche selbst. Open WebUI fungiert im Grunde als Vermittler zwischen Nutzer und Modell, der zusätzlich Chatverlauf, Rechteverwaltung und Werkzeug-Integrationen übernimmt. Das macht den Einstieg deutlich niedrigschwelliger als bei Lösungen, die Frontend und Inferenz-Engine in einem einzigen, schwer zu wartenden Prozess bündeln.

Ein weiterer Grund für die wachsende Verbreitung: Open WebUI läuft plattformunabhängig, weil es als Docker-Image ausgeliefert wird. Ob Raspberry Pi im Homelab, ein gemieteter V-Server oder eine GPU-Workstation im Büro, solange Docker läuft, funktioniert die Installation nach demselben Muster. Genau diese Portabilität macht das Projekt zu einer realistischen Alternative für Selbstständige und kleine Teams, die keine dedizierte IT-Abteilung für den Betrieb einer KI-Plattform abstellen können.

Voraussetzungen: Diese Versionen brauchst du

Bevor es losgeht, die konkrete Ausstattung, mit der diese Anleitung getestet wurde. Die Mindestanforderungen hängen stark davon ab, welches Modell du am Ende laufen lassen willst, aber für ein funktionierendes Grundsetup reicht deutlich weniger, als viele erwarten.

Komponente	Mindestversion / Empfehlung	Hinweis
Docker Engine	27.x oder neuer	Docker Desktop unter Windows/macOS oder Docker Engine unter Linux
Docker Compose	v2	Meist bereits in Docker Desktop enthalten
Open WebUI	0.11.1	Aktuelle Version laut openwebui.com, Stand August 2026
Ollama	aktuelle Version	Als lokales Backend für Modelle wie Llama oder Mistral
vLLM (optional)	0.28.0	Für High-Throughput-Serving und Kimi-K3-Unterstützung, Release vom 26. August 2026
Arbeitsspeicher	16 GB (min.), 32 GB+ empfohlen	Abhängig von Modellgröße und Kontextfenster
Freier Speicherplatz	mind. 30 GB	Modelle wie 7B-Varianten belegen schnell 5-15 GB
GPU (optional)	NVIDIA mit CUDA 12.x	Für spürbar schnellere Inferenz, nicht zwingend nötig

Ohne GPU funktioniert das Setup ebenfalls, die Antwortzeiten steigen dann aber je nach Modellgröße von wenigen Sekunden auf teils über eine Minute pro Antwort. Für erste Tests mit kleineren Modellen (7B-Klasse) reicht ein aktueller Laptop mit 16 GB RAM völlig aus.

Wichtig ist außerdem, welches Betriebssystem den Unterbau bildet. Unter Linux läuft Docker nativ und beansprucht kaum zusätzlichen Overhead. Unter Windows und macOS läuft Docker Desktop dagegen in einer virtuellen Maschine, was zusätzlichen Arbeitsspeicher kostet. Wer knapp bei RAM ist, sollte deshalb bei Windows- oder Mac-Installationen eher zur oberen Grenze der empfohlenen 32 GB tendieren, um sowohl Docker-Overhead als auch das eigentliche Modell komfortabel unterzubringen.

Schritt 1: Docker installieren und vorbereiten

Open WebUI läuft am zuverlässigsten als Docker-Container. Auf Linux-Systemen installierst du Docker über das offizielle Convenience-Skript. Unter Ubuntu oder Debian sieht das so aus:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker
docker --version

Unter Windows und macOS installierst du stattdessen Docker Desktop und startest die Anwendung einmal, damit der Hintergrunddienst läuft. Prüfe danach mit docker ps, ob der Docker-Daemon erreichbar ist. Kommt eine Fehlermeldung wie “Cannot connect to the Docker daemon”, ist entweder der Dienst nicht gestartet oder dein Nutzerkonto gehört noch nicht zur Docker-Gruppe.

Schritt 2: Ollama als lokales Modell-Backend einrichten

Open WebUI braucht ein Backend, das die eigentliche Inferenz übernimmt. Für den Einstieg ist Ollama die einfachste Wahl, weil es Modelle automatisch herunterlädt und verwaltet. Installation unter Linux:

curl -fsSL https://ollama.com/install.sh | sh
ollama serve &
ollama pull llama3
ollama pull mistral

Der Befehl ollama serve startet den Hintergrunddienst auf Port 11434. Mit ollama pull lädst du ein Modell herunter, wobei Größe und Downloadzeit stark variieren: Ein 7B-Modell wiegt üblicherweise 4-5 GB, größere Varianten entsprechend mehr. Wer bereits ein separates Tutorial zu Ollama gelesen hat, kann diesen Schritt überspringen und direkt mit einer laufenden Ollama-Instanz weitermachen.

Ein häufiger Anfängerfehler an dieser Stelle: Der Befehl ollama serve muss dauerhaft im Hintergrund laufen, damit Open WebUI später eine Verbindung aufbauen kann. Wer die Konsole schließt, in der ollama serve gestartet wurde, beendet damit auch den Dienst. Für einen dauerhaften Betrieb lohnt es sich, Ollama stattdessen als systemd-Dienst einzurichten oder ebenfalls über Docker zu betreiben, was den Vorteil hat, dass beide Komponenten mit demselben Werkzeug verwaltet werden.

Schritt 3: Open WebUI per Docker starten

Jetzt kommt der eigentliche Kern der Anleitung. Der offizielle Docker-Befehl für die Standardinstallation mit Ollama-Anbindung lautet:

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Der Parameter --add-host sorgt dafür, dass der Container die auf dem Host laufende Ollama-Instanz erreicht, auch wenn beide in getrennten Netzwerk-Namespaces laufen. Das benannte Volume open-webui speichert Chatverläufe, Nutzerkonten und Einstellungen dauerhaft, sodass ein Container-Neustart keine Daten verliert. Nach etwa 15-30 Sekunden ist die Oberfläche unter http://localhost:3000 erreichbar.

Wer lieber mit Docker Compose arbeitet, weil er das Setup versionieren oder um weitere Dienste erweitern will, nutzt stattdessen diese Compose-Datei:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    volumes:
      - open-webui-data:/app/backend/data
    extra_hosts:
      - "host.docker.internal:host-gateway"
    restart: always

volumes:
  open-webui-data:

Gestartet wird die Compose-Konfiguration mit docker compose up -d. Der Vorteil gegenüber dem einzelnen docker run-Befehl: Änderungen an Ports, Volumes oder Umgebungsvariablen lassen sich sauber in einer Datei nachvollziehen und mit einem Team teilen.

Wer eine GPU-Beschleunigung für das spätere Modell-Backend nutzen will, muss zusätzlich das NVIDIA Container Toolkit installieren, damit Docker-Container auf die Grafikkarte zugreifen können. Ohne dieses Toolkit bleibt der Parameter --gpus all aus Schritt 6 wirkungslos, und die Inferenz läuft trotz vorhandener GPU auf der CPU weiter, meist ohne dass eine klare Fehlermeldung darauf hinweist.

Schritt 4: Ersten Admin-Account anlegen

Beim ersten Aufruf von http://localhost:3000 zeigt Open WebUI eine Registrierungsmaske. Der erste angelegte Account erhält automatisch Administratorrechte, alle danach registrierten Nutzer landen zunächst in der Rolle “Pending” und müssen vom Admin freigeschaltet werden. Das ist besonders wichtig, wenn die Instanz nicht nur auf localhost, sondern im Firmennetz erreichbar ist, da sonst jeder mit Netzwerkzugriff ein Konto anlegen könnte.

Trage im Registrierungsformular Name, E-Mail-Adresse und ein Passwort ein. Danach landest du direkt im Chat-Interface, das dem von ChatGPT bewusst ähnelt, um Umsteigern die Eingewöhnung zu erleichtern.

Schritt 5: Modelle in Open WebUI verbinden

Falls Ollama korrekt konfiguriert ist, erkennt Open WebUI die dort geladenen Modelle automatisch und listet sie im Dropdown-Menü oben im Chat. Ist die Liste leer, prüfst du unter “Einstellungen” → “Admin-Bereich” → “Verbindungen” die hinterlegte Ollama-Basis-URL. Sie muss auf http://host.docker.internal:11434 zeigen, wenn Open WebUI im Container und Ollama auf dem Host läuft.

Mit dem neuen /model-Slash-Command aus Version 0.11.1 lässt sich das aktive Modell mitten im Chat wechseln, ohne den Dialog zu verlassen. Das spart bei Vergleichstests zwischen mehreren Modellen deutlich Zeit.

Welches Modell passt zu welchem Anwendungsfall

Nicht jedes Modell eignet sich für jede Aufgabe, und die Modellgröße bestimmt direkt, wie viel Hardware du brauchst. Für einfache Chat-Anwendungen und Textzusammenfassungen reichen Modelle der 7B- bis 8B-Klasse wie Llama 3 oder Mistral, die auf den meisten aktuellen Laptops noch akzeptabel laufen. Sobald komplexere Aufgaben wie Code-Generierung oder mehrstufiges Schlussfolgern gefragt sind, lohnt sich der Wechsel zu größeren Modellen, was aber proportional mehr Arbeitsspeicher und im Idealfall eine dedizierte GPU verlangt.

Mistral Nemo, das laut dem offiziellen Mistral-Changelog 2026 veröffentlicht wurde, positioniert sich als Kompromiss zwischen Geschwindigkeit und Qualität und eignet sich gut als Standardmodell für allgemeine Chat-Aufgaben. Für spezialisierte Roboter- oder Automatisierungsszenarien hat Mistral zusätzlich Robostral Navigate vorgestellt, ein 8B-Modell für die Navigation von Robotern per natürlicher Sprache und einer einzelnen RGB-Kamera, das laut Unternehmensangaben Bestwerte auf dem R2R-CE-Benchmark erreicht. Für die meisten Open-WebUI-Nutzer ohne Robotik-Anwendungsfall ist das zwar keine direkte Kaufempfehlung, zeigt aber, wie breit sich das Mistral-Ökosystem inzwischen aufgestellt hat.

Wer sehr große Modelle wie Kimi K3 einsetzen will, kommt an einem leistungsfähigeren Backend wie vLLM kaum vorbei, weil Ollama bei diesen Größenordnungen und bei parallelen Anfragen an seine praktischen Grenzen stößt. Der nächste Schritt zeigt, wie diese Anbindung konkret aussieht.

Schritt 6: vLLM als High-Performance-Backend anbinden

Ollama ist ideal zum Einstieg, stößt bei parallelen Anfragen oder sehr großen Modellen aber an Grenzen. Wer produktive Lasten fahren will, etwa mehrere Nutzer gleichzeitig, sollte auf vLLM als Inferenz-Engine wechseln. Version 0.28.0 vom 26. August 2026 bringt laut Release-Notizen einen “Full-Stack Speed Pass” speziell für das Modell Kimi K3 und optimiert damit Durchsatz und Latenz bei genau der Art von Last, die Open WebUI erzeugt.

docker run -d --gpus all \
  -p 8000:8000 \
  --name vllm-server \
  vllm/vllm-openai:latest \
  --model mistralai/Mistral-7B-Instruct-v0.3 \
  --host 0.0.0.0 \
  --port 8000

vLLM stellt eine OpenAI-kompatible API bereit. In Open WebUI trägst du unter “Admin-Bereich” → “Verbindungen” → “OpenAI-API” die URL http://host.docker.internal:8000/v1 ein. Ein API-Key ist bei einer selbst gehosteten vLLM-Instanz meist nicht zwingend erforderlich, das Feld muss aber trotzdem mit einem beliebigen Platzhalterwert gefüllt sein, da das Frontend sonst die Verbindung ablehnt.

Laut den Release-Notizen zu vLLM 0.27.0 (veröffentlicht am 10. August 2026 mit 561 Commits von 242 Mitwirkenden) unterstützt die Engine inzwischen auch Modelle wie Qwen3.5 und VaultGemma nativ, was die Auswahl für Selbsthoster deutlich erweitert.

Schritt 7: Tool-Call-Freigaben und Sicherheits-Guardrails aktivieren

Eines der wichtigsten neuen Features in Open WebUI 0.11.1 sind die “Tool-Call-Freigaben”. Damit muss jede Aktion, die ein Modell über ein angebundenes Werkzeug ausführen will (etwa eine Websuche, ein Datei-Zugriff oder ein HTTP-Request), erst vom Nutzer bestätigt werden, bevor sie tatsächlich läuft. Das reduziert das Risiko, dass ein durch Prompt Injection manipuliertes Modell unbemerkt Aktionen im Hintergrund ausführt.

Aktiviert wird die Freigabepflicht unter “Admin-Bereich” → “Einstellungen” → “Tools”. Für Umgebungen mit höheren Sicherheitsanforderungen lohnt sich zusätzlich der Einsatz eines dedizierten Guardrail-Tools wie LLM Guard, das Input- und Output-Filter sowie eine Anonymisierungsfunktion für Prompt-Injection-Erkennung mitbringt. Solche Tools lassen sich als vorgeschalteter Proxy zwischen Open WebUI und dem Modell-Backend betreiben.

Gerade bei Tool-Integrationen, die auf externe Websuchen oder Datei-Schreibzugriffe zugreifen dürfen, sollte die Freigabepflicht standardmäßig aktiv bleiben, statt sie aus Bequemlichkeit für den Alltagsbetrieb zu deaktivieren. Ein einzelner unbestätigter, aber automatisch ausgeführter Tool-Aufruf kann im schlimmsten Fall dazu führen, dass ein manipuliertes Modell Daten an eine externe Adresse überträgt oder lokale Dateien verändert. Der kurze zusätzliche Klick zur Bestätigung ist ein kleiner Preis für diese zusätzliche Kontrolle.

Schritt 8: Dateizugriff und Wissensbasis einrichten

Der neue Terminal-Dateibrowser erlaubt es, Dokumente direkt im Chat-Interface zu durchsuchen und in eine Antwort einfließen zu lassen, ohne eine komplette Retrieval-Pipeline aufsetzen zu müssen. Unter “Arbeitsbereich” → “Wissen” lädst du PDF-, Markdown- oder Textdateien hoch, die anschließend als Kontext für Antworten zur Verfügung stehen.

Für größere Dokumentenmengen, etwa eine komplette interne Wissensdatenbank, lohnt sich die Kombination mit einer echten Vektor-Datenbank. Open WebUI unterstützt hierfür unter anderem ChromaDB als Standard-Backend, was ohne zusätzliche Konfiguration direkt funktioniert.

Wichtig für die Praxis: Je größer die Wissensbasis, desto sorgfältiger sollte die Struktur der hochgeladenen Dokumente sein. Gut gegliederte PDFs mit klaren Überschriften liefern in der Regel präzisere Antworten als ein einziges, unstrukturiertes Sammeldokument mit hunderten Seiten. Wer eine bestehende Dokumentensammlung migriert, sollte deshalb vorab prüfen, ob sich große Dateien sinnvoll in kleinere, thematisch klar abgegrenzte Abschnitte aufteilen lassen.

Schritt 9: Multimodale Erweiterungen mit LocalAI kombinieren

Wer über reinen Text hinausgehen will, kann Open WebUI zusätzlich mit LocalAI verbinden. Die Version 4.7.0 vom 14. Juli 2026 brachte laut Projekt-Changelog eine UI-verwaltete Bibliothek für Voice-Cloning, lokale Video- und Audio-Avatar-Generierung sowie neue Audio-Engines mit Streaming-Text-to-Speech und diarisierter Transkription (also einer Sprecher-Trennung bei mehreren Stimmen).

docker run -d -p 8080:8080 \
  --name localai \
  -v localai-models:/models \
  localai/localai:latest-cpu

Danach fügst du LocalAI in Open WebUI als zusätzliche OpenAI-kompatible Verbindung hinzu, analog zum vLLM-Setup aus Schritt 6. Damit lassen sich in einer einzigen Oberfläche Text-, Sprach- und Avatar-Funktionen bündeln, ohne mehrere getrennte Tools bedienen zu müssen.

Schritt 10: Nutzerverwaltung und Rollen für Teams konfigurieren

Für den Einsatz im Team richtest du unter “Admin-Bereich” → “Nutzer” Rollen und Gruppen ein. Open WebUI unterscheidet zwischen Administrator, Nutzer und der bereits erwähnten Pending-Rolle für unbestätigte Registrierungen. Über Gruppen lassen sich zusätzlich Zugriffsrechte auf bestimmte Modelle oder Wissensbasen beschränken, was bei mehreren Abteilungen mit unterschiedlichen Datenschutzanforderungen relevant wird.

Die neuen “Admin-Defaults” aus Version 0.11.1 erlauben es außerdem, Standardeinstellungen für neue Nutzerkonten zentral vorzugeben, etwa Standardmodell oder Sprache, statt jeden Account einzeln zu konfigurieren.

Skalierung: Mehrere Nutzer und parallele Anfragen

Ein einzelner Nutzer merkt in einer Testinstallation selten, wie stark die Last steigt, sobald mehrere Kolleginnen und Kollegen gleichzeitig Anfragen stellen. Jede gleichzeitige Chat-Anfrage bindet Rechenkapazität auf dem Modell-Backend, und Ollama verarbeitet Anfragen standardmäßig eher sequenziell als in echter Parallelität. Für Teams ab etwa fünf bis zehn gleichzeitigen Nutzern lohnt sich deshalb der bereits beschriebene Wechsel zu vLLM, dessen Architektur von Grund auf für hohen Durchsatz bei vielen gleichzeitigen Anfragen ausgelegt ist.

Ein zweiter Hebel ist die Trennung von Open WebUI und Modell-Backend auf unterschiedliche Maschinen. Läuft die Oberfläche auf einem schlanken V-Server, während die eigentliche Inferenz auf einer separaten GPU-Maschine im selben Netz stattfindet, verbessert das sowohl Antwortzeiten als auch Ausfallsicherheit, weil ein Neustart der Weboberfläche keine laufenden Modellberechnungen unterbricht. Die Verbindung zwischen beiden Komponenten läuft dann einfach über die interne Netzwerkadresse statt über host.docker.internal.

Ein dritter, oft übersehener Punkt betrifft das Kontextfenster. Je länger die Unterhaltung oder je mehr Dokumente in eine Wissensbasis eingebunden werden, desto mehr Arbeitsspeicher und Rechenzeit verbraucht eine einzelne Anfrage, unabhängig von der Zahl gleichzeitiger Nutzer. Bei intensiver Nutzung von langen Dokumenten empfiehlt es sich deshalb, das maximale Kontextfenster pro Modell in den Admin-Einstellungen bewusst zu begrenzen, statt es auf den technischen Maximalwert zu stellen. Das verhindert, dass einzelne, sehr lange Anfragen das gesamte System für andere Nutzer spürbar verlangsamen.

Schritt 11: Reverse Proxy und HTTPS für den Netzwerkzugriff

Sobald Open WebUI nicht nur lokal, sondern im Heim- oder Firmennetz erreichbar sein soll, gehört ein Reverse Proxy mit TLS-Verschlüsselung dazu. Ein einfaches Beispiel mit Nginx:

server {
    listen 443 ssl;
    server_name ki.beispiel-firma.de;

    ssl_certificate /etc/letsencrypt/live/ki.beispiel-firma.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ki.beispiel-firma.de/privkey.pem;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Die beiden proxy_set_header-Zeilen für Upgrade und Connection sind zwingend nötig, weil Open WebUI für Streaming-Antworten WebSocket-Verbindungen nutzt. Fehlen sie, bricht der Chat mitten in der Antwort ab oder zeigt gar nichts an.

Schritt 12: Backup und Update-Strategie festlegen

Da alle Daten im Docker-Volume open-webui liegen, reicht für ein Backup ein einfacher Export:

docker run --rm -v open-webui:/data -v $(pwd):/backup \
  alpine tar czf /backup/open-webui-backup-$(date +%F).tar.gz -C /data .

Angesichts der hohen Release-Frequenz (mehrere Versionen pro Monat) empfiehlt es sich, vor jedem Update ein Backup zu ziehen und Änderungen zunächst in einer Testumgebung zu prüfen, bevor eine produktive Instanz aktualisiert wird. Ein Update selbst ist mit docker pull ghcr.io/open-webui/open-webui:main gefolgt von einem Container-Neustart in der Regel in unter einer Minute erledigt.

Für automatisierte Backups bietet sich ein einfacher Cron-Job an, der das oben gezeigte Export-Kommando täglich oder wöchentlich ausführt und ältere Archive nach einer festgelegten Frist löscht. So bleibt der Speicherplatz unter Kontrolle, ohne dass Backups manuell angestoßen werden müssen. Wer die Instanz produktiv für ein Team betreibt, sollte die Backup-Archive zusätzlich auf einem zweiten physischen Medium oder einem separaten Server ablegen, damit ein Hardware-Defekt am Hauptsystem nicht gleichzeitig die Sicherungen mit sich reißt.

Das fertige Projekt: Komplettes Docker-Compose-Setup

Wer alle Komponenten aus dieser Anleitung, also Open WebUI, Ollama und optional vLLM, in einem einzigen Setup bündeln will, nutzt folgende vollständige Compose-Datei als Ausgangspunkt:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama-data:/root/.ollama
    restart: always

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - open-webui-data:/app/backend/data
    depends_on:
      - ollama
    restart: always

volumes:
  ollama-data:
  open-webui-data:

Diese Konfiguration startet beide Dienste im selben Docker-Netzwerk, sodass Open WebUI die Ollama-Instanz direkt über den Servicenamen ollama erreicht, ganz ohne die vorher nötige host.docker.internal-Sonderbehandlung. Gestartet mit docker compose up -d, ist die Umgebung nach dem ersten Modell-Download ein vollständig funktionsfähiges, selbst gehostetes KI-System.

Typische Ausgabe: So sieht ein erfolgreicher Start aus

Nach dem Start solltest du in den Container-Logs eine Ausgabe ähnlich dieser sehen:

$ docker logs open-webui
INFO:     Started server process [1]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)
INFO:     Open WebUI version: 0.11.1

Erscheint stattdessen eine Fehlermeldung wie Address already in use, belegt bereits ein anderer Prozess Port 3000 oder 8080. Ändere in diesem Fall die Port-Zuordnung im docker run-Befehl, etwa auf -p 3001:8080.

Häufige Fehler beim Einrichten (5 Stolperfallen)

Bei der Recherche zu diesem Tutorial und in eigenen Testinstallationen tauchten immer wieder dieselben fünf Fehlerquellen auf.

Falsche Ollama-URL im Container: Wird localhost statt host.docker.internal eingetragen, findet der Container die Ollama-Instanz auf dem Host nicht, weil localhost im Container auf sich selbst zeigt.
Fehlendes Volume beim ersten Start: Wer den -v-Parameter vergisst, verliert bei jedem Container-Neustart sämtliche Chatverläufe und Nutzerkonten.
Zu wenig Arbeitsspeicher für das gewählte Modell: Ein 13B- oder größeres Modell auf einem System mit nur 8 GB RAM führt zu Absturz oder extrem langsamer Inferenz, statt zu einer klaren Fehlermeldung.
Firewall blockiert Port 3000: Besonders bei Servern hinter einer Unternehmens-Firewall bleibt die Oberfläche von außen unerreichbar, obwohl der Container lokal läuft.
Vergessene Freigabe neuer Nutzerkonten: Nutzer registrieren sich, landen aber im Status “Pending” und wundern sich, warum sie sich nicht einloggen können, weil der Admin die Freigabe im Backend übersehen hat.

Alle fünf Fehler haben eines gemeinsam: Sie entstehen nicht durch fehlerhafte Software, sondern durch Netzwerk- oder Konfigurationsannahmen, die beim ersten Setup leicht übersehen werden. Wer die Reihenfolge aus dieser Anleitung Schritt für Schritt durchgeht und nach jedem größeren Schritt kurz mit docker logs open-webui die Logs prüft, findet die meisten dieser Probleme innerhalb weniger Minuten.

Troubleshooting: Die 8 häufigsten Probleme und ihre Lösung

Problem	Ursache	Lösung
Container startet, Oberfläche bleibt weiß	JavaScript-Bundle lädt nicht vollständig	Browser-Cache leeren, Container-Logs auf Fehler prüfen
“Connection refused” bei Ollama	Ollama-Dienst läuft nicht oder falscher Port	`ollama serve` manuell starten, Port 11434 prüfen
Modelle werden nicht angezeigt	Falsche Basis-URL in den Verbindungseinstellungen	URL auf `host.docker.internal:11434` setzen
Chat bricht mitten in der Antwort ab	Reverse Proxy leitet WebSockets nicht weiter	Upgrade- und Connection-Header im Proxy ergänzen
Sehr langsame Antworten ohne GPU	CPU-Inferenz bei großem Modell	Kleineres Modell wählen oder GPU-Passthrough aktivieren
Datei-Upload schlägt fehl	Upload-Limit oder fehlende Schreibrechte im Volume	Limit in den Admin-Einstellungen erhöhen, Volume-Rechte prüfen
Tool-Call wird nicht ausgeführt	Freigabe wurde nicht bestätigt oder Tool falsch konfiguriert	Freigabedialog im Chat bestätigen, Tool-Endpunkt testen
Update bricht mit Datenbankfehler ab	Kein Backup vor größerem Versionssprung	Backup einspielen, Änderungsprotokoll auf GitHub prüfen

Fortgeschrittene Tipps für den produktiven Einsatz

Wer über das reine Ausprobieren hinausgeht, profitiert von ein paar zusätzlichen Kniffen. Erstens: Für Teams mit unterschiedlichen Abteilungen lohnt es sich, pro Abteilung eine eigene Wissensbasis anzulegen, statt alle Dokumente in einen gemeinsamen Topf zu werfen. Das hält die Kontext-Relevanz hoch und verhindert, dass Antworten mit irrelevanten Informationen aus anderen Bereichen vermischt werden.

Zweitens: Delta-Streaming, eines der Kernfeatures aus Version 0.11.1, reduziert laut den offiziellen Release-Hinweisen den Antwort-Traffic erheblich. Das zahlt sich besonders bei Installationen auf Heimservern oder kleinen V-Servern mit begrenzter Bandbreite aus, etwa wenn mehrere Nutzer gleichzeitig über eine langsamere Internetverbindung zugreifen.

Drittens: Kombiniere für sicherheitskritische Einsätze die eingebauten Tool-Call-Freigaben mit einem externen Guardrail-Tool wie NeMo Guardrails oder LLM Guard. Die eingebaute Freigabe verhindert unerwünschte Aktionen, ein externes Guardrail-Tool filtert zusätzlich gefährliche Eingaben, bevor sie das Modell überhaupt erreichen. Orientierung für die Bewertung solcher Policies bietet die OWASP-Top-10-Liste für Large Language Model Applications.

Viertens: Wer mehrere Modelle parallel testen will, etwa Mistral Nemo gegen ein via vLLM angebundenes Kimi K3, sollte separate Chat-Ordner anlegen. Open WebUI erlaubt das Organisieren von Unterhaltungen in Ordnern, was bei systematischen Modellvergleichen die Übersicht deutlich verbessert.

Fünftens: Nutze die verbesserte Chat-Suche aus Version 0.11.1, sobald die Wissensbasis oder der Chatverlauf über mehrere Wochen gewachsen ist. Gerade in Teams, in denen mehrere Personen dieselbe Instanz nutzen, geht sonst schnell der Überblick verloren, welche Frage bereits vor einigen Tagen beantwortet wurde. Eine kurze interne Konvention, etwa aussagekräftige Chat-Titel statt der automatisch generierten Kurzfassung, spart auf Dauer viel Suchzeit.

Open WebUI im Vergleich zu anderen lokalen Oberflächen

Open WebUI ist nicht die einzige Möglichkeit, lokale Modelle über eine grafische Oberfläche zu bedienen. Die folgende Tabelle ordnet die wichtigsten Alternativen ein.

Tool	Betriebsart	Stärke	Schwäche
Open WebUI	Docker, selbst gehostet	Multi-User, Tool-Calls, Wissensbasis	Setup erfordert Docker-Grundkenntnisse
LM Studio	Desktop-App	Sehr einfache lokale Nutzung für Einzelpersonen	Keine Multi-User-Verwaltung
AnythingLLM	Docker oder Desktop	Starker Fokus auf Dokumenten-Chat	Kleinere Community als Open WebUI
LibreChat	Docker, selbst gehostet	Breite Anbindung an viele Cloud-APIs	Weniger auf reines Self-Hosting optimiert

Für Einzelpersonen ohne Server-Erfahrung ist LM Studio oft der schnellere Einstieg. Sobald aber mehrere Nutzer, eine Wissensbasis oder Tool-Integrationen ins Spiel kommen, zieht Open WebUI durch seinen größeren Funktionsumfang klar vorbei.

Ein Aspekt, der in vielen Vergleichen untergeht: Diese Tools schließen sich nicht gegenseitig aus. Viele Nutzer setzen LM Studio für schnelle, lokale Einzeltests auf dem eigenen Rechner ein und betreiben parallel eine Open-WebUI-Instanz für den Team-Zugriff auf demselben oder einem separaten Server. Wer bereits in eine Wissensbasis und Nutzerverwaltung investiert hat, sollte dagegen nicht ohne triftigen Grund zwischen den Plattformen wechseln, weil Chatverläufe und Dokumente nicht automatisch migriert werden.

Datenschutz und Compliance in der DACH-Region

Ein selbst gehostetes Setup wie dieses löst zwar die Frage, wohin Chatdaten übertragen werden, ersetzt aber keine vollständige Datenschutz-Folgenabschätzung. Wer Open WebUI im Unternehmenskontext einsetzt, sollte trotzdem dokumentieren, welche Daten im Docker-Volume gespeichert werden, wie lange sie aufbewahrt bleiben und wer administrativen Zugriff hat. Gerade weil die Installation “auf eigener Hardware” oft mit “automatisch DSGVO-konform” verwechselt wird, lohnt sich ein kurzer Blick in die eigene Informationssicherheitsrichtlinie, bevor die Instanz produktiv geschaltet wird.

Ein praktischer Vorteil bleibt trotzdem bestehen: Anders als bei gehosteten Diensten läuft bei einem lokalen Setup keine Anfrage über eine externe API, was die Kontrolle über Auftragsverarbeitungsverträge und Datenübermittlung in Drittländer erheblich vereinfacht.

Sinnvoll ist außerdem eine klare interne Regelung, welche Art von Daten überhaupt in den Chat oder die Wissensbasis eingegeben werden darf. Auch bei einem lokalen Setup bleibt das Risiko bestehen, dass sensible Informationen versehentlich in einem Chatverlauf landen, der später von einem anderen Teammitglied mit geringeren Zugriffsrechten eingesehen wird. Eine kurze schriftliche Richtlinie, ergänzt um die bereits beschriebenen Gruppenrechte aus der Nutzerverwaltung, deckt die meisten dieser Fälle ab, ohne den praktischen Nutzen der Plattform einzuschränken.

Umstieg von einer Cloud-API auf ein selbst gehostetes Setup

Viele Teams starten mit einer Cloud-API von OpenAI, Anthropic oder Google und wechseln erst später zu einer lokalen Lösung, meist getrieben von Kosten, Datenschutz oder beidem. Der Umstieg lässt sich schrittweise gestalten, statt alles auf einmal umzustellen. Ein bewährter Weg: Zunächst läuft Open WebUI parallel zur bestehenden Cloud-Anbindung, wobei beide Backends gleichzeitig eingebunden werden. Nutzer können dann im laufenden Betrieb zwischen Cloud-Modell und lokalem Modell wechseln und für unkritische Aufgaben schrittweise auf das lokale Setup umsteigen, ohne dass die gewohnte Cloud-Option sofort komplett wegfällt.

Diese Übergangsphase eignet sich auch gut, um die Qualität lokaler Modelle für die eigenen Anwendungsfälle realistisch einzuschätzen. Nicht jede Aufgabe, die heute über eine große Cloud-API läuft, lässt sich verlustfrei auf ein kleineres, lokal gehostetes Modell übertragen. Komplexe mehrstufige Aufgaben oder sehr lange Kontexte bleiben oft eine Domäne der größten Cloud-Modelle, während Zusammenfassungen, interne FAQ-Antworten oder Standard-Support-Anfragen sich in der Praxis gut auf lokale Modelle verlagern lassen.

Bekannte Einschränkungen: Wann sich Open WebUI nicht lohnt

So nützlich Open WebUI ist, für jeden Anwendungsfall ist es die falsche Wahl. Wer nur gelegentlich eine einzelne Frage an ein Modell stellt, etwa ein paar Mal pro Woche, zieht mit einer kostenlosen oder günstigen Cloud-API meist den kürzeren Weg, weil Anschaffung und Wartung einer eigenen Infrastruktur den geringen Nutzungsumfang nicht rechtfertigen. Auch wer auf die absolut leistungsfähigsten verfügbaren Modelle angewiesen ist, etwa für sehr anspruchsvolle Programmieraufgaben, stößt bei lokal betreibbaren Modellen häufiger an Qualitätsgrenzen als bei den größten Cloud-Angeboten.

Ein weiterer Punkt: Ohne eigene GPU wird jede Antwort spürbar langsamer, was bei zeitkritischen Anwendungen, etwa einem Kundenservice-Chat mit Echtzeit-Erwartung, zum Problem werden kann. Wer sich nicht sicher ist, ob der Aufwand sich lohnt, kann parallel zu einer bestehenden Cloud-Lösung testweise eine kleine Open-WebUI-Instanz aufsetzen und über einige Wochen den tatsächlichen Nutzungsumfang beobachten, bevor eine größere Investition in Hardware ansteht.

Kosten im Überblick: Was ein selbst gehostetes Setup wirklich bringt

Open WebUI selbst ist als Open-Source-Software kostenlos. Die tatsächlichen Kosten entstehen durch Hardware und Strom, nicht durch Lizenzgebühren. Ein Mini-PC oder gebrauchter Server mit 32 GB RAM und einer Consumer-GPU reicht für kleinere Teams bereits aus und schlägt über die Nutzungsdauer gerechnet oft günstiger zu Buche als laufende API-Kosten bei einem Cloud-Anbieter, insbesondere bei hohem, dauerhaftem Nutzungsvolumen. Bei sporadischer Nutzung mit wenigen Anfragen pro Tag bleibt eine Cloud-API dagegen häufig die günstigere Option, weil die Hardware sonst ungenutzt Strom verbraucht.

Bei der Rechnung sollte man zusätzlich den Wartungsaufwand einkalkulieren. Ein selbst gehostetes System muss aktualisiert, überwacht und im Zweifel wiederhergestellt werden, was Zeit kostet, die bei einem gemanagten Cloud-Dienst entfällt. Für Teams mit ohnehin vorhandener IT-Infrastruktur und Docker-Erfahrung fällt dieser Mehraufwand kaum ins Gewicht. Für Einzelpersonen ohne technischen Hintergrund kann er dagegen den vermeintlichen Kostenvorteil der lokalen Lösung wieder aufzehren, insbesondere wenn Updates oder Fehlerbehebungen mehrfach im Monat anfallen.

Häufig gestellte Fragen

Brauche ich eine GPU, um Open WebUI zu nutzen?
Nein. Open WebUI selbst benötigt keine GPU, da es nur die Oberfläche stellt. Das angebundene Modell-Backend (Ollama oder vLLM) läuft zwar auch ohne GPU auf der CPU, ist dann aber deutlich langsamer, besonders bei größeren Modellen.

Kann ich Open WebUI ohne Docker installieren?
Ja, über pip mit pip install open-webui und dem Befehl open-webui serve. Die Docker-Variante ist aber der von den Entwicklern empfohlene und am besten getestete Weg, weil sie Abhängigkeiten sauber kapselt.

Funktioniert Open WebUI auch mit ChatGPT- oder Claude-APIs?
Ja. Neben lokalen Backends unterstützt Open WebUI auch OpenAI-kompatible Cloud-APIs, die sich unter den Verbindungseinstellungen mit API-Key hinterlegen lassen. Damit lässt sich eine Instanz auch als einheitliche Oberfläche für mehrere Cloud-Anbieter gleichzeitig nutzen.

Wie oft sollte ich Open WebUI aktualisieren?
Angesichts der Release-Kadenz von mehreren Versionen pro Monat reicht ein Update alle zwei bis vier Wochen für die meisten Anwendungsfälle. Sicherheitsrelevante Patches sollten zeitnaher eingespielt werden.

Unterstützt Open WebUI mehrere gleichzeitige Nutzer?
Ja, über die eingebaute Nutzer- und Rollenverwaltung mit Admin-, Nutzer- und Pending-Status. Für größere Teams empfiehlt sich zusätzlich der Einsatz eines Reverse Proxys mit TLS und gegebenenfalls Single-Sign-On über OAuth.

Was ist der Unterschied zwischen Open WebUI und Ollama?
Ollama ist das Backend, das Modelle lädt und Inferenz-Anfragen beantwortet. Open WebUI ist die Oberfläche darüber, die Chat, Nutzerverwaltung, Dateizugriff und Tool-Integrationen bereitstellt. Beide ergänzen sich, ersetzen sich aber nicht gegenseitig.

Kann ich Kimi K3 in Open WebUI nutzen?
Ja, allerdings nicht direkt über Ollama, sondern über ein vLLM-Backend, das laut den Release-Notizen zu vLLM 0.28.0 seit dem 26. August 2026 optimierte Unterstützung für Kimi K3 bietet.

Ist die Nutzung von Open WebUI im Unternehmen rechtlich unbedenklich?
Das selbst gehostete Setup vereinfacht die Datenschutz-Bewertung, ersetzt aber keine eigene Prüfung. Zugriffsrechte, Aufbewahrungsfristen und die Absicherung des Servers gegen unbefugten Zugriff müssen weiterhin dokumentiert und umgesetzt werden.

Wie migriere ich eine bestehende Open-WebUI-Instanz auf einen neuen Server?
Am einfachsten über das in dieser Anleitung gezeigte Backup-Kommando: Das Docker-Volume wird als Archiv exportiert, auf den neuen Server kopiert und dort in ein frisch angelegtes Volume zurückgespielt, bevor der Container gestartet wird. Chatverläufe, Nutzerkonten und Wissensbasen bleiben dabei vollständig erhalten.

Lässt sich Open WebUI auf einem Raspberry Pi betreiben?
Die Oberfläche selbst läuft auch auf schwacher ARM-Hardware wie einem Raspberry Pi 5, solange das Modell-Backend auf einer leistungsfähigeren Maschine im selben Netzwerk läuft. Ein vollständiges Setup inklusive Modell-Inferenz auf einem Raspberry Pi allein ist wegen der begrenzten Rechenleistung nur für sehr kleine Modelle praktikabel.

Open WebUI einrichten: KI-Plattform mit 12 Schritten [2026]