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

Welche Open-WebUI-Alternative eignet sich für einen VPS

Open-WebUI-Alternativen werden fast immer auf einem Laptop verglichen, auf dem RAM günstig ist und kein Dienst an einer öffentlichen Adresse lauscht. Ein VPS ändert beide Bedingungen. Dadurch ändert sich auch die Rangfolge. Open WebUI bleibt die richtige Standardwahl, sobald sich eine zweite Person anmeldet, weil es echte Benutzerkonten und ein Administrationspanel bereitstellt. Die schlankeren Projekte gewinnen, wenn die Benutzeroberfläche mit dem Modell um das letzte Gigabyte RAM konkurriert. Der Preis für diesen Vorteil ist die Authentifizierung: Sie bieten keine.

Alle folgenden Angaben stammen aus der jeweiligen Projektdokumentation und wurden im August 2026 ermittelt. Die vier Kriterien sind erst relevant, sobald der Server aus dem Internet erreichbar ist.

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

• Speicher neben dem Modell. Der Model-Server ist der ressourcenintensive Prozess auf dem System. Jedes Megabyte, das die Oberflä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 bieten überhaupt keine Anmeldung.
• Remote-Inferenz. Eine Oberfläche, die nur 127.0.0.1:11434 erreichen kann, erzwingt, dass das Modell auf demselben System wie die Oberfläche läuft.
• 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 Oberfläche

Die Oberfläche ist nicht der größte Speicherverbraucher auf dem Server. Das Modell ist es. Die veröffentlichten Downloadgrößen geben die Untergrenze vor, weil die Gewichte während der Antworten im Speicher resident sein müssen. Der tatsächliche Speicherbedarf ist höher als die Downloadgröße, sobald der Kontext-Cache angelegt wurde.

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

Dies sind die Werte, die auf den Ollama-Bibliotheksseiten im August 2026 angegeben waren. Es handelt sich um veröffentlichte Größen, nicht um Messwerte. Auf einem 4-GB-VPS lässt qwen3:4b mit 2.5 GB weniger als 1,5 GB für das Betriebssystem und alle anderen Prozesse übrig. Mit wachsender Unterhaltung belegt der Kontext-Cache zusätzlich Speicher. qwen3:8b mit 5.2 GB passt auf diesen Server überhaupt nicht. Genau diese Situation wird in Laptop-Vergleichen nie behandelt. Hier entscheidet eine Chat-Oberfläche, die einige hundert Megabyte belegt, darüber, ob das Modell ausgeführt werden kann.

Verlassen Sie sich auf keine Zahl aus einem Vergleich, auch nicht auf diese. Führen Sie docker stats --no-stream erst nach einer Stunde realer Nutzung aus, nicht eine Minute nach dem Start des Containers. Der relevante Speicher wird erst bei der ersten Verwendung zugewiesen.

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 README des Projekts veröffentlicht -p 3000:8080, das auf allen Schnittstellen lauscht. Das Präfix 127.0.0.1: bindet den Dienst an 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 erhält die Administratorrolle. Spätere Registrierungen werden mit der Rolle pending angelegt, dem dokumentierten Standardwert DEFAULT_USER_ROLE. Eine fremde Person, die die Seite erreicht, kann Ihr Modell daher erst verwenden, nachdem ein Administrator sie freigeschaltet hat.

Open WebUI benötigt mehr Arbeitsspeicher als die folgenden Projekte, weil es mehr Funktionen bietet. Auf der eigenen Performance-Seite nennt das Projekt die dafür verantwortlichen Komponenten. Die standardmäßige Embedding-Engine lädt ein sentence-transformers-Modell innerhalb des Containers. Laut Dokumentation sind dafür etwa 500 MB pro Worker-Prozess 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. Bei SQLite fällt der Verbindungspool zurück auf eine große interne Größe, wenn DATABASE_POOL_SIZE nicht gesetzt ist. Jede Verbindung vergrößert dann ihren eigenen Page Cache und ihr eigenes Memory Mapping. Setzen Sie daher auf einem kleinen System DATABASE_POOL_SIZE=8 und DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False verhindert, dass die Oberfläche das Modell während der Eingabe eines Benutzers nach einer Vervollständigung fragt.

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 über Port 3080 erreichbar. LibreChat ist die richtige Wahl, wenn Sie ein Identitätssystem statt eines einfachen Anmeldeformulars benötigen: Die Dokumentation beschreibt Anmeldungen über LDAP und OAuth2. Außerdem enthält LibreChat ein Administrationspanel für Benutzer und Rollen. Diese Funktionen erfordern einen Stack.

