Open WebUI 2026 selbst hosten: Model-Endpoints, Storage und Security

Behandle Open WebUI als kleines System, nicht als Docker-Image. Das Ziel auf User-Seite ist klar: eine Chat-Oberfläche für OpenAI-kompatible und lokale Model-Endpoints. Der Betrieb ist erst dann akzeptabel, wenn du einen entfernten Model-Endpoint verbinden, eine Chat-Antwort streamen, ein Dokument hochladen, Retrieval ausführen und die Unterhaltung nach einem Neustart wieder öffnen kannst.

Diese Unterscheidung macht den Fehler sichtbar, auf den Operatoren nach lokalen Tests stoßen: OLLAMA_BASE_URL zeigt innerhalb des WebUI-Containers auf localhost. Außerdem wird der Backup- und Upgrade-Plan dadurch konkret genug, um ihn zu testen.

Wähle die kleinste geeignete Open-WebUI-Topologie

Beginne mit dem Netzwerk-Namespace von Open WebUI: Der Web-Listener läuft auf Port 8080, nicht auf einem Host-Port, der aus einem Laptop-Tutorial übernommen wurde. Der Netzwerkvertrag für Open WebUI ist eine OpenAI-kompatible API oder ein erreichbarer Ollama-Service. Halte private Endpoints im internen DNS, erlaube nur die erforderlichen ausgehenden Verbindungen und gib Open WebUI ein Service-Credential mit begrenztem Scope.

Sobald die Anforderung erfüllt ist, führe das vollständige Szenario aus – einen entfernten Model-Endpoint verbinden, eine Chat-Antwort streamen, ein Dokument hochladen, Retrieval ausführen und die Unterhaltung nach einem Neustart wieder öffnen. Erfasse Logs und Messwerte für Model-Latenz, parallele Streams, Embedding-Jobs, die Größe hochgeladener Dateien und das Wachstum des Vector-Index. Diese Nachweise bilden die erste bekannte funktionierende Architektur und machen spätere Wechsel zwischen Dockup-Compute und einem angeschlossenen Server testbar.

TLS ist einfach – generierte URLs sind es nicht

Die Ausstellung eines TLS-Zertifikats ist nur die Hälfte des Open-WebUI-Routings. Mache den Model-Endpoint aus dem Container-Netzwerk erreichbar. Leite den Traffic intern an 8080 weiter und übermittle das externe Schema, damit generierte URLs und Secure Cookies konsistent bleiben.

Nutze das vollständige Open-WebUI-Szenario aus einem sauberen Netzwerk, nicht nur die Root-Seite. Ein 502- oder Zertifikatsfehler lässt sich mit automatischer Domain- und TLS-Einrichtung isolieren. Wenn der Traffic den Prozess erreicht und OLLAMA_BASE_URL innerhalb des WebUI-Containers auf localhost zeigt, diagnostiziere diese Bedingung dort, wo sie auftritt, statt mehrere Redirects übereinanderzulegen.

Starte Open WebUI, ohne die beweglichen Teile zu verstecken

Halte den initialen Aufruf von Open WebUI so reproduzierbar, dass er sich in einem Pull Request überprüfen lässt.

docker run -d \
  --name open-webui \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v open-webui-data:/app/backend/data \
  -e WEBUI_SECRET_KEY=replace-with-a-long-random-value \
  ghcr.io/open-webui/open-webui:main

Verlasse dich nicht auf latest, sobald echte Daten vorhanden sind. Halte den funktionierenden Digest, den Container-User und die Ownership des Mounts fest. Verfolge das Application-Log durch einen vollständigen Test – einen entfernten Model-Endpoint verbinden, eine Chat-Antwort streamen, ein Dokument hochladen, Retrieval ausführen und die Unterhaltung nach einem Neustart wieder öffnen – und notiere alle Migrationen, bevor du die Route produktiv erreichbar machst.

Führe Open WebUI ohne Rätselraten upzugraden

