Open-WebUI-Alternativen für einen VPS im Vergleich

Welche Open WebUI-Alternative gehört auf einen VPS

Alternativen zu Open WebUI werden fast immer auf Laptops verglichen, wo RAM günstig ist und kein Dienst auf einer öffentlichen Adresse lauscht. Ein VPS ändert beide Fakten, was die Rangfolge verschiebt. Open WebUI bleibt die richtige Standardwahl, sobald sich eine zweite Person anmeldet, da es echte Benutzerkonten und ein Admin-Panel mitliefert. Die schlankeren Projekte gewinnen, wenn das Interface mit dem Modell um das letzte Gigabyte RAM konkurriert. Der Preis für diesen Gewinn ist die Authentifizierung: Diese ist nicht vorhanden.

Alles Folgende stammt aus der Dokumentation der jeweiligen Projekte, gelesen im August 2026, erneut geprüft am 20. Oktober 2026 und für Open WebUI, LibreChat, Hollama sowie OrionChat nochmals am 25. Oktober 2026 validiert. Die Dokumentation von Ollama und die Sicherheitsregeln der Browser wurden am 29. Oktober 2026 erneut überprüft. Die vier Achsen sind diejenigen, die erst relevant werden, sobald der Server aus dem Internet erreichbar ist.

Vier Achsen, die nur bei einer öffentlichen IP-Adresse relevant sind

• Speicher neben dem Modell. Der Model-Server ist der teuerste Prozess auf dem System. Jedes Megabyte, das die Benutzeroberfläche belegt, steht dem Modell nicht zur Verfügung.
• Authentifizierung. Einige dieser Projekte bieten Benutzerkonten und Rollen. Andere gehen davon aus, dass sie die einzige Anwendung auf Ihrem Laptop sind, und haben überhaupt keine Anmeldung.
• Remote-Inferenz. Eine Benutzeroberfläche, die ausschließlich auf 127.0.0.1:11434 zeigt, erwartet das Modell auf demselben System wie die Benutzeroberfläche. Wenn sich das Modell an einem anderen Ort befindet, ist daher ein Tunnel erforderlich, der diesen lokalen Port an den Host des Modells weiterleitet.
• Wartungsaufwand. Ein Container mit einer SQLite-Datei ist eine andere Aufgabe als sechs Container mit MongoDB und einer dahinterliegenden Vektordatenbank.

Wie viel RAM bleibt dem Modell für die Benutzeroberfläche

Die Benutzeroberfläche ist nicht der größte Verbraucher auf dem Server. Das Modell ist es. Veröffentlichtte Download-Größen geben die Untergrenze an, weil die Gewichte während der Antworten im Speicher bleiben müssen. Der tatsächliche Speicherbedarf liegt höher als die Download-Größe, sobald der Kontext-Cache zugewiesen wurde.

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.4"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

Das sind die Werte, die auf den Ollama-Bibliotheksseiten am 25 October 2026 angegeben waren. Es handelt sich um veröffentlichte Größen, nicht um Messwerte. Auf einer 4 GB VPS lässt qwen3:4b bei 2.5 GB weniger als 1.5 GB für das Betriebssystem und alles Weitere übrig. Der Kontext-Cache verringert diesen freien Speicher weiter, wenn eine Unterhaltung wächst. Deshalb ist der von Ihnen festgelegte num_ctx ebenso eine Speicherentscheidung wie eine Qualitätsentscheidung. qwen3:8b mit 5.2 GB passt überhaupt nicht auf diesen Server. Diese Situation wird in Laptop-Übersichten nie behandelt. Hier entscheidet eine Chat-Benutzeroberfläche, die einige hundert Megabyte belegt, ob das Modell ausgeführt werden kann. Wenn Sie einen Server für deutlich größere Modelle als diese Tags dimensionieren, zeigt die Berechnung für ein 27B-Modell auf einer CPU-only VPS, wie schnell die Benutzeroberfläche nicht mehr der entscheidende Wert ist.

