Open WebUI single instance vs scaled deployment

Users see WebSocket 403 errors, configuration sync breaks between replicas, and authentication can fail intermittently. The scaling guide attributes these symptoms to missing shared state: each replica keeps its own websocket connections and application state, so a request can reach a replica that does not know about the session. The fix the guide describes is to set REDIS_URL, WEBSOCKET_MANAGER=redis and ENABLE_WEBSOCKET_SUPPORT=true on every replica so they share sessions, websocket connections and application state through one Redis instance. Confirm the exact Redis topology (single node, managed service or cluster) with your platform team, since the guide describes the variables but not a sizing for Redis itself.

Login loops and 401 errors usually mean the replicas do not share the same WEBUI_SECRET_KEY. Each replica signs and verifies session tokens with its own key, so a token issued by one container is rejected by another, and the browser keeps sending users back to the login page. The fix is to set an identical WEBUI_SECRET_KEY on every replica and to generate it once and store it in your secrets manager. Changing the key later invalidates existing sessions, so plan the rotation as a maintenance event. A simple test is to log in, then refresh several times: repeated redirects point to a key mismatch rather than to the identity provider.

Files uploaded through one replica can be missing or unreadable on another, so chats that reference a document or a knowledge base fail for some users and succeed for others. The scaling guide says replicas need shared access to uploaded files through a shared filesystem or object storage such as S3, GCS or Azure Blob. The fix is to place the upload directory on storage that every container mounts, or to use an object store, and to confirm that knowledge base content is reachable from every replica. Ask your team to test an upload, then query it from several sessions routed to different containers before go-live.

The default ChromaDB is not suited to multi-process use, and the scaling guide warns that it will crash when Open WebUI runs in multi-process setups. The cause is that the embedded store is opened by the application process rather than served to many workers. The fix the guide describes is to move vector storage to a client-server database: PGVector, Milvus, Qdrant, Pinecone or ChromaDB running in HTTP mode. If you already run PostgreSQL for Open WebUI, PGVector is the option with the fewest new services, though you should check its indexing and performance against your document volume before choosing it.

Open WebUI does not migrate data between databases, so a switch from SQLite to PostgreSQL after production use leaves users, chats, settings and configuration behind unless you move them yourself. The scaling guide advises planning the switch before there is production data, because SQLite does not handle concurrent writes from multiple processes well and a multi-instance deployment needs PostgreSQL through DATABASE_URL. If data already exists, ask your implementation partner to scope a data migration as a separate, written task with a rehearsal, rollback plan and a verification step. Its cost and duration depend on data volume, custom configuration and how many systems reference Open WebUI, so get them in writing before work starts.

The cost of these fixes falls on whoever builds and runs the multi-replica stack: your staff, a partner, or both. The one-time work covers the Redis, PostgreSQL, shared storage and vector database setup, secret handling, testing across replicas and the data migration if one is needed. The recurring work covers operating those services, patching them and rotating the secret key under change control. Costs rise with the number of replicas, the amount of existing data and how many integrations depend on the chat platform. Ask any quote to list each component separately, state what is tested and in which environment, and say whether backups and failover tests are included. DeployOpen does not publish prices; a fixed-scope quote follows from the written scope.

Moving from one container to several adds components you must run, not just more containers. The main cost drivers are the infrastructure for PostgreSQL, Redis, shared file storage and a client-server vector database, the staff who build and operate them, and the support scope you agree on. Infrastructure and staff time recur every month, while design, configuration and cutover work is largely one-time. Ask any quote to itemize the build, the environments covered, whether PostgreSQL and Redis are self-run or managed, how storage and backups are handled, and what ongoing support or upgrade work is included. DeployOpen does not publish a price list; a quote follows from the written scope.

The duration depends on the scope, so it is set during scoping rather than assumed in advance. The factors that move the timeline are the size of your existing data, how many replicas and environments you need, whether your file storage and vector database are already in place, and how much testing your authentication and session behavior requires. DeployOpen plans and implements most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts. Ask for the timeline as a set of milestones tied to those deliverables.

A capable platform team can do it alone if it has working experience with PostgreSQL administration, Redis, a reverse proxy or load balancer that supports WebSockets, and a shared storage backend. The Open WebUI scaling guide names the required settings, such as DATABASE_URL, REDIS_URL, WEBSOCKET_MANAGER=redis, ENABLE_WEBSOCKET_SUPPORT=true and one shared WEBUI_SECRET_KEY across all replicas. The harder parts are backups, failover, upgrades and testing failure modes such as login loops and intermittent 401 errors. Assess those skills honestly before deciding, and consider a fixed-scope engagement for the build with your team owning day-to-day operations.

Open WebUI does not migrate data between databases, so an in-place switch from SQLite to PostgreSQL should not be assumed to carry your history over. The scaling guide advises planning the switch before there is production data. If you already run production use, ask for the migration approach in writing, test it against a copy of your data, and confirm which records, such as users, chats, knowledge bases and settings, must survive the move and how they will be verified afterward.

Yes, the branding rule is tied to user count. Since v0.6.6, the Open WebUI License forbids altering or removing Open WebUI branding unless the deployment has no more than 50 end users in a rolling 30-day period, the copyright holder gives written permission, or the licensee holds an enterprise license. Scaling out for performance does not by itself change the license, but a larger user base does. Confirm your user count method and your options with Open WebUI directly, and check the Open WebUI License documentation and LICENSE file before you commit to a rollout plan.

Missing shared state causes symptoms that look like unrelated bugs. According to the scaling guide, a multi-instance deployment without Redis can show WebSocket 403 errors, configuration sync problems and intermittent authentication failures. Replicas with different WEBUI_SECRET_KEY values can cause login loops and 401 errors. Uploads and knowledge that live on one replica's local disk will be missing when a request lands on another. The ChromaDB default can also crash in multi-process setups, so use a client-server vector database. Test each of these before cutover, including a replica restart during an active chat session.

Running several Open WebUI replicas does not make the database highly available. PostgreSQL supports hot standby servers and both synchronous and asynchronous replication, but it does not detect a primary failure or notify the standby on its own, so automatic failover needs external tools. Decide who owns that tooling, how backups and point-in-time recovery are set up, and how upgrades are scheduled, since minor releases and major upgrades follow different procedures. Ask any implementation partner to state which of these it builds, which it documents, and which remain with your team.