Ein inaktiver Health Check sagt wenig über Open WebUI aus. Beobachte Model-Latenz, parallele Streams, Embedding-Jobs, die Größe hochgeladener Dateien und das Wachstum des Vector-Index. Löse anschließend anhand des Symptoms aus, das User tatsächlich erleben: dem Fehlschlagen der Aktion „einen entfernten Model-Endpoint verbinden, eine Chat-Antwort streamen, ein Dokument hochladen, Retrieval ausführen und die Unterhaltung nach einem Neustart wieder öffnen“. Halte Liveness lokal und günstig; Readiness sollte Migrationen oder Initialisierung melden, ohne eine Restart-Schleife auszulösen.

Der riskante Bereich bei Upgrades besteht darin, dass sich Datenbank-Migrationen, Retrieval-Backends und Einstellungen für Model-Endpoints unabhängig vom Chat-Frontend ändern können. Lies die Release Notes, erstelle einen Snapshot des Zustands, deploye die Zielversion gegen eine wiederhergestellte Kopie und wiederhole die Abnahmeaktion. Wenn OLLAMA_BASE_URL innerhalb des WebUI-Containers auf localhost zeigt, korreliere den Client-Request mit dem ersten relevanten Application-Log, statt blind Daten zu löschen oder Redirects hinzuzufügen.

Fünf Checks, die stärker sind als der Container-Health-Check

Mache den Traffic des ersten Users nicht zum Abnahmetest für Open WebUI. Bereite ungefährliche Beispieldaten vor und führe die vollständige Aktion „einen entfernten Model-Endpoint verbinden, eine Chat-Antwort streamen, ein Dokument hochladen, Retrieval ausführen und die Unterhaltung nach einem Neustart wieder öffnen“ aus. Notiere die exakte öffentliche URL, das Ergebnis, die Image-Referenz und das mit dem Lauf verbundene Log-Intervall.

Ersetze den Container und wiederhole den Test, ohne die Daten neu zu erstellen. Stelle anschließend auf einem leeren Host wieder her. Die Recovery-Bedingung ist erfüllt, wenn Accounts, Chats, Dateien und Retrieval-Collections zurückkehren und die wiederhergestellte Instanz denselben Model-Endpoint erreichen kann. Erfasse bei jedem Durchlauf Model-Latenz, parallele Streams, Embedding-Jobs, die Größe hochgeladener Dateien und das Wachstum des Vector-Index. Definiere den Alert anhand einer Verschlechterung der Transaktion statt anhand inaktiver Container-Metriken.

Ein letzter Check sollte absichtlich fehlschlagen: Entziehe der Test-Identität vorübergehend den Zugriff auf eine OpenAI-kompatible API oder einen erreichbaren Ollama-Service. Stelle sicher, dass die resultierende Open-WebUI-Meldung die relevante Grenze benennt, statt eine Datenlöschung oder einen endlosen Neustart auszulösen. Stelle die gültige Bedingung wieder her und bestätige, dass dieselbe Beispieltransaktion erfolgreich ist. Nimm diese kurze Übung in die Release-Checkliste auf.

Finde jedes persistente Byte in Open WebUI

Bei Open WebUI beginnt die Sicherheit von Redeployments mit Usern, Chats, Dateien, Vektordaten und der Application-Konfiguration. Mounte /app/backend/data vor dem Bootstrap, schreibe ungefährliche Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Teste den Pfad, indem du den Container ersetzt, während ungefährliche Beispieldaten vorhanden sind. So werden Mounts sichtbar, die auf ein Verzeichnis zu hoch oder zu niedrig zeigen.

Teste anschließend die Disaster Recovery auf einem leeren Host. Verwende bei Bedarf einen konsistenten Datenbank-Export und verifiziere, dass Accounts, Chats, Dateien und Retrieval-Collections zurückkehren und die wiederhergestellte Instanz denselben Model-Endpoint erreichen kann. Der Leitfaden für getestete Datenbank-Backups setzt ein höheres Ziel als lediglich zu prüfen, ob eine Archivdatei erstellt wurde.

Gib Open WebUI nicht den gesamten Host