[
  {
    "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": 6,
    "notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

Die standardmäßige Compose-Datei startet 6 Dienste: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Keiner davon ist das Modell. MongoDB und pgvector benötigen jeweils eigenen Arbeitsspeicher. Auf einem System mit 4 GB fehlt dieser Speicher dann dem Modell.

Upgrades erfolgen über Git. Genau dabei passieren häufig Fehler.

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

git pull bricht mit einem Konflikt ab, wenn Sie die versionierte Datei 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. Speichern Sie Geheimnisse in .env. Beide Dateien sind nicht versioniert. git pull lässt sie daher unverändert.

Verweisen Sie in librechat.yaml über einen benutzerdefinierten Endpunkt auf Ihren eigenen Modellserver.

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, auch wenn Ollama seinen Wert ignoriert. Ein Platzhalter ist daher ausreichend. Wenn LibreChat in Docker und Ollama auf demselben System laufen, verweist localhost innerhalb des Containers auf den Container selbst. Verwenden Sie dort stattdessen host.docker.internal.

Hollama und OrionChat: Der Browser übernimmt die Verarbeitung

Hollama stellt eine Browseranwendung 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 Version dieses Befehls aus der README verwendet --rm. Dadurch wird der Container beim Beenden gelöscht, und die Oberfläche ist nach einem Reboot nicht mehr verfügbar. Hinter einem Reverse Proxy müssen Sie -e VITE_ALLOWED_HOSTS='chat.example.com' ergänzen, weil das Image nur den Host localhost zulässt. Bei jedem anderen Hostnamen antwortet es mit einem Blocked-Host-Fehler statt mit der Anwendung.

OrionChat geht noch weiter und hat überhaupt keine Serverkomponente. Klonen Sie das Repository und stellen Sie das Verzeichnis mit dem Webserver bereit, den Sie bereits betreiben. Alternativ können Sie index.html von der Festplatte öffnen. API-Keys werden in localStorage des Browsers gespeichert. Der Chatverlauf bleibt im Browser. Die Anwendung löscht die ältesten Chats, sobald die Anzahl 512 überschreitet.

Keines der beiden Projekte verfügt über eine Anmeldung, weil kein Server vorhanden ist, der diese prüfen könnte. Auf einem Laptop ist das unproblematisch. Auf einem VPS darf die Seite daher niemals über 0.0.0.0 veröffentlicht werden. Außerdem gibt es einen leicht zu übersehenden Punkt: Der Browser ruft das Modell auf, nicht der Server.

Diese Tatsache entscheidet darüber, wo Sie die beiden Anwendungen einsetzen können. Ihr Browser muss Ollama direkt erreichen. Ollama muss deshalb nicht nur auf der Loopback-Adresse lauschen. Außerdem bietet Ollama keinerlei Authentifizierung. Daraus folgen zwei Browserregeln. Eine über HTTPS bereitgestellte Seite kann keinen HTTP-Endpunkt aufrufen. 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. Ein Aufruf an einen anderen Origin wird mit has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource abgelehnt, bis Sie diesen Origin zulassen.

Die dokumentierte Methode von Ollama, eine der beiden 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 jetzt 0.0.0.0:11434 ausgeben, obwohl zuvor 127.0.0.1:11434 ausgegeben wurde. Nehmen Sie diese Änderung nur vor, wenn bereits eine Firewall oder ein authentifizierender Proxy den Zugriff auf den Port kontrolliert. Ein offener Port 11434 bedeutet einen offenen Modelserver. Massenscanner erreichen einen neuen öffentlichen Port schnell. Der folgende SSH-Tunnel umgeht diese Frage vollständig: Die Seite läuft dann über einen localhost-Origin, den Ollama standardmäßig zulässt, und der Port verlässt das System nicht.

Kann jedes davon 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 oder einen anderen OpenAI-kompatiblen Server setzen Sie OPENAI_API_BASE_URL=http://model-host:8000/v1 mit einem nicht leeren OPENAI_API_KEY und behalten das Suffix /v1 bei, das erforderlich ist. OPENAI_API_BASE_URLS akzeptiert mehrere Backends, die durch Semikolons getrennt werden.

LibreChat kann dies über den baseURL des oben gezeigten benutzerdefinierten Endpunkts. Auch diese Anfrage verlässt den Server, daher gilt keine Browser-Regel.

Hollama und OrionChat können auf jeden Endpunkt verweisen, den Sie in ihren Einstellungen eingeben. Die Anfrage verlässt jedoch Ihren Browser. Alles im obigen Abschnitt gilt für diese beiden, aber für nichts anderes in diesem Abschnitt.

Die Trennung von Benutzeroberfläche und Modell ist der größte 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 sehr unterschiedlich verhalten, sobald mehrere Personen gleichzeitig mit dem Modell arbeiten. Wenn der Modellserver noch nicht vorhanden ist, beginnen Sie mit Ollama auf einem VPS ausführen. Auf einem System ohne GPU sollten Sie außerdem lesen, wie sich Ollama im Vergleich zu llama.cpp verhält, bevor Sie eine Laufzeit auswählen.

Keine Chat-Oberfläche 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 ohne jeglichen Login verdient mindestens denselben Schutz.

Prüfen Sie, welche Dienste auf Ports lauschen, bevor Sie ihnen 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 Ihre Chat-Oberfläche im öffentlichen Internet erreichbar ist. Auf dem eigenen Rechner zeigt eine Antwort von curl -sI http://YOUR.VPS.IP:3000 auf HTTP/1.1 200 OK dasselbe noch deutlicher.

Das Deaktivieren des Open-WebUI-Logins mit WEBUI_AUTH=False ist für einen Einzelbenutzer auf einem Rechner gedacht, den niemand sonst erreichen kann. Bei einer Installation, für die bereits Konten vorhanden sind, wird diese Einstellung außerdem nicht angewendet. Open WebUI meldet dann You can't turn off authentication because there are existing users.

Muster 1: An Loopback binden und über SSH darauf zugreifen. Veröffentlichen Sie jeden Port auf 127.0.0.1. Leiten Sie anschließend die benötigten Ports 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 nichts veröffentlicht und kann daher auch nicht gescannt werden. Verwenden Sie bei Hollama oder OrionChat im selben Befehl zusätzlich -L 11434:127.0.0.1:11434, um den Modellport weiterzuleiten, und lassen Sie Ollama an Loopback gebunden. 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 2: Ein Reverse Proxy, der die Anfrage authentifiziert, bevor die Anwendung sie sieht. Lassen Sie die Anwendung an Loopback gebunden, überlassen Sie dem Proxy Port 443 und schalten Sie Single Sign-on davor. Traefik, gesteuert über Docker-Compose-Labels, mit Authentik als Identity Provider, stellt für jede 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 2 schützt die Projekte, die ausschließlich im Browser ausgeführt werden, nicht. Ein vorgeschalteter Proxy schützt den Modellendpunkt nicht. Außerdem überträgt ein Abruf von dieser Seite zu einem anderen Hostnamen Ihr Session-Cookie nicht. Der authentifizierende Proxy vor Ollama antwortet dann mit einer Weiterleitung zu einem Login-Formular, und der Chat schlägt fehl. Routen Sie den Modellendpunkt entweder unter demselben Hostnamen wie die Seite oder verwenden Sie Muster 1.

Welche Lösung Sie wählen sollten

Wenn andere Personen als Sie die Anwendung nutzen, setzen Sie Open WebUI ein. Es bietet echte Benutzerkonten. Neue Benutzer werden in eine Freigabewarteschlange aufgenommen. Die Maintainer veröffentlichen außerdem Empfehlungen zur Absicherung, an denen Sie sich orientieren können. Wenn Sie LDAP oder ein Administrationspanel benötigen, setzen Sie LibreChat ein. Prüfen Sie mit docker stats, ob dessen sechs Dienste zusammen mit Ihrem Modell die verfügbaren Ressourcen tatsächlich ausreichen, bevor Sie sich darauf verlassen. Wenn nur eine Person die Anwendung auf einem kleinen System nutzt 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 Sitzungsstatus verwalten. Auf einem VPS ist es grundsätzlich falsch, eine dieser Anwendungen ohne vorgeschaltete Anmeldung über 0.0.0.0 zu veröffentlichen.

FAQ

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

Auf der eigenen Hardening-Seite wird Open WebUI als Software für private, vertrauenswürdige Netzwerke beschrieben, in derselben Kategorie wie eine Datenbank oder ein CI-Server. Es gibt echte Benutzerkonten. Das erste Konto wird zum Administrator, während spätere Konten bis zur Freigabe den Status pending behalten. Damit ist Open WebUI deutlich sicherer als eine Benutzeroberfläche ohne Anmeldung. Trotzdem sollten Sie Open WebUI hinter einem Reverse Proxy mit TLS und, sofern möglich, Single Sign-on betreiben. Veröffentlichen Sie den Container-Port als 127.0.0.1:3000:8080, damit die eigenen iptables-Regeln von Docker den Dienst nicht unbemerkt für das Internet öffnen können.

Welche Open-WebUI-Alternative benötigt auf einem VPS am wenigsten RAM?

Die browserbasierten Anwendungen Hollama und OrionChat benötigen am wenigsten RAM, weil die Anwendung auf dem Client läuft. Der Server liefert nur statische Dateien aus. OrionChat benötigt überhaupt keinen Anwendung-Container. Open WebUI hält einen Python-Prozess, eine Datenbank und standardmäßig ein lokales Embedding-Modell im Speicher. Für das Embedding-Modell allein werden etwa 500 MB pro Worker angegeben. Prüfen Sie die Werte auf Ihrem eigenen System mit docker stats --no-stream, da sie sich abhängig von den aktivierten Funktionen ändern.

Können diese Chat-Benutzeroberflächen einen Ollama-Server auf einem anderen Host verwenden?

Open WebUI und LibreChat können das. Die Verbindung wird von ihrem Server hergestellt, daher gelten keine Browserregeln. Setzen Sie für Open WebUI OLLAMA_BASE_URL oder verwenden Sie 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 Suffix /v1 und einem nicht leeren API-Schlüssel. Hollama und OrionChat können ebenfalls auf einen beliebigen Server verweisen. Die Anfrage kommt dann jedoch aus Ihrem Browser. Der Endpunkt muss daher auch von Ihrem Browser aus erreichbar sein.

Warum kann meine browserbasierte Chat-Benutzeroberfläche Ollama nicht erreichen?

In nahezu allen Fällen gibt es zwei Ursachen. Ollama bindet standardmäßig an 127.0.0.1:11434. Ein Browser auf einem anderen Rechner kann Ollama daher nicht erreichen, bis OLLAMA_HOST geändert wird. Außerdem akzeptiert Ollama Cross-Origin-Anfragen standardmäßig nur von localhost. Eine Seite, die von Ihrer eigenen Domain ausgeliefert wird, wird daher mit No 'Access-Control-Allow-Origin' header is present on the requested resource abgewiesen, bis dieser Ursprung in OLLAMA_ORIGINS eingetragen ist. Wenn die Seite HTTPS verwendet und der Endpunkt HTTP, blockiert der Browser die Anfrage als Mixed Content, bevor Ollama sie überhaupt erhält. Setzen Sie beide Variablen in einem systemctl edit ollama.service-Override oder leiten Sie den Port über SSH weiter. Dann tritt dieses Problem nicht auf.