Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
Open WebUI starts easily with local state for a single instance, but multi-worker or multi-replica production needs shared infrastructure. Current scaling docs explicitly separate PostgreSQL, Redis, external vector DB and shared file storage steps.
Open WebUI documentation states the default ChromaDB uses local SQLite and can crash or corrupt under multi-worker/multi-replica access. Scaled deployments should use a client-server vector database or a separate Chroma HTTP server.
A load balancer distributes traffic across Open WebUI instances; PostgreSQL stores app state, Redis coordinates WebSockets/sessions, external vector DB stores RAG data and shared storage holds files.
Externalize shared/stateful components before adding replicas.
Content extraction, embedding engines and file storage must also be suitable for multi-instance operation. Documentation suggests external extraction such as Tika and external embedding engines such as Ollama/OpenAI.
Adapt container names to your deployment.
Turkey (Turkish)
Germany (German)
Worldwide (English)
curl -sS http://127.0.0.1:3000/healthdocker compose psdocker stats --no-streamdocker compose logs --tail=100 open-webuiss -lntp | grep ':3000'Manage user/group permissions, knowledge-base access, upload limits, model/API keys and admin policies together.
The current scaling guide recommends PostgreSQL as an early step for multi-instance or more reliable deployments.
It coordinates cross-instance WebSocket/session state across replicas.
Documentation says the local SQLite-backed ChromaDB is unsafe for multi-worker/multi-replica use.
Share concurrent users, RAG documents, upload volume and model backends; we can design PostgreSQL/Redis/vector DB/storage topology.