Open WebUI für 500 bis 2.000 Nutzer skalieren: Replikate, Redis, PostgreSQL, SSO und Storage

Open WebUI skalieren: was sich zwischen Pilot und 1.000 Nutzern ändert

Ein Pilot von Open WebUI läuft als ein Container mit SQLite in seinem Datenvolume. Für einen produktiven Betrieb mit 500 bis 2.000 Nutzern stellt der Skalierungsleitfaden von Open WebUI die Installation auf PostgreSQL um, ergänzt Redis für Websockets und gemeinsamen Zustand, betreibt mehrere Replikate hinter einem Load Balancer, verlagert den Vektorindex in eine externe Datenbank und nimmt Dokumentenextraktion und Embeddings aus dem Anwendungsprozess heraus. Seine Kurzübersicht markiert PostgreSQL, Redis und eine externe Vektordatenbank für mehrere Instanzen als erforderlich und führt große Installationen mit „1000+ Nutzern“ mit denselben Anforderungen. Die folgenden Einstellungen stammen aus der Dokumentation von Open WebUI, abgerufen am 10. Oktober 2026, als v0.11.4 das neueste Release auf der GitHub-Seite des Projekts war. Der Kubernetes-Leitfaden legt Helm-Chart 16.5.0 mit v0.11.3 fest, und die Referenz der Umgebungsvariablen ist auf dem Stand von v0.11.1.

Dokumentation von Open WebUI: Skalierungsleitfaden, Fehlerbehebung bei mehreren Replikaten, Seiten zu Redis, SSO und Kubernetes, abgerufen am 10. Oktober 2026.

Die Wahl des Frontends und die Grundlagen der Anmeldung behandelt unser Leitfaden zu einer privaten ChatGPT-Alternative.

PostgreSQL und der Connection-Pool

Der Skalierungsleitfaden nennt den Wechsel als ersten Schritt: „Ersetzen Sie die eingebettete Datenbankkonfiguration durch PostgreSQL, bevor Sie Replikate oder Worker hinzufügen“. DATABASE_URL verweist auf die PostgreSQL-Datenbank. Mehrere Instanzen auf einer SQLite-Datei erzeugen Fehler „database is locked“ und beschädigte Daten, und SQLite darf nicht auf einem Netzwerkdateisystem liegen, weil seine Dateisperren über NFS unzuverlässig sind. Der Leitfaden weist außerdem darauf hin, dass Open WebUI „keine Daten zwischen Datenbanken migriert“; entscheiden Sie also vor dem Wechsel, ob die Chats des Piloten nach PostgreSQL umziehen oder die produktive Plattform leer startet.

Jedes Replikat hält einen eigenen Connection-Pool. Der Leitfaden schlägt DATABASE_POOL_SIZE=15 und DATABASE_POOL_MAX_OVERFLOW=20 als Ausgangspunkt vor und verlangt, die Summe je Instanz „deutlich unter Ihrem PostgreSQL-Limit max_connections (Standard ist 100)“ zu halten. Nach unserer Rechnung kann ein Replikat dann bis zu 35 Verbindungen öffnen, drei Replikate kommen also auf 105, bevor sich Migrationen, Backups oder Monitoring verbinden. PostgreSQL 18 reserviert zudem standardmäßig drei Verbindungen für Superuser. Erhöhen Sie entweder max_connections auf dem Datenbankserver, was erst beim Serverstart wirksam wird, oder verkleinern Sie den Pool je Replikat.

Die Vektoren können im selben PostgreSQL-Server bleiben: Das Produktionsprofil des Kubernetes-Leitfadens setzt VECTOR_DB auf pgvector mit derselben Datenbank-URL und überlässt das Anlegen der Erweiterung vector einem Datenbankadministrator. Wann pgvector nicht mehr ausreicht, zeigt unser Vergleich von Vektordatenbanken für RAG.

Redis für Websockets, Token-Widerruf und gemeinsamen Zustand

Mit WEBSOCKET_MANAGER=redis betreibt Open WebUI Socket.IO über Redis Pub/Sub, sodass eine Antwort, die ein Replikat streamt, auch einen Browser erreicht, der mit einem anderen Replikat verbunden ist. Die Redis-Seite nennt REDIS_URL für den Anwendungszustand, ENABLE_WEBSOCKET_SUPPORT=true, WEBSOCKET_MANAGER=redis und WEBSOCKET_REDIS_URL sowie REDIS_KEY_PREFIX für den Fall, dass sich mehrere Open-WebUI-Instanzen einen Redis-Server teilen. Redis hält außerdem Locks, die Pools für Websocket-Sitzungen und Nutzung sowie die Liste der widerrufenen Token. Die Dokumentation warnt, dass ohne Redis „die Abmeldung das JWT-Token eines Nutzers nicht ungültig macht“, was auch für eine einzelne Instanz gilt.