Messen Sie den Speicherbedarf, statt einer Zahl aus einer Übersicht zu vertrauen, auch dieser hier nicht. Führen Sie docker stats --no-stream eine Stunde unter realer Last aus, nicht eine Minute nach dem Start des Containers. Der relevante Speicher wird erst bei der ersten Verwendung zugewiesen. Ollama gibt die Gewichte außerdem nach fünf Minuten ohne Aktivität frei. Eine Messung zwischen zwei Unterhaltungen unterschätzt daher den Spitzenwert. Die nächste Nachricht muss die Gewichte erneut vollständig laden, sofern Sie das Modell nicht mit keep_alive im Speicher halten.

Open WebUI: weiterhin die Standardwahl für mehrere Benutzer

Open WebUI läuft aus einem Image und speichert seine Daten in einem Volume.

docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Der Befehl in der Projekt-README veröffentlicht -p 3000:8080, das auf allen Schnittstellen lauscht. Das Präfix 127.0.0.1: beschränkt den Dienst auf das Loopback-Interface. Auf einem VPS ist dieses Präfix wichtiger als alles andere in der Zeile, weil Docker eigene iptables-Regeln schreibt und ein veröffentlichter Port Ihre ufw-Deny-Regeln ignoriert.

Rufen Sie die Seite über einen Tunnel oder einen Proxy auf. Beide Varianten werden weiter unten beschrieben. Erstellen Sie anschließend das erste Konto. Dieses Konto wird zum Administrator. Die Registrierung wird danach automatisch deaktiviert, bis ein Administrator New Sign Ups wieder aktiviert. Spätere Konten werden mit der Rolle pending angelegt, dem dokumentierten Standardwert DEFAULT_USER_ROLE. Ein Fremder, der die Seite erreicht, kann Ihr Modell daher erst verwenden, nachdem ein Administrator ihn freigibt.

Open WebUI benötigt mehr Arbeitsspeicher als die unten genannten Projekte, weil es mehr Funktionen bietet. Die eigene Performance-Seite nennt die Komponenten, die dafür verantwortlich sind. Die standardmäßige Embedding-Engine lädt ein sentence-transformers-Modell in den Container. Dafür sind pro Worker-Prozess laut Dokumentation etwa 500 MB oder mehr erforderlich. Mit RAG_EMBEDDING_ENGINE=ollama übergeben Sie diese Aufgabe an den Model-Server, den Sie bereits betreiben. AUDIO_STT_ENGINE=webapi verhindert, dass ein lokales Speech-to-Text-Modell geladen wird. Wenn DATABASE_POOL_SIZE bei SQLite nicht gesetzt ist, verwendet der Pool eine große interne Standardgröße. Jede Verbindung legt dann ihren eigenen Page-Cache und ihr eigenes Memory-Mapping an. Setzen Sie auf einem kleinen System daher DATABASE_POOL_SIZE=8 und DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. Autocomplete fragt das Modell nach einer Vervollständigung, während ein Benutzer noch tippt. Diese Funktion ist inzwischen standardmäßig deaktiviert (ENABLE_AUTOCOMPLETE_GENERATION verwendet standardmäßig False). Lassen Sie sie auf einem kleinen System deaktiviert.

LibreChat: mehrere Benutzer mit einem Stack dahinter

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

Die Oberfläche ist auf Port 3080 erreichbar. LibreChat ist die passende Wahl, wenn Sie ein Identitätssystem statt eines einfachen Anmeldefelds benötigen: Die Dokumentation beschreibt LDAP- und OAuth2-Anmeldungen, und die standardmäßige Compose-Datei definiert außerdem ein Administrationspanel für Benutzer, Gruppen und Rollen. Das Panel läuft nicht sofort. Es startet erst, wenn ADMIN_PANEL_SESSION_SECRET in .env gesetzt ist. Dieser erforderliche Wert muss mindestens 32 Zeichen lang sein und hat keinen Standardwert. Erzeugen Sie bei Bedarf einen Wert mit openssl rand -hex 32. Das Panel läuft als eigener Dienst und nicht innerhalb des LibreChat-Prozesses. Es benötigt LibreChat v0.8.5 oder höher, und das Projekt kennzeichnet es weiterhin als Vorschau. Diese Funktion wird zusammen mit einem Stack bereitgestellt.

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 5,
    "notes": "api, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

