📋 FAQ
💡 Warum Docker?
Wir verstehen, dass Docker möglicherweise nicht jedermanns Präferenz ist. Dieser Ansatz ist jedoch zentral für das Design und die betriebliche Effizienz unseres Projekts. Wir betrachten das Engagement des Projekts für Docker als fundamentalen Aspekt und ermutigen diejenigen, die nach anderen Bereitstellungsmethoden suchen, community-gesteuerte Alternativen zu erkunden.
F: Wie kann ich das Logo und Branding anpassen?
A: Sie können das Thema, das Logo und das Branding mit unserer Enterprise Lizenz anpassen, die exklusive Enterprise-Funktionen freischaltet.
Für weitere Details zu Enterprise-Lösungen und Branding-Anpassungen kontaktieren Sie bitte unser Vertriebsteam unter: 📧 sales@openwebui.com
F: Warum werde ich aufgefordert, mich zu registrieren? Wohin werden meine Daten gesendet?
A: Wir verlangen Ihre Registrierung, um der Administratorbenutzer für erhöhte Sicherheit zu werden. Dies stellt sicher, dass Ihre Daten sicher bleiben, falls Open WebUI jemals externen Zugriffen ausgesetzt ist. Es ist wichtig zu beachten, dass alles lokal bleibt. Wir sammeln Ihre Daten nicht. Wenn Sie sich registrieren, bleiben alle Informationen auf Ihrem Server und verlassen Ihr Gerät niemals. Ihre Privatsphäre und Sicherheit haben für uns oberste Priorität, um sicherzustellen, dass Ihre Daten jederzeit unter Ihrer Kontrolle bleiben.
F: Warum kann mein Docker-Container keine Dienste auf dem Host mit localhost erreichen?
A: Innerhalb eines Docker-Containers bezieht sich localhost auf den Container selbst und nicht auf den Host-Rechner. Diese Unterscheidung ist entscheidend für die Netzwerkkommunikation. Um eine Verbindung von Ihrem Container zu Diensten auf dem Host herzustellen, sollten Sie den DNS-Namen host.docker.internal anstelle von localhost verwenden. Dieser DNS-Name wird von Docker speziell erkannt, um solche Verbindungen zu ermöglichen und damit die übliche localhost-Scope-Beschränkung zu umgehen, wodurch der Host als erreichbare Entität vom Container aus behandelt wird.
F: Wie mache ich Dienste meines Hosts für Docker-Container zugänglich?
A: Um Dienste, die auf dem Host laufen, für Docker-Container zugänglich zu machen, konfigurieren Sie diese Dienste so, dass sie auf allen Netzwerkschnittstellen lauschen und die IP-Adresse 0.0.0.0 anstelle von 127.0.0.1 verwenden, die auf localhost beschränkt ist. Diese Konfiguration ermöglicht es den Diensten, Verbindungen von jeder IP-Adresse, einschließlich Docker-Containern, zu akzeptieren. Es ist wichtig, sich der Sicherheitsauswirkungen dieser Einrichtung bewusst zu sein, insbesondere beim Betrieb in Umgebungen mit potenziellem externen Zugriff. Die Implementierung geeigneter Sicherheitsmaßnahmen wie Firewalls und Authentifizierung kann helfen, Risiken zu mindern.
F: Warum wird mein Open WebUI nicht aktualisiert? Ich habe den Container neu gezogen/neu gestartet und nichts hat sich geändert.
A: Das Aktualisieren von Open WebUI erfordert mehr als nur das Ziehen des neuen Docker-Images. Hier sind die Gründe, warum Ihre Updates möglicherweise nicht angezeigt werden und wie Sie sicherstellen können, dass sie es tun
- Aktualisieren des Docker-Images: Der Befehl
docker pull ghcr.io/open-webui/open-webui:mainaktualisiert das Docker-Image, aber nicht den laufenden Container oder seine Daten. - Persistente Daten in Docker-Volumes: Docker-Volumes speichern Daten unabhängig vom Container-Lebenszyklus und bewahren Ihre Daten (wie Chat-Verläufe) über Updates hinweg.
- Anwenden des Updates: Stellen Sie sicher, dass Ihr Update wirksam wird, indem Sie den bestehenden Container entfernen (wodurch das Volume nicht gelöscht wird) und einen neuen mit dem aktualisierten Image und dem vorhandenen Volume erstellen.
Dieser Prozess aktualisiert die App, während Ihre Daten sicher bleiben.
F: Aber warum sollte ich meinen Container löschen? Verliere ich dann nicht meine Daten?
A: Das ist eine häufige Sorge, aber das Löschen eines Containers bedeutet nicht, dass Sie Ihre Daten verlieren, vorausgesetzt, Sie verwenden Docker-Volumes korrekt. Hier ist der Grund:
- Volumes bewahren Daten: Docker-Volumes sind so konzipiert, dass Daten außerhalb des Container-Lebenszyklus persistiert werden. Solange Ihre Daten in einem Volume gespeichert sind, bleiben sie intakt, unabhängig davon, was mit dem Container geschieht.
- Sicherer Update-Prozess: Beim Aktualisieren von Open WebUI hat das Entfernen des alten Containers und das Erstellen eines neuen mit dem aktualisierten Image keinen Einfluss auf die in Volumes gespeicherten Daten. Der Schlüssel ist, das Volume nicht explizit mit Befehlen wie
docker volume rmzu löschen.
Indem Sie die richtigen Aktualisierungsschritte befolgen – das neue Image ziehen, den alten Container entfernen, ohne das Volume zu löschen, und einen neuen Container mit dem aktualisierten Image und dem vorhandenen Volume erstellen –, wird Ihr Anwendungscode aktualisiert, während Ihre Daten unverändert und sicher bleiben.
F: Sollte ich das distro-gepackte Docker oder das offizielle Docker-Paket verwenden?
A: Wir empfehlen die Verwendung des offiziellen Docker-Pakets anstelle von distro-gepackten Versionen für den Betrieb von Open WebUI. Das offizielle Docker-Paket wird regelmäßig mit den neuesten Funktionen, Fehlerbehebungen und Sicherheitspatches aktualisiert, um eine optimale Leistung und Sicherheit zu gewährleisten. Darüber hinaus unterstützt es wichtige Funktionalitäten wie host.docker.internal, die in distro-gepackten Versionen möglicherweise nicht verfügbar sind. Diese Funktion ist für ordnungsgemäße Netzwerkkonfigurationen und Konnektivität innerhalb von Docker-Containern unerlässlich.
Durch die Wahl des offiziellen Docker-Pakets profitieren Sie von konsistentem Verhalten in verschiedenen Umgebungen, zuverlässigerem Support bei der Fehlerbehebung und Zugang zu den neuesten Docker-Fortschritten. Die breitere Docker-Community und die Ressourcen sind ebenfalls besser auf das offizielle Paket abgestimmt, sodass Sie eine Fülle von Informationen und Unterstützung für alle Probleme erhalten, auf die Sie stoßen könnten.
Alles, was Sie zum Ausführen von Open WebUI benötigen, einschließlich Ihrer Daten, bleibt unter Ihrer Kontrolle und in Ihrer Serverumgebung, was unser Engagement für Ihre Privatsphäre und Sicherheit unterstreicht. Anweisungen zur Installation des offiziellen Docker-Pakets finden Sie in der Install Docker Engine-Anleitung auf der offiziellen Dokumentationsseite von Docker.
F: Ist GPU-Unterstützung in Docker verfügbar?
A: Die GPU-Unterstützung in Docker ist verfügbar, variiert jedoch je nach Plattform. Offiziell wird die GPU-Unterstützung in Docker für Windows und Docker Engine unter Linux bereitgestellt. Andere Plattformen wie Docker Desktop für Linux und MacOS bieten derzeit keine GPU-Unterstützung. Diese Einschränkung ist für Anwendungen, die GPU-Beschleunigung benötigen, wichtig zu berücksichtigen. Für die beste Erfahrung und zur Nutzung von GPU-Fähigkeiten empfehlen wir die Verwendung von Docker auf Plattformen, die die GPU-Integration offiziell unterstützen.
F: Warum betont Open WebUI die Verwendung von Docker?
A: Die Entscheidung für Docker beruht auf seiner Fähigkeit, Konsistenz zu gewährleisten, Abhängigkeiten zu isolieren und die Bereitstellung in verschiedenen Umgebungen zu vereinfachen. Docker minimiert Kompatibilitätsprobleme und optimiert den Prozess der Einrichtung der WebUI, unabhängig vom zugrunde liegenden System. Es ist eine strategische Entscheidung der Projektbetreuer, diese Vorteile zu nutzen, auch wenn Docker eine Lernkurve hat, sind die Vorteile für Bereitstellung und Wartung erheblich. Wir verstehen, dass Docker möglicherweise nicht jedermanns Präferenz ist. Dieser Ansatz ist jedoch zentral für das Design und die betriebliche Effizienz unseres Projekts. Wir betrachten das Engagement des Projekts für Docker als fundamentalen Aspekt und ermutigen diejenigen, die nach anderen Bereitstellungsmethoden suchen, community-gesteuerte Alternativen zu erkunden.
F: Warum funktionieren Speech-to-Text (STT) und Text-to-Speech (TTS) in meiner Bereitstellung nicht?
A: Die Funktionalität von Speech-to-Text (STT) und Text-to-Speech (TTS) Diensten in Ihrer Bereitstellung erfordert möglicherweise HTTPS, um korrekt zu funktionieren. Moderne Browser erzwingen Sicherheitsmaßnahmen, die bestimmte Funktionen, einschließlich STT und TTS, darauf beschränken, nur unter sicheren HTTPS-Verbindungen zu arbeiten. Wenn Ihre Bereitstellung nicht für die Verwendung von HTTPS konfiguriert ist, funktionieren diese Dienste möglicherweise nicht wie erwartet. Die Sicherstellung, dass Ihre Bereitstellung über HTTPS zugänglich ist, kann diese Probleme beheben und die volle Funktionalität von STT/TTS-Funktionen ermöglichen.
F: Warum enthält Open WebUI keine integrierte HTTPS-Unterstützung?
A: Obwohl wir den Wunsch nach einer All-in-One-Lösung mit HTTPS-Unterstützung verstehen, glauben wir, dass ein solcher Ansatz den vielfältigen Bedürfnissen unserer Benutzerbasis nicht angemessen dienen würde. Die Implementierung von HTTPS direkt im Projekt könnte die Flexibilität einschränken und möglicherweise nicht mit den spezifischen Anforderungen oder Vorlieben aller Benutzer übereinstimmen. Um sicherzustellen, dass jeder seine Einrichtung an seine einzigartige Umgebung anpassen kann, überlassen wir die Implementierung der HTTPS-Terminierung den Benutzern für ihre Produktionsumgebungen. Diese Entscheidung ermöglicht größere Anpassungsfähigkeit und Flexibilität. Obwohl wir keine offizielle Dokumentation zur Einrichtung von HTTPS anbieten, können Community-Mitglieder auf Anfrage Anleitung geben und Einblicke und Vorschläge basierend auf ihren Erfahrungen teilen.
F: Ich habe einige neue Software aktualisiert/neu gestartet/installiert und jetzt funktioniert Open WebUI nicht mehr!
A: Wenn Ihr Open WebUI nach einem Update oder der Installation neuer Software nicht mehr startet, liegt dies wahrscheinlich an einem direkten Installationsansatz, insbesondere wenn Sie keine virtuelle Umgebung für Ihre Backend-Abhängigkeiten verwendet haben. Direkte Installationen können empfindlich auf Änderungen in der Systemumgebung reagieren, wie z. B. Updates oder Neuinstallationen, die vorhandene Abhängigkeiten ändern. Um Konflikte zu vermeiden und Stabilität zu gewährleisten, empfehlen wir die Verwendung einer virtuellen Umgebung zur Verwaltung der requirements.txt-Abhängigkeiten Ihres Backends. Dies isoliert Ihre Open WebUI-Abhängigkeiten von anderen Systempaketen und minimiert das Risiko solcher Probleme.
F: Ich habe aktualisiert/neu gestartet und jetzt funktioniert mein Login nicht mehr, ich musste ein neues Konto erstellen und alle meine Chats sind weg.
A: Dieses Problem tritt typischerweise auf, wenn ein Docker-Container ohne das Mounten eines Volumes für /app/backend/data erstellt wird oder wenn das dafür vorgesehene Open WebUI-Volume (in unseren Beispielen normalerweise open-webui genannt) versehentlich gelöscht wurde. Docker-Volumes sind entscheidend für die Persistenz Ihrer Daten über den Lebenszyklus des Containers hinaus. Wenn Sie nach einem Neustart ein neues Konto erstellen müssen, haben Sie wahrscheinlich einen neuen Container gestartet, ohne das vorhandene Volume anzuhängen, in dem sich Ihre Daten befinden. Stellen Sie sicher, dass Ihr Docker-Befehl eine Volume-Einbindung enthält, die auf den richtigen Datenspeicherort verweist, um Datenverlust zu vermeiden.
F: Ich habe versucht, mich anzumelden und konnte nicht, habe ein neues Konto erstellt und jetzt wird mir gesagt, dass mein Konto von einem Administrator aktiviert werden muss.
A: Diese Situation tritt auf, wenn Sie das Passwort für das ursprüngliche Admin-Konto vergessen haben, das während der ersten Einrichtung erstellt wurde. Das erste Konto wird automatisch als Admin-KontoDesigniert. Das Erstellen eines neuen Kontos ohne Zugriff auf das Admin-Konto führt dazu, dass eine Admin-Aktivierung erforderlich ist. Die Vermeidung des Verlusts der Anmeldeinformationen des ursprünglichen Admin-Kontos ist entscheidend für nahtlosen Zugriff und Verwaltung von Open WebUI. Siehe die Anleitung zum Zurücksetzen des Admin-Passworts für Anweisungen zur Wiederherstellung des Admin-Kontos.
F: Warum kann Open WebUI nicht mit einem SSL-Fehler starten?
A: Das SSL-Fehler, das Sie beim Starten von Open WebUI erhalten, ist wahrscheinlich auf das Fehlen von SSL-Zertifikaten oder eine falsche Konfiguration von huggingface.co zurückzuführen. Um dieses Problem zu beheben, könnten Sie einen Spiegel für HuggingFace einrichten, z. B. hf-mirror.com, und diesen als Endpunkt angeben, wenn Sie den Docker-Container starten. Verwenden Sie den Parameter -e HF_ENDPOINT=https://hf-mirror.com/, um die HuggingFace-Spiegeladresse im Docker-Ausführungsbefehl zu definieren. Sie können den Docker-Ausführungsbefehl beispielsweise wie folgt ändern
docker run -d -p 3000:8080 -e HF_ENDPOINT=https://hf-mirror.com/ --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
F: RAG mit Open WebUI ist sehr schlecht oder funktioniert überhaupt nicht. Warum?
A: Wenn Sie Ollama verwenden, beachten Sie, dass Ollama die Kontextlänge standardmäßig auf 2048 Tokens setzt. Das bedeutet, dass möglicherweise keine der abgerufenen Daten verwendet wird, da sie nicht in das verfügbare Kontextfenster passen.
Um die Leistung von Retrieval-Augmented Generation (RAG) mit Open WebUI zu verbessern, sollten Sie die Kontextlänge auf einen viel größeren Wert (8192+ Tokens) erhöhen, um sicherzustellen, dass abgerufene Dokumente effektiv zu den Antworten des Modells beitragen können.
Konfigurieren Sie dazu Ihre Ollama Modellparameter, um ein größeres Kontextfenster zu ermöglichen. Sie können diese Einstellung direkt in Ihrem Chat oder auf der Modellbearbeitungsseite überprüfen und ändern, um die RAG-Erfahrung erheblich zu verbessern.
F: Wird MCP (Model Context Protocol) in Open WebUI unterstützt?
A: Ja, Open WebUI unterstützt MCP Tool Server offiziell – aber ausschließlich über einen OpenAPI-konformen Proxy (openapi-servers) für optimale Kompatibilität, Sicherheit und Wartbarkeit.
Um MCP (und andere Backend-Protokolle) zu überbrücken, stellen wir eine speziell entwickelte Proxy-Implementierung zur Verfügung unter: 👉 https://github.com/open-webui/mcpo
Diese Designentscheidung wird durch mehrere Kernprinzipien motiviert:
- 📘 Standards-First: OpenAPI ist der De-facto-Standard für RESTful-Service-Definitionen und vertragsgesteuerte Service-Interoperabilität. Durch die Abstimmung von Integrationen über OpenAPI ermöglichen wir reproduzierbares, schema-gesteuertes Verhalten über Upgrades und Bereitstellungen hinweg.
- 🔒 Isolation des Sicherheitsmodells: Die Integration von MCP über einen Proxy ermöglicht es uns, das Verhalten von Backend-Protokollen zu isolieren und zu sandkasten, um die Angriffsfläche zu reduzieren und Audits, Authentifizierung und Beobachtbarkeit auf Grenzwertebene zu ermöglichen.
- ⚙️ Protokollabstraktion: Die Unterstützung heterogener Backends (z. B. MCP) über ein einheitliches OpenAPI-Schema ermöglicht es Open WebUI, backend-agnostisch zu bleiben und gleichzeitig ein vorhersehbares Laufzeitverhalten aufrechtzuerhalten.
- ⛓️ Entkoppelte Bereitstellungstopologie: Die Proxy-basierte Architektur ermöglicht es Tool-Servern (wie MCP), sich unabhängig von der Frontend-Präsentation zu entwickeln, was hochmodulare Produktionsumgebungen oder verteilte Workloads ermöglicht.
Zusammenfassend: MCP wird unterstützt – solange der MCP Tool Server von einem OpenAPI-kompatiblen Proxy bedient wird. Diese architektonische Entscheidung ist bewusst und stellt sicher, dass Open WebUI skalierbar, sicher und wartbar bleibt.
F: Wie oft wird Open WebUI aktualisiert? (Release-Zeitplan)
A: Wir streben wöchentliche Hauptversionen an, mit Fehlerbehebungen und kleineren Updates nach Bedarf. Dies ist jedoch kein starrer Zeitplan – einige Wochen können mehrere Veröffentlichungen sehen, während andere überhaupt keine haben.
Um informiert zu bleiben, können Sie die Release Notes und Ankündigungen auf unserer GitHub Releases-Seite verfolgen.
Weitere Hilfe benötigt?
Wenn Sie weitere Fragen oder Bedenken haben, wenden Sie sich bitte an unsere GitHub Issues-Seite oder unseren Discord-Kanal, um weitere Hilfe und Informationen zu erhalten.