Dokumentation von Open WebUI, Redis-Seite, abgerufen am 10. Oktober 2026.

Für die Verfügbarkeit verbindet sich Open WebUI über REDIS_SENTINEL_HOSTS mit Redis Sentinel oder mit REDIS_CLUSTER=true mit einem Redis Cluster; sind beide gesetzt, hat Sentinel Vorrang.

Mehrere Replikate hinter einem Load Balancer

Der Skalierungsleitfaden beschreibt Open WebUI als zustandslos, sobald die gemeinsamen Dienste bereitstehen, sodass „Sie beliebig viele Instanzen hinter einem Load Balancer betreiben können“. Belassen Sie UVICORN_WORKERS=1 je Container und lassen Sie den Orchestrator Replikate hinzufügen, denn jeder Worker ist ein vollständiger Open-WebUI-Prozess, der beim Start die Migrationen ausführt. Setzen Sie ENABLE_DB_MIGRATIONS=false auf allen Replikaten außer einem festgelegten Pod. Alle Replikate brauchen denselben WEBUI_SECRET_KEY; mit unterschiedlichen Schlüsseln scheitert ein Token, das ein Replikat ausgestellt hat, am nächsten, und Nutzer sehen Anmeldeschleifen und 401-Fehler. Die SSO-Seite ergänzt, dass OAUTH_SESSION_TOKEN_ENCRYPTION_KEY „von allen Instanzen eines Clusters gemeinsam genutzt werden muss“.

Load Balancer oder Ingress müssen Websockets, gestreamte Antworten ohne Pufferung, passende Request- und Leerlauf-Timeouts und die von Ihnen zugelassene Upload-Größe unterstützen. Jeder öffentliche Hostname gehört in CORS_ALLOW_ORIGIN, sonst scheitern Websocket-Verbindungen an einem Origin-Mismatch. Session-Affinität ist optional: Der Kubernetes-Leitfaden sagt, sie „kann für Socket.IO-Polling nötig sein“, und „Affinität ersetzt Redis nicht“. Der Skalierungsleitfaden erhöht außerdem THREAD_POOL_SIZE auf 2000, weil die Standardobergrenze „nur bei 40 liegt“.

Auf Kubernetes startet das Produktionsprofil des offiziellen Charts drei Replikate mit je einem Worker, Redis und PostgreSQL außerhalb des Charts, Uploads in einem S3-Bucket und aktiviertem Ingress. Der Leitfaden hält fest: „Die Nutzerzahl allein bestimmt nicht die Zahl der Replikate“, und platziert Replikate „auf verschiedenen Nodes, wenn Sie Ausfallsicherheit gegenüber dem Ausfall eines Nodes brauchen“. Chart 16.5.0 legt weder einen HorizontalPodAutoscaler noch ein PodDisruptionBudget über eigene Values an, beide werden daher als separate Ressourcen angewendet. ENABLE_OTEL=true mit OTEL_EXPORTER_OTLP_ENDPOINT exportiert Traces, Metriken und Logs. Die Modellserver hinter Open WebUI sind eine eigene Schicht, die unser Artikel zu einer privaten LLM-Plattform auf Kubernetes behandelt.

Unsere Leistung Private AI/ML baut eine Kubernetes-basierte Plattform auf Ihren Servern oder auf dedizierter Hardware in einem Tier-3-Rechenzentrum in Litauen. Beschreiben Sie den Aufbau Ihres Piloten und die geplante Nutzerzahl im Formular unten.

Dateien, Vektorindex und Dokumentenextraktion

Uploads, die ein Replikat schreibt, müssen für alle anderen lesbar sein, sonst sehen Nutzer Platzhalter „Image unavailable“ und Dateien, die das Modell nicht findet. Die Kurzübersicht des Skalierungsleitfadens markiert gemeinsamen Speicher für mehrere Instanzen und für „1000+ Nutzer“ als „Optional (NFS oder S3)“, und sein Schritt zum Dateispeicher beantwortet die Frage, ob S3 nötig ist, mit „Nicht unbedingt“, da ein gemeinsam eingebundenes Dateisystem wie NFS oder CephFS genügt. Die Seite zu mehreren Replikaten zählt gemeinsamen Speicher zu den „absoluten Voraussetzungen“ eines Aufbaus mit mehreren Replikaten, und das Kubernetes-Produktionsprofil legt Uploads in einem S3-kompatiblen Bucket ab. Zusammen gelesen lassen die Seiten die Wahl zwischen gemeinsamem Dateisystem und Object Storage offen und erwarten, dass jedes Replikat dieselben Dateien sieht. Open WebUI benennt Dateien nach UUID, sodass Replikate ein Verzeichnis ohne Schreibkonflikte teilen können. Binden Sie auf jedem Replikat ein ReadWriteMany-Volume unter /app/backend/data ein, oder setzen Sie STORAGE_PROVIDER auf einen Object Store wie S3. Mit Object Storage behandelt der Kubernetes-Leitfaden /app/backend/data als flüchtig: Dateien dort, die weder in PostgreSQL noch im Bucket liegen, überstehen den Austausch eines Pods nicht.