Die standardmäßige Compose-Datei startet 5 Dienste: api, MongoDB, Meilisearch, pgvector, RAG API. Ein sechster Dienst, das Administrationspanel, befindet sich in derselben Datei und wird nach dem Setzen des Secrets ebenfalls gestartet. Keiner dieser Dienste ist das Modell. MongoDB und pgvector benötigen jeweils eigenen Arbeitsspeicher. Auf einem System mit 4 GB fehlt dieser Speicher dem Modell.

Zwei Dienste in der Datei veröffentlichen Ports. Keine der Zuordnungen nennt eine Bind-Adresse: die API auf 3080 und das Administrationspanel auf dem Host-Port 3000, dem Standardwert von ADMIN_PANEL_PORT. Beide Dienste lauschen daher nach dem Start auf allen Schnittstellen. Port 3000 wird außerdem von Open WebUI verwendet. Auf einem gemeinsamen System kollidieren die beiden Dienste daher, sobald das Panel aktiviert wird. Ändern Sie beide Bindings vor dem Internetbetrieb in 127.0.0.1 in docker-compose.override.yml.

Upgrades erfolgen als git-Vorgang. Genau dabei treten häufig Fehler auf.

docker compose down
git pull
docker compose pull
docker compose up -d

git pull bricht bei einem Konflikt ab, wenn Sie die versionierte docker-compose.yml bearbeitet haben. Das Upgrade ist dann nur teilweise angewendet. Legen Sie Ihre Änderungen stattdessen in docker-compose.override.yml ab. Das Projekt stellt diese Datei genau dafür bereit. Bewahren Sie Secrets in .env auf. Beide Dateien sind nicht versioniert, daher lässt git pull sie unverändert.

Verweisen Sie mit einem benutzerdefinierten Endpoint in librechat.yaml auf Ihren eigenen Model-Server.

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

Ersetzen Sie model-host durch die Adresse des Systems, auf dem Ollama läuft. Das Feld apiKey muss vorhanden sein, obwohl Ollama seinen Wert ignoriert. Ein Platzhalter ist daher ausreichend. Wenn LibreChat in Docker und Ollama auf demselben System laufen, bezeichnet localhost innerhalb des Containers den Container selbst. Verwenden Sie dort stattdessen host.docker.internal.

Hollama und OrionChat: Der Browser erledigt die Arbeit

Hollama stellt eine Browser-Anwendung aus einem kleinen Container bereit. Chats werden im Speicher Ihres Browsers abgelegt, nicht auf dem Server.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

Die README-Version dieses Befehls verwendet --rm, wodurch der Container beim Stoppen gelöscht wird. Die Oberfläche ist daher nach einem Neustart nicht mehr verfügbar.

OrionChat geht noch weiter und besitzt überhaupt keine Server-Komponente. Klonen Sie das Repository und stellen Sie den Ordner über Ihren bestehenden Webserver bereit oder öffnen Sie index.html direkt von der Festplatte. API-Schlüssel werden im localStorage des Browsers gespeichert, der Chat-Verlauf verbleibt im Browser und die Anwendung löscht die ältesten Chats, sobald die Anzahl 512 überschreitet. Die Ollama-Adresse von OrionChat ist im Quellcode (js/script.js) fest auf http://localhost:11434 eingestellt; die Einstellungen bieten kein Feld, um dies zu ändern.

Keines der Projekte verfügt über eine Anmeldefunktion. Auf einem Laptop ist das unproblematisch. Auf einem VPS bedeutet dies, dass die Seite niemals unter 0.0.0.0 veröffentlicht werden darf. Zudem ergibt sich ein leicht zu übersehender Punkt: Der Browser ruft das Modell auf, nicht der Server.

