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

Welche Open-WebUI-Alternative gehört auf 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 Voraussetzungen, und 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 Oberfläche mit dem Modell um das letzte Gigabyte RAM konkurriert. Der Preis für diesen Vorteil ist die Authentifizierung: Sie ist nicht vorhanden.

Alle folgenden Angaben stammen aus der jeweiligen Dokumentation der Projekte, die im August 2026 gelesen wurde. Die vier Kriterien 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 Prozess mit dem höchsten Speicherbedarf 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 nur 127.0.0.1:11434 erreichen kann, erzwingt, dass das Modell auf demselben System wie die Benutzeroberfläche ausgeführt wird.
• Wartungsaufwand. Ein Container mit einer SQLite-Datei ist etwas anderes als sechs Container mit MongoDB und einer dahinter betriebenen Vektordatenbank.

Wie viel RAM bleibt für die Benutzeroberfläche?

Die Benutzeroberfläche ist nicht der größte Speicherverbraucher auf dem System. Das ist das Modell. Die veröffentlichten Downloadgrößen geben die Untergrenze vor, weil die Gewichte im Speicher bleiben müssen, während das Modell antwortet. Der tatsächliche Speicherbedarf liegt höher als die Downloadgröße, sobald der Kontext-Cache reserviert ist.

[
  {
    "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 angezeigt wurden. Es handelt sich um veröffentlichte Größen, nicht um Messwerte. Auf einem VPS mit 4 GB lässt qwen3:4b bei 2.5 GB weniger als 1.5 GB für das Betriebssystem und alle anderen Prozesse übrig. Der Kontext-Cache verringert diesen freien Speicher weiter, wenn eine Unterhaltung länger wird. Deshalb ist der von Ihnen gesetzte num_ctx ebenso eine Speicherentscheidung wie eine Qualitätsentscheidung. qwen3:8b mit 5.2 GB passt überhaupt nicht auf dieses System. Diese Situation wird in Laptop-Vergleichen nie berücksichtigt. Hier entscheidet eine Chat-Benutzeroberfläche, die einige hundert Megabyte belegt, ob das Modell ausgeführt werden kann. Wenn Sie ein System für ein Modell deutlich oberhalb dieser Größenklassen planen, zeigt die Berechnung für ein 27B-Modell auf einem CPU-only-VPS, wie schnell die Benutzeroberfläche nicht mehr der entscheidende Wert ist.

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

Open WebUI: weiterhin die Standardlösung für mehr als einen 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: 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 Möglichkeiten werden weiter unten beschrieben. Erstellen Sie anschließend das erste Konto. Dieses Konto wird zum Administrator. Spätere Registrierungen werden mit der Rolle pending und dem dokumentierten Standardwert DEFAULT_USER_ROLE angelegt. Eine fremde Person, die die Seite erreicht, kann Ihr Modell daher erst verwenden, wenn ein Administrator sie freigibt.

Open WebUI benötigt mehr Arbeitsspeicher als die folgenden Projekte, weil es mehr Funktionen bietet. Auf der eigenen Performance-Seite werden die dafür verantwortlichen Komponenten genannt. Die standardmäßige Embedding-Engine lädt ein sentence-transformers-Modell innerhalb des Containers. In der Dokumentation werden dafür etwa 500 MB pro Worker-Prozess angegeben. Mit RAG_EMBEDDING_ENGINE=ollama übertragen Sie diese Aufgabe an den bereits laufenden Model-Server. AUDIO_STT_ENGINE=webapi verhindert das Laden eines lokalen Speech-to-Text-Modells. Wenn DATABASE_POOL_SIZE bei SQLite nicht gesetzt ist, verwendet der Pool eine große interne Größe. Jede Verbindung vergrößert dann ihren eigenen Page-Cache und ihr eigenes Memory-Mapping. Setzen Sie auf einem kleinen System daher DATABASE_POOL_SIZE=8 und DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False verhindert, dass die Benutzeroberfläche das Modell nach einer Completion fragt, während ein Benutzer noch tippt.

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 Anmeldefelds benötigen: Die Dokumentation beschreibt LDAP- und OAuth2-Anmeldungen. 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 Standarddatei für Compose 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 Arbeitsspeicher dann dem Modell.

Upgrades werden als git-Vorgang durchgeführt. 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 für diesen Zweck bereit. Speichern Sie Geheimnisse in .env. Beide Dateien sind nicht versioniert, daher lässt git pull sie 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, 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 übernimmt die Arbeit

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, sodass die Oberfläche nach einem Reboot nicht wieder verfügbar ist. 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 Anfragen an einen 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 den Ordner mit dem bereits betriebenen Webserver bereit, oder öffnen Sie index.html direkt von der Festplatte. API-Schlüssel werden im 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 hat eine Anmeldung, weil keines einen Server besitzt, der eine solche Anmeldung prüfen könnte. Auf einem Laptop ist das unproblematisch. Auf einem VPS bedeutet es, dass die Seite niemals über 0.0.0.0 veröffentlicht werden darf. Außerdem gibt es einen leicht zu übersehenden Punkt: Der Browser ruft das Modell auf, nicht der Server.

Diese Tatsache bestimmt, wo die beiden Anwendungen eingesetzt werden können. Ihr Browser muss Ollama direkt erreichen können. Daher muss Ollama auf mehr als nur dem Loopback-Interface lauschen. Ollama bietet keinerlei Authentifizierung. Daraus folgen zwei Regeln für den Browser. Eine über HTTPS bereitgestellte Seite kann keinen HTTP-Endpunkt ohne TLS aufrufen. Außerdem gibt die Konsole 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 eine andere Origin wird mit has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource abgelehnt, bis Sie diese Origin erlauben.

Die von Ollama dokumentierte Methode zum Ändern beider Einstellungen 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, wo 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 Modellserver, und Massenscanner erreichen einen neuen öffentlichen Port schnell. Der folgende SSH-Tunnel vermeidet dieses Problem vollständig: Die Seite läuft dann über eine localhost-Origin, die 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 das über baseURL des oben gezeigten benutzerdefinierten Endpunkts. Diese Anfrage verlässt ebenfalls den Server, daher gilt keine Browserregel. Dieselbe Basis-URL und derselbe Platzhalter-Key funktionieren auch außerhalb eines Chatfensters. Damit können Sie einen Coding-Agent auf das bereits von Ihnen gehostete Modell verweisen.

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

Die Trennung von Oberfläche und Modell ist der größte Vorteil eines entfernten Endpunkts. Platzieren Sie die Oberfläche auf einer kleinen Maschine und das Modell dort, wo ausreichend Arbeitsspeicher vorhanden ist. An diesem Punkt sollten Sie auch entscheiden, ob Ollama oder vLLM die Anfragen verarbeiten soll, da sich beide deutlich 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 einer Maschine ohne GPU-Unterstützung lesen Sie außerdem wie Ollama im Vergleich zu llama.cpp abschneidet, bevor Sie einen Runner auswählen.

Keine Chat-Weboberfläche ohne Anmeldung 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. Dort wird empfohlen, die Anwendung hinter einem VPN oder hinter einem Reverse Proxy mit Authentifizierung zu betreiben. Ein Projekt ganz ohne Anmeldung sollte mindestens genauso behandelt werden.

Prüfen Sie, welche Dienste lauschen, bevor Sie einer dieser Einstellungen 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. Wenn von Ihrem eigenen Rechner aus curl -sI http://YOUR.VPS.IP:3000 mit HTTP/1.1 200 OK antwortet, zeigt das noch eindeutiger dasselbe.

Wenn Sie die Anmeldung von Open WebUI mit WEBUI_AUTH=False deaktivieren, ist das eine Einstellung für einen einzelnen Benutzer auf einem Rechner, den niemand sonst erreichen kann. Sie lässt sich außerdem nicht auf eine Installation anwenden, in der bereits Konten vorhanden sind. In diesem Fall erscheint die Meldung 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 auf Ihrem Laptop http://localhost:3000. Es wird nichts veröffentlicht und kann daher auch nicht gescannt werden. Für Hollama oder OrionChat leiten Sie den Modell-Port im selben Befehl mit -L 11434:127.0.0.1:11434 weiter und lassen Ollama auf loopback lauschen. Die Sicherheit dieses Musters hängt 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 auf loopback lauschen. Überlassen Sie dem Proxy Port 443 und schalten Sie Single Sign-on davor. Traefik, gesteuert über Docker-Compose-Labels, zusammen mit Authentik als Identity Provider, stellt für jede Anwendung auf dem Rechner eine gemeinsame Anmeldung 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 bis zu seinem Ablaufzeitpunkt verwendbar.

Muster 2 schützt die Projekte nicht, die ausschließlich im Browser funktionieren. Ein Proxy vor der Seite schützt den Modell-Endpunkt nicht. Ein Abruf von dieser Seite zu einem anderen Hostnamen überträgt außerdem Ihr Session-Cookie nicht. Der authentifizierende Proxy vor Ollama antwortet dann mit einer Weiterleitung zu einem Anmeldeformular, und der Chat schlägt fehl. Routen Sie den Modell-Endpunkt entweder unter demselben Hostnamen wie die Seite oder verwenden Sie Muster 1.

Welche Lösung Sie wählen sollten

Wenn andere Personen als Sie den Dienst verwenden, setzen Sie Open WebUI ein. Es bietet echte Benutzerkonten. Neue Benutzer landen in einer Genehmigungswarteschlange. Die Maintainer veröffentlichen außerdem Härtungshinweise, die Sie umsetzen können. Wenn Sie LDAP oder ein Administrationspanel benötigen, setzen Sie LibreChat ein. Prüfen Sie mit docker stats, ob seine sechs Dienste zusammen mit Ihrem Modell die verfügbaren Ressourcen tatsächlich ausreichen, bevor Sie sich darauf verlassen. Wenn nur eine Person den Dienst auf einem kleinen System nutzt und das Modell bereits den größten Teil des RAM belegt, stellen Sie Hollama oder OrionChat über einen SSH-Tunnel bereit. Lassen Sie den Browser den Sitzungsstatus verwalten. Die falsche Lösung auf einem VPS ist jede dieser Anwendungen, die ohne vorgeschaltete Anmeldung auf 0.0.0.0 veröffentlicht wird.

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 pending bleiben. Damit ist Open WebUI deutlich sicherer als eine Oberfläche ohne Anmeldung. Trotzdem sollten Sie Open WebUI hinter einem Reverse Proxy mit TLS und, wenn möglich, mit Single Sign-on betreiben. Veröffentlichen Sie den Container-Port als 127.0.0.1:3000:8080, damit die eigenen iptables-Regeln von Docker ihn nicht unbemerkt ins Internet öffnen können.

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

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

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

Open WebUI und LibreChat können das. Die Verbindung wird von ihrem Server hergestellt, daher gilt keine Browser-Regel. Setzen Sie für Open WebUI OLLAMA_BASE_URL oder verwenden Sie baseURL in einem benutzerdefinierten Endpoint 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-Key. Hollama und OrionChat können ebenfalls auf ein beliebiges Ziel verweisen. Die Anfrage kommt dann jedoch aus Ihrem Browser. Daher muss der Endpoint auch von Ihrem Browser aus erreichbar sein.

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

Fast alle Fälle haben eine von zwei Ursachen. Ollama bindet standardmäßig an 127.0.0.1:11434. Ein Browser auf einem anderen Rechner kann Ollama daher erst erreichen, wenn sich OLLAMA_HOST ändert. Außerdem akzeptiert Ollama Cross-Origin-Anfragen standardmäßig nur von localhost. Eine Seite von Ihrer eigenen Domain wird daher mit No 'Access-Control-Allow-Origin' header is present on the requested resource abgewiesen, bis dieser Origin in OLLAMA_ORIGINS aufgeführt ist. Wenn die Seite HTTPS verwendet, der Endpoint jedoch HTTP, blockiert der Browser den Aufruf als Mixed Content, bevor Ollama ihn überhaupt sieht. Setzen Sie beide Variablen in einem systemctl edit ollama.service-Override oder leiten Sie den Port über SSH weiter. Damit verschwindet das Problem.