Die standardmäßige ChromaDB läuft innerhalb der Anwendung auf SQLite. Die Seite zu mehreren Replikaten nennt sie „nicht sicher für Deployments mit mehreren Workern oder mehreren Replikaten“, und die Abhilfe ist ChromaDB als separater HTTP-Server oder eine Client-Server-Datenbank über VECTOR_DB, etwa pgvector, Milvus oder Qdrant. Der Skalierungsleitfaden hält fest: „Nur PGVector und ChromaDB werden vom Open-WebUI-Team dauerhaft gepflegt“.

Der Skalierungsleitfaden nennt die Standard-Extraktions-Engine pypdf und die Standard-Embedding-Engine SentenceTransformers als die beiden häufigsten Ursachen für Speicherlecks im Produktivbetrieb. Er verlagert die Extraktion mit CONTENT_EXTRACTION_ENGINE=tika und TIKA_SERVER_URL auf Apache Tika und die Embeddings mit RAG_EMBEDDING_ENGINE auf einen externen Endpunkt, etwa ein Embedding-Modell, das vLLM bereitstellt.

SSO mit OIDC, Rollen und Modellzugriff nach Gruppen

In dieser Größenordnung kommen die Konten aus dem Identity Provider. Open WebUI liest die OIDC-Discovery-URL aus OPENID_PROVIDER_URL, beschränkt die Anmeldung auf die Rollen in OAUTH_ALLOWED_ROLES und vergibt Administratorrechte an OAUTH_ADMIN_ROLES, wenn die Rollenverwaltung eingeschaltet ist. Mit ENABLE_OAUTH_GROUP_MANAGEMENT folgen die Mitgliedschaften bei jeder Anmeldung dem Claim groups. Die SSO-Seite warnt, dass Nutzer aus Gruppen entfernt werden, „auch aus solchen, die in Open WebUI manuell angelegt oder zugewiesen wurden“, dass es dabei „keine Ausnahme für Rollen“ gibt und dass eine Änderung im Identity Provider erst sichtbar wird, nachdem sich der Nutzer ab- und wieder angemeldet hat. In OAUTH_BLOCKED_GROUPS aufgeführte Gruppen werden nie hinzugefügt oder entfernt.

Modelle, Wissensdatenbanken und Tools, die auf privat gesetzt sind, werden für Gruppen mit Lese- oder Schreibrecht freigegeben. Berechtigungen sind additiv, und Deny-Regeln gibt es nicht; die Seite zu Gruppen empfiehlt deshalb, in Freigabegruppen alle Berechtigungen zu deaktivieren und Funktionsrechte in den globalen Standardwerten zu setzen. Wie Abteilungen und Einführungswellen auf diese Gruppen abgebildet werden, behandelt unser Einführungsplan für 1.000 Mitarbeiter. Wo der Modellzugriff zusätzlich Schlüssel je Team, Token-Budgets und ein Log braucht, zeigt die Verbindung aus Open WebUI auf ein LLM-Gateway statt auf die Modellserver.

Zwei Einstellungen entscheiden, ob die Umgebungsvariablen oder das Admin-Panel Vorrang haben. ENABLE_PERSISTENT_CONFIG steht standardmäßig auf true, und als ConfigVar markierte Variablen werden dann nur beim ersten Start gelesen und in der Datenbank gespeichert. ENABLE_OAUTH_PERSISTENT_CONFIG steht standardmäßig auf false, was „die Umgebungsvariablen für OAuth maßgeblich hält“, und beide müssen auf true stehen, um OAuth über das Admin-Panel zu verwalten. Legen Sie vor dem ersten produktiven Start fest, welche Seite Vorrang hat.

Lizenzbedingungen zum Branding

Seit v0.6.6 vom 19. April 2025 verbietet die Lizenz von Open WebUI, sein Branding zu verändern, zu entfernen, zu verdecken oder zu ersetzen, auf der Lizenzseite beschrieben als „(Name, Logo, UI-Kennzeichen usw.)“, es sei denn, eine Installation hat nicht mehr als 50 Endnutzer „innerhalb eines beliebigen rollierenden Zeitraums von dreißig (30) Tagen“, der Rechteinhaber hat schriftlich zugestimmt oder eine Enterprise-Lizenz erlaubt es. Für die interne Nutzung gilt: „Keine Begrenzung je Nutzer für interne, Mitarbeiter- oder unternehmensweite Nutzung, solange das Open-WebUI-Branding stets vorhanden und deutlich sichtbar ist“. WEBUI_NAME legt den angezeigten Namen fest und hängt laut Variablenreferenz „(Open WebUI)“ an, wenn er überschrieben wird. Ob ein geplantes eigenes Theme innerhalb dieser Bedingungen bleibt, ist eine rechtliche Bewertung für die Rechtsabteilung des Unternehmens.