Diese Tatsache entscheidet über den Einsatzbereich beider Projekte. Ihr Browser muss Ollama direkt erreichen können. Für OrionChat bedeutet dies immer localhost:11434 auf dem Rechner, auf dem der Browser läuft; auf einem VPS ist der unten genannte SSH-Tunnel daher der einzige Weg zum Modell. Hollama akzeptiert jede Adresse, die Sie als Basis-URL für die Verbindung eingeben, und die Anleitung zum Self-Hosting deckt auch einen Ollama-Server auf einem anderen Gerät ab: Fügen Sie den Ursprung von Hollama zu OLLAMA_ORIGINS auf der Ollama-Seite hinzu. Sofern Sie den Port nicht per SSH weiterleiten, muss Ollama auf mehr als nur dem Loopback-Interface lauschen, und die Ollama-API verlangt weder eine Anmeldung noch einen Schlüssel. Daraus ergeben sich zwei Browser-Regeln. Eine über HTTPS bereitgestellte Seite kann keinen einfachen HTTP-Endpunkt unter einer öffentlichen IP-Adresse aufrufen, und die Konsole gibt Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked. aus. Loopback genießt eine gesonderte Ausnahme: Die Mixed-Content-Spezifikation blockiert nur URLs, die nicht als potenziell vertrauenswürdig gelten, und die Secure-Contexts-Spezifikation stuft localhost, 127.0.0.0/8 sowie ::1 als potenziell vertrauenswürdig ein. Daher kann dieselbe HTTPS-Seite http://localhost:11434 oder http://127.0.0.1:11434 aufrufen. Auf dieser Ausnahme basiert der unten genannte SSH-Tunnel. Seit Version 142 fügt Chrome einen Schritt hinzu, wenn die Seite von einer öffentlichen Website wie https://chat.example.com stammt: Eine Anfrage von dort an eine Loopback- oder lokale Netzwerkadresse wartet, bis der Benutzer den Zugriff auf das lokale Netzwerk in einer Berechtigungsaufforderung erlaubt. Chrome nimmt zudem HTTP-Anfragen an Endpunkte im lokalen Netzwerk von der Mixed-Content-Prüfung aus, sofern diese durch eine Berechtigung geschützt sind und der Hostname ein privates IP-Literal wie 192.168.0.1, ein .local-Name ist oder der Fetch-Befehl targetAddressSpace: "local" spezifiziert. Eine Seite, die Sie über den Tunnel unter http://localhost öffnen, befindet sich bereits auf dem Loopback-Interface, weshalb diese Aufforderung dort nicht greift. Ein Aufruf an einen anderen Ursprung wird mit has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource verweigert, bis Sie diesen Ursprung explizit erlauben.

Der dokumentierte Weg von Ollama, eine dieser Einstellungen zu ändern, ist ein systemd-Override.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

ss sollte nun 0.0.0.0:11434 ausgeben, wo zuvor 127.0.0.1:11434 stand. Nehmen Sie diese Änderung nur vor, wenn eine Firewall oder ein authentifizierender Proxy bereits kontrolliert, wer den Port erreichen kann, da ein offener Port 11434 einen offenen Modell-Server bedeutet und Massenscanner einen neuen öffentlichen Port schnell finden. Der unten genannte SSH-Tunnel umgeht diese Problematik vollständig: Die Seite läuft dann unter einem localhost-Ursprung, den Ollama standardmäßig zulässt, und der Port verlässt zu keinem Zeitpunkt den Rechner.

Kann jede Anwendung einen entfernten Ollama- oder vLLM-Endpunkt verwenden

Open WebUI kann das, und die Verbindung wird serverseitig hergestellt. OLLAMA_BASE_URL=http://model-host:11434 verweist auf Ollama. Für vLLM setzen Sie OPENAI_API_BASE_URL=http://model-host:8000/v1 und belassen /v1, unter dem vLLM seine API bereitstellt. Setzen Sie OPENAI_API_KEY nur, wenn der Server mit einem Schlüssel gestartet wurde, da die vLLM-Anleitung von Open WebUI ansonsten keine Authentifizierung verwendet. Andere OpenAI-kompatible Server verwenden den Basispfad aus ihrer eigenen Dokumentation; das ist nicht immer /v1. OPENAI_API_BASE_URLS akzeptiert mehrere Backends, die durch Semikolons getrennt werden.

