Open WebUI startet einfach mit lokalem State; Multi-Worker/Multi-Replica-Production braucht Shared Infrastructure. Aktuelle Scaling-Doku trennt PostgreSQL, Redis, externe Vector DB und Shared File Storage.
Open WebUI sagt, Default-ChromaDB nutzt lokales SQLite und kann bei Multi-Worker/Multi-Replica crashen oder korrumpieren. Für Scale client-server Vector DB oder separaten Chroma-HTTP-Server verwenden.
Load Balancer verteilt Traffic auf Open-WebUI-Instanzen; PostgreSQL hält App-State, Redis koordiniert WebSockets/Sessions, externe Vector DB hält RAG-Daten und Shared Storage Dateien.
Stateful Komponenten vor zusätzlichen Replicas external/shared machen.
Content Extraction, Embedding Engine und File Storage müssen ebenfalls Multi-Instance-tauglich sein. Doku empfiehlt externe Extraction wie Tika und externe Embedding Engines.
Container-Namen an eigenes Deployment anpassen.
curl -sS http://127.0.0.1:3000/healthdocker compose psdocker stats --no-streamdocker compose logs --tail=100 open-webuiss -lntp | grep ':3000'User/Group Permissions, Knowledge-Base-Zugriff, Upload Limits, Modell/API Keys und Admin-Policies gemeinsam verwalten.
Aktuelle Scaling-Doku empfiehlt PostgreSQL frühzeitig für Multi-Instance.
Für Cross-Instance-WebSocket-/Session-State.
Nein, die Doku warnt vor SQLite-basiertem Multi-Worker/Multi-Replica-Betrieb.
Teilen Sie Concurrency, RAG-Dokumente, Upload-Volumen und Modell-Backends; PostgreSQL/Redis/Vector DB/Storage planen.