Backups und Upgrades

Ein Backup umfasst die PostgreSQL-Datenbank, die Chats, Nutzer, Einstellungen und mit pgvector auch die Vektoren enthält, sowie den Bucket oder das Volume mit den Uploads. Die Backup-Seite von Open WebUI nennt für PostgreSQL pg_dump, das laut PostgreSQL-Dokumentation „konsistente Exporte erstellt, auch wenn die Datenbank gleichzeitig benutzt wird“. Kopieren Sie die Uploads direkt nach dem Dump, damit Dateieinträge und Dateien zusammenpassen. Bewahren Sie die geheimen Schlüssel und die Umgebung in Ihrem Secrets Store auf, denn Token und gespeicherte OAuth-Sitzungen hängen von ihnen ab.

Upgrades folgen einer festen Reihenfolge. Die Seite zu mehreren Replikaten hält fest: „Alte und neue Open-WebUI-Instanzen dürfen niemals gleichzeitig Datenverkehr gegen dieselbe Datenbank bedienen“. Die Reihenfolge lautet: Datenbank sichern, alle Replikate stoppen, eine Instanz das Schema migrieren lassen, dann alle Replikate mit der neuen Version starten. Rolling- oder Canary-Upgrades über eine Schemaänderung hinweg werden nicht unterstützt. Der Kubernetes-Leitfaden skaliert das Deployment auf null, startet ein Replikat mit aktivierten Migrationen und deaktiviertem Ingress, prüft es und stellt dann die produktiven Values wieder her; er warnt, dass ein Helm-Rollback, auch mit --atomic, „Datenbankmigrationen nicht rückgängig machen kann“. Testen Sie jedes Upgrade zuerst auf einer Staging-Kopie der Datenbank.

Wir bauen und betreuen die Plattform unter einem vereinbarten SLA, mit Änderungen in vereinbarten Wartungsfenstern und einem Rollback-Plan. Schreiben Sie uns, welche Open-WebUI-Version Ihr Pilot nutzt und wie oft Sie Upgrades planen.

Vom Piloten zum produktiven Aufbau

1. Frieren Sie die Version des Piloten ein, dokumentieren Sie seine Einstellungen und entscheiden Sie, ob seine Chats und Nutzer nach PostgreSQL umziehen.
2. Stellen Sie PostgreSQL mit pgvector bereit, setzen Sie max_connections für die geplanten Replikate und Pools und legen Sie die Erweiterung vector an.
3. Stellen Sie Redis mit noeviction, Append-only-Persistenz und Sentinel oder Cluster für die Verfügbarkeit bereit.
4. Legen Sie den Bucket oder das ReadWriteMany-Volume für Uploads an und betreiben Sie Tika und den Embedding-Endpunkt als separate Dienste.
5. Erzeugen Sie einen WEBUI_SECRET_KEY und einen OAuth-Sitzungsschlüssel, speichern Sie beide als Secrets und entscheiden Sie, ob die Konfiguration in Variablen oder in der Datenbank liegt.
6. Starten Sie ein Replikat mit aktivierten Migrationen und deaktiviertem Ingress, binden Sie OIDC mit Rollen- und Gruppen-Claims an und testen Sie Anmeldung, Freigaben und Uploads.
7. Erhöhen Sie die Zahl der Replikate mit deaktivierten Migrationen, öffnen Sie den Ingress mit Websockets und setzen Sie CORS_ALLOW_ORIGIN.
8. Indizieren Sie die Wissensdatenbanken neu in den neuen Vektorspeicher, binden Sie OpenTelemetry an und schreiben Sie das Runbook für Backup und Upgrade.

Was wir tun

Unsere Leistung Private AI/ML baut eine KI-Plattform unter Ihrer Kontrolle, mit Query-Log sowie Daten- und Berechtigungsverwaltung. Wir starten mit einem Pilotprojekt auf einem Prozess mit klaren Metriken und schulen Ihr Team, die Plattform zu betreiben. Eurokommerz hält den Vertrag und liefert die GPU-Server, vom Einzelserver bis zum Cluster, mit Engineering von unserem Engineering-Partner Vixen.UNO und laufendem Support unter einem vereinbarten SLA; der Preis des technischen Assessments steht vor Beginn fest.

FAQ