LibreChat kann das über baseURL des oben gezeigten benutzerdefinierten Endpunkts. Diese Anfrage verlässt ebenfalls den Server, daher gilt keine Browser-Regel. Dieselbe Basis-URL und derselbe Platzhalter-Schlüssel funktionieren auch außerhalb eines Chatfensters. Damit können Sie einen Coding-Agent auf das bereits von Ihnen gehostete Modell verweisen.

Hollama kann auf jeden Endpunkt verweisen, den Sie in den Einstellungen eingeben. Die Ollama-Verbindung hat eine bearbeitbare Basis-URL, die standardmäßig auf http://localhost:11434 gesetzt ist. Zusätzlich bietet Hollama eine OpenAI-kompatible Verbindung, standardmäßig http://localhost:8080/v1. Das ist der Weg zu vLLM. Die Anfrage verlässt Ihren Browser, daher gilt alles aus dem vorherigen Abschnitt auch hier. OrionChat kann auf keinen anderen Endpunkt verweisen. Seine Endpunkte sind fest kodiert. Ollama ist fest auf http://localhost:11434/v1/chat/completions gesetzt. Die README-Datei besagt, dass Anfragen direkt an die offizielle API des jeweiligen Anbieters gesendet werden. Ein entferntes Ollama ist nur über einen SSH-Tunnel erreichbar, der es an diesem lokalen Port antworten lässt. Für einen vLLM-Server gibt es überhaupt keine Einstellung.

Die Trennung von Benutzeroberfläche und Modell ist der wichtigste Vorteil eines entfernten Endpunkts. Platzieren Sie die Benutzeroberfläche auf einem kleinen System und das Modell dort, wo der Arbeitsspeicher verfügbar ist. An dieser Stelle sollten Sie auch entscheiden, ob Ollama oder vLLM die Anfragen verarbeiten soll, da sich beide unterschiedlich verhalten, sobald mehrere Personen gleichzeitig mit dem Modell arbeiten. Wenn der Modellserver noch nicht vorhanden ist, beginnen Sie mit dem Betrieb von Ollama auf einem VPS. Auf einem System ohne GPU lesen Sie außerdem wie Ollama im Vergleich zu llama.cpp abschneidet, bevor Sie sich für eine Runtime entscheiden.

Kein Chat-UI ohne Login auf 0.0.0.0 veröffentlichen

Auf der Hardening-Seite von Open WebUI steht, dass das Projekt „für private, vertrauenswürdige Netzwerke entwickelt wurde, ähnlich wie andere selbst gehostete Infrastruktur wie Datenbanken, Container-Registries und CI-Server“. Außerdem wird empfohlen, es hinter einem VPN oder hinter einem Reverse Proxy mit Authentifizierung zu betreiben. Ein Projekt ganz ohne Login verdient mindestens denselben Schutz.

Prüfen Sie, welche Dienste lauschen, bevor Sie einer dieser Komponenten vertrauen.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

Eine Zeile mit 127.0.0.1:3000 ist das gewünschte Ergebnis. Eine Zeile mit 0.0.0.0:3000 bedeutet, dass der Dienst auf allen Adressen lauscht. Docker lässt standardmäßig jede externe Quell-IP einen veröffentlichten Port erreichen. Sofern keine Regel in der DOCKER-USER-Kette von Docker oder in der Firewall Ihres Providers den Zugriff blockiert, ist Ihre Chat-Oberfläche im öffentlichen Internet erreichbar. Auf Ihrem eigenen Rechner beantwortet curl -sI http://YOUR.VPS.IP:3000 mit HTTP/1.1 200 OK die Frage noch eindeutiger.

Open WebUIs Login mit WEBUI_AUTH=False zu deaktivieren, ist eine Einstellung für einen einzelnen Benutzer auf einem Rechner, den niemand sonst erreichen kann. In der Dokumentation steht außerdem, dass dies nur bei einer Installation ohne registrierte Benutzer funktioniert. Sie können die Einstellung daher nicht auf eine Installation mit bereits vorhandenen Konten anwenden.