Ein sicheres Open-WebUI-Deployment beginnt damit, Berechtigungen zu entziehen. Lass die Registrierung nicht offen und verwende keinen flüchtigen WEBUI_SECRET_KEY. Deaktiviere stattdessen die öffentliche Registrierung, sofern sie nicht ausdrücklich vorgesehen ist, behalte ein stabiles WebUI-Secret bei und beschränke die Model-Administration auf vertrauenswürdige User.

Behandle WEBUI_SECRET_KEY entsprechend seiner Rolle in Open WebUI: Halte sensible Werte aus Git heraus, dokumentiere die Auswirkungen einer Rotation und ersetze in der Produktion niemals ein öffentliches Beispiel. Beschränke administrative Routen, verwende für Dependencies privates DNS und überprüfe jeden Bind-Mount. Wenn Logs zentral gesammelt werden, filtere Secrets und private Inhalte, bevor sie den Server verlassen.

Nutze Dockup für die Plattformebene

Dockup übernimmt die manuelle Arbeit an Reverse Proxy und Lifecycle rund um Open WebUI. Der Service erhält während Austauschaktionen eine stabile HTTPS-Route zu 8080, injizierte Konfiguration und persistenten Storage. Ein angeschlossener Kundenserver folgt demselben Modell wie von Dockup gehostetes Compute.

Erfülle nach dem Launch den Application-Vertrag: Mache den Model-Endpoint aus dem Container-Netzwerk erreichbar, verbinde und teste eine OpenAI-kompatible API oder einen erreichbaren Ollama-Service und führe diesen Nachweis aus: einen entfernten Model-Endpoint verbinden, eine Chat-Antwort streamen, ein Dokument hochladen, Retrieval ausführen und die Unterhaltung nach einem Neustart wieder öffnen. So bleibt das One-Click-Erlebnis nützlich, ohne die Details zu verbergen, die Open WebUI wiederherstellbar und sicher machen.

Häufig gestellte Fragen

Was benötigt Open WebUI für einen produktiven Betrieb?

Routiere den Open-WebUI-Container auf Port 8080 über eine HTTPS-Origin. Die unterstützende Netzwerkanforderung ist eine OpenAI-kompatible API oder ein erreichbarer Ollama-Service. Erkläre Open WebUI erst dann für bereit, wenn du einen entfernten Model-Endpoint verbinden, eine Chat-Antwort streamen, ein Dokument hochladen, Retrieval ausführen und die Unterhaltung nach einem Neustart wieder öffnen kannst.

Welche Open-WebUI-Daten gehören in ein Backup?

Persistiere /app/backend/data und nimm User, Chats, Dateien, Vektordaten und die Application-Konfiguration in dasselbe Recovery-Manifest auf. Eine saubere Open-WebUI-Wiederherstellung ist erst dann erfolgreich, wenn Accounts, Chats, Dateien und Retrieval-Collections zurückkehren und die wiederhergestellte Instanz denselben Model-Endpoint erreichen kann.

Benötigt Open WebUI HTTPS hinter einem Reverse Proxy?

Verwende HTTPS für die öffentliche Open-WebUI-Origin und halte Port 8080 auf der internen Route. Setze die Open-WebUI-Einstellung korrekt um: Mache den Model-Endpoint aus dem Container-Netzwerk erreichbar. Bei Open WebUI schützt HTTPS Credentials oder User-Inhalte bei der Übertragung und sorgt für konsistentes, Origin-sensitives Client-Verhalten.

Wie sollte ein Open-WebUI-Upgrade getestet werden?

Stelle den aktuellen Open-WebUI-Zustand in einem isolierten Deployment wieder her, spiele die Kandidatenversion ein und wiederhole die Abnahmetransaktion. Achte besonders darauf, dass sich Datenbank-Migrationen, Retrieval-Backends und Einstellungen für Model-Endpoints unabhängig vom Chat-Frontend ändern können. Behalte das vorherige Open-WebUI-Image, bis die Grenzen für Datenmigration und Rollback verstanden sind.