Muster eins: An Loopback binden und über SSH darauf zugreifen. Veröffentlichen Sie jeden Port auf 127.0.0.1. Leiten Sie anschließend den benötigten Port weiter: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, und öffnen Sie http://localhost:3000 auf Ihrem Laptop. Es wird kein Port veröffentlicht, daher kann auch kein Port gescannt werden. Bei OrionChat leiten Sie den Modell-Port mit -L 11434:127.0.0.1:11434 im selben Befehl weiter und lassen Ollama auf Loopback lauschen. Hollama kann Ollama direkt erreichen. Durch dieselbe Weiterleitung bleibt Ollama jedoch ebenfalls vom öffentlichen Internet getrennt. Daher ist dies auch für Hollama der sicherere Weg. Die Sicherheit dieses Musters hängt vollständig von Ihrer SSH-Konfiguration ab. Kombinieren Sie es daher mit SSH nur mit Schlüsseln und einem gehärteten sshd.

Muster zwei: Ein Reverse Proxy authentifiziert die Anfrage, bevor die Anwendung sie erhält. Lassen Sie die Anwendung auf Loopback lauschen. Lassen Sie den Proxy Port 443 übernehmen und schalten Sie Single Sign-On davor. Traefik mit Docker-Compose-Labels und Authentik als Identity Provider stellen jeder Anwendung auf dem Server einen gemeinsamen Login und ein gemeinsames Zertifikat bereit. Wenn Open WebUI hinter TLS (Transport Layer Security) betrieben wird, setzen Sie WEBUI_SESSION_COOKIE_SECURE=true und WEBUI_SESSION_COOKIE_SAME_SITE=strict. Verkürzen Sie außerdem JWT_EXPIRES_IN gegenüber dem Standardwert von vier Wochen. Open WebUI dokumentiert, dass eine Abmeldung ohne Redis das Token nicht ungültig macht. Es bleibt verwendbar, bis es selbstständig abläuft.

Muster zwei schützt die Projekte, die nur im Browser funktionieren, nicht. Ein Proxy vor der Seite schützt den Modell-Endpunkt nicht. Ein Abruf von dieser Seite zu einem anderen Hostnamen überträgt Ihr Session-Cookie nicht. Deshalb antwortet der authentifizierende Proxy vor Ollama mit einer Weiterleitung zu einem Login-Formular, und der Chat schlägt fehl. Routen Sie den Modell-Endpunkt entweder unter demselben Hostnamen wie die Seite oder verwenden Sie Muster eins.

Welche Variante Sie wählen sollten

Wenn außer Ihnen noch jemand den Dienst verwendet, setzen Sie Open WebUI ein. Es bietet echte Benutzerkonten. Neue Benutzer landen zunächst in einer Freigabewarteschlange. Die Maintainer veröffentlichen außerdem Anleitungen zur Absicherung, an denen Sie sich orientieren können. Wenn Sie LDAP oder ein Administrationspanel benötigen, setzen Sie LibreChat ein. Aktivieren Sie das Panel mit ADMIN_PANEL_SESSION_SECRET, wenn Sie es benötigen. Prüfen Sie mit docker stats, ob die fünf Dienste beziehungsweise mit Panel sechs Dienste zusammen mit Ihrem Modell tatsächlich in den verfügbaren Arbeitsspeicher passen, bevor Sie sich darauf verlassen. Wenn nur eine Person den Dienst auf einem kleinen System verwendet und das Modell bereits den größten Teil des Arbeitsspeichers belegt, stellen Sie Hollama oder OrionChat über einen SSH-Tunnel bereit. Lassen Sie den Browser den Zustand verwalten. Auf einem VPS ist es in jedem Fall falsch, eine dieser Anwendungen ohne vorgeschaltete Anmeldung auf 0.0.0.0 zu veröffentlichen.

FAQ

Ist es sicher, Open WebUI direkt über eine öffentliche IP-Adresse bereitzustellen?

Die eigene Hardening-Seite beschreibt die Software als Anwendung für private, vertrauenswürdige Netzwerke, vergleichbar mit einer Datenbank oder einem CI-Server. Sie verfügt über echte Benutzerkonten, wobei das erste Konto zum Administrator wird und spätere Konten den Status pending behalten, bis sie freigegeben werden; damit ist sie deutlich sicherer als eine Benutzeroberfläche ohne Login. Dennoch sollte sie hinter einem Reverse Proxy mit TLS und, sofern möglich, Single Sign-On betrieben werden. Veröffentlichen Sie den Container-Port als 127.0.0.1:3000:8080, damit die Docker-eigenen iptables-Regeln ihn nicht unbemerkt für das Internet öffnen.

Welche Open WebUI-Alternative verbraucht auf einem VPS am wenigsten RAM?

Die browserbasierten Lösungen Hollama und OrionChat, da die Anwendung auf dem Client ausgeführt wird. Der Server liefert lediglich statische Dateien aus, und OrionChat benötigt gar keinen Anwendungs-Container. Open WebUI hält einen Python-Prozess, eine Datenbank und standardmäßig ein lokales Embedding-Modell im Arbeitsspeicher, was laut Dokumentation allein für das Embedding-Modell etwa 500 MB oder mehr pro Worker beansprucht. Überprüfen Sie die Werte auf Ihrem eigenen System mit docker stats --no-stream, da sie sich je nach aktivierten Funktionen ändern.

Können diese Chat-UIs einen Ollama-Server auf einem anderen Host nutzen?

Open WebUI und LibreChat können dies, da ihr Server die Verbindung herstellt und somit keine Browser-Regeln greifen. Setzen Sie OLLAMA_BASE_URL für Open WebUI oder baseURL in einem benutzerdefinierten Endpunkt für LibreChat. Für vLLM oder einen anderen OpenAI-kompatiblen Server verwenden Sie OPENAI_API_BASE_URL mit dem in der Dokumentation des Servers angegebenen Basispfad, der für vLLM /v1 lautet, und fügen Sie nur dann einen API-Key hinzu, wenn der Server diesen erfordert. Hollama kann ebenfalls auf beliebige Ziele verweisen, jedoch erfolgt die Anfrage durch Ihren Browser, weshalb der Endpunkt auch von Ihrem Browser aus erreichbar sein muss. OrionChat kann dies nicht: Die Ollama-Adresse ist fest auf http://localhost:11434 kodiert, sodass ein entferntes Ollama nur über einen SSH-Tunnel funktioniert, der diesen Port weiterleitet.

Warum kann meine Browser-Chat-UI Ollama nicht erreichen?

Zwei Ursachen decken fast alle Fälle ab. Ollama bindet standardmäßig 127.0.0.1:11434, sodass ein Browser auf einem anderen Rechner es nicht direkt erreichen kann, bis OLLAMA_HOST geändert oder der Port per SSH-Tunnel weitergeleitet wird. Zudem akzeptiert Ollama standardmäßig Cross-Origin-Anfragen von localhost, 127.0.0.1 und 0.0.0.0, weshalb eine von Ihrer eigenen Domain bereitgestellte Seite mit No 'Access-Control-Allow-Origin' header is present on the requested resource abgelehnt wird, bis dieser Ursprung in OLLAMA_ORIGINS aufgeführt ist. Wenn die Seite HTTPS verwendet und der Endpunkt unverschlüsseltes HTTP auf einer öffentlichen IP-Adresse ist, blockiert der Browser den Aufruf als Mixed Content, bevor Ollama ihn überhaupt empfängt. Loopback-Adressen (localhost, jede Adresse in 127.0.0.0/8 wie 127.0.0.2 oder [::1]) sind davon ausgenommen. Chrome nimmt zudem HTTP-Anfragen an Endpunkte im lokalen Netzwerk von der Mixed-Content-Prüfung aus, wenn diese Anfragen durch eine Berechtigung für das lokale Netzwerk geschützt sind und private IP-Literale wie 192.168.0.1, .local-Hostnamen oder targetAddressSpace: "local" verwendet werden; die CORS-Anforderungen von Ollama gelten jedoch weiterhin. Setzen Sie beide Variablen in einer systemctl edit ollama.service-Überschreibung oder leiten Sie den Port über SSH weiter, um das Problem zu beheben.