Open WebUI high availability guide

Why Open WebUI high availability starts with shared state, not extra containers

If you want more than one Open WebUI instance for uptime or capacity, the first thing to understand is that adding replicas behind a load balancer is the easy part. The default single-container setup stores its working data in local files and a local SQLite database, and it was not built for several processes writing to the same state at once. High availability means every replica reads and writes the same database, the same Redis instance, the same vector store and the same file storage. Anything less produces users who are signed in on one replica and signed out on the next.

The scaling guide makes the database requirement explicit: multi-instance deployments need PostgreSQL instead of SQLite, because SQLite does not handle concurrent writes from multiple processes well. Moving to PostgreSQL is a data migration, not a configuration flag, so teams that start on SQLite should plan the cutover with their existing users, chats and settings in mind. Confirm the exact migration steps for your release with the Open WebUI documentation before you change anything in production.

Sessions and tokens are where the load balancer stops being enough. Without Redis, signing out does not revoke tokens. They stay valid until they expire, and by default that is 4 weeks. In a replicated setup, a user who signs out on one replica can still act through a token issued by another, and security reviewers will ask how a compromised token is revoked. Redis also holds websocket connection state and other application state that must be visible to every replica. Decide early how session lifetimes and revocation will be handled, and test sign-out against several replicas before go-live.

Websockets and uploads add the next layer of difficulty. Streaming responses and live updates depend on connection state, so the load balancer and any proxy in front of Open WebUI must pass websocket traffic correctly, and the shared Redis state must let any replica serve a connection that another one started. File uploads and knowledge base content must also be reachable from every replica, which means shared file storage rather than a directory on one container's disk. The scaling guide also warns that the default ChromaDB crashes in multi-process setups, so an external vector database is required once you run several workers or replicas.

The practical question for your team is whether each shared component has an owner, a backup and a failure plan. Ask who operates PostgreSQL, Redis, the vector database and the file store, how each is backed up, and what happens to in-flight chats if one of them restarts. Treat these as the design inputs for the rest of the high availability work, because no number of extra containers compensates for a shared component that cannot survive a failure.

Which Open WebUI components must be shared across replicas

Running several Open WebUI replicas moves state out of each container and into shared services. Five components carry that state: the load balancer, the database, the session store, the vector database and file storage. Each one fails in a specific way when a replica keeps its own copy.

Load balancer in front of replicas

The load balancer spreads user requests across replicas and must pass websocket upgrades and long streaming responses through without dropping them. If it sends a user's requests to different replicas without a plan for session state, chats can appear to reset or stall mid-answer. If health checks and proxy timeouts are set too low, healthy replicas can be marked as failed during long model responses. Confirm the routing, affinity and timeout settings against the scaling documentation for the release you deploy.

PostgreSQL for application data

Open WebUI keeps users, chats, settings and access rules in its database. The scaling guide requires PostgreSQL in place of SQLite for multi-instance deployments because SQLite does not handle concurrent writes from multiple processes well. If replicas share a SQLite file across the network or keep separate copies, writes can conflict, fail or diverge, and users may see missing chat history or inconsistent settings. Confirm the connection variables and the migration path for your version before cutover.

Redis for sessions and websockets

Redis holds sessions, websocket connection state and shared application state for every replica. Without it, each replica tracks sessions on its own, and signing out on one replica does not revoke tokens held by another. The scaling guide notes that tokens stay valid until they expire, by default after 4 weeks, so a stolen token can remain usable on any replica. Confirm the Redis connection settings for your release and test sign-out across all replicas before go-live.

External vector database for retrieval

The scaling guide warns that the default ChromaDB will crash in multi-process setups, so running several workers or replicas requires an external vector database. Open WebUI's retrieval features list 13 supported vector databases, including PGVector, Qdrant, Milvus and Elasticsearch. The chosen store must be reachable from every replica over the network, and index creation and maintenance must be handled once for the whole cluster. Confirm the connection variables and the supported options for your version before you size the knowledge base.

Shared storage for uploads and knowledge

Uploaded files and knowledge base documents must stay reachable from every replica. If each replica writes to its own local volume, a file uploaded through one replica may be missing or unreadable through another, and knowledge collections can appear incomplete to some users. Choose shared storage that every replica mounts with consistent permissions, and include it in backup scope so that file and database records stay aligned. Confirm the storage settings in the scaling documentation for your release.

Which database, Redis, vector store and storage options fit your team

This table compares the realistic options for each shared component in a multi-replica Open WebUI deployment and the operational load each one places on your team. Read each row as a decision: the option, when it fits, and who carries backups, failover, upgrades and paging. The main takeaway is that the choice depends less on the product than on who already runs database and cache services well and who will answer when a replica loses its shared state.

Component	Option	When it fits	Operational cost to plan for
PostgreSQL	Managed PostgreSQL service in your cloud account	Your team already runs managed databases and wants the provider to handle patching and host failure	You still own schema migration timing with each Open WebUI release, backup retention settings, restore testing and access control. Confirm the provider's failover behavior and recovery point with them.
PostgreSQL	Self-run PostgreSQL cluster	You have experienced DBAs and need control over versions, replication and network placement	Your team owns replication, failover automation, backups, upgrades and the on-call page when the primary fails. Required by the scaling guide instead of SQLite for multi-instance use.
Redis	Managed Redis service	You want shared session and websocket state without operating a cache cluster	Confirm whether the service offers the persistence and failover mode you need. Plan for upgrade windows and for checking that token revocation still works after a failover.
Redis	Self-run Redis with replication and sentinel or equivalent failover	Platform engineering already runs Redis for other workloads and can reuse existing monitoring	Your team owns failover tuning, memory limits, persistence settings and the page when state is lost. Without Redis, sign-out does not revoke tokens until they expire, by default after 4 weeks.
Vector store	PGVector inside the existing PostgreSQL service	You want the fewest new components and your knowledge base size is modest to moderate	Retrieval load shares the database's CPU, memory and backup window. Confirm sizing with your DBA before the knowledge base grows.
Vector store	Dedicated vector database such as Qdrant, Milvus or Elasticsearch	Knowledge bases are large, retrieval must be isolated from the chat database, or your team already runs the engine	Adds another stateful service with its own backups, upgrades, scaling and paging. The default ChromaDB is not suitable for several workers or replicas, so an external store is required.
Shared file storage	Network file system mounted on every replica	You need uploads and knowledge files reachable from any replica with minimal change	Your storage team owns mount reliability, permissions, latency and snapshots. Confirm the file locking and performance behavior with your storage vendor before go-live.
Shared file storage	Object storage through a supported storage backend setting	Your organization already standardizes on object storage and wants durable, centrally backed files	Confirm the Open WebUI version and storage configuration you plan to use against the official documentation. Plan for credential rotation and bucket lifecycle rules.
Local database file	SQLite on locally attached SSD or NVMe	Single-replica use, evaluation or a small team only	Not suitable for multiple replicas. Network-mounted SQLite is not acceptable under the scaling guidance, so this option ends when you add a second replica.

How to build Open WebUI high availability in the right order

This sequence builds Open WebUI high availability in the order that avoids rework: shared database and session state first, then retrieval and files, then replicas and routing. Each step ends with a check that confirms the layer works before the next one depends on it.

Provision PostgreSQL as the shared database
Your platform or database team provisions a PostgreSQL instance that every replica can reach over the private network, with backups and credentials managed outside the Open WebUI configuration. The scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments because SQLite does not handle concurrent writes from multiple processes well. Start with a clean database for a new install, or move existing data from an earlier SQLite install before any second replica starts. Check: connect from a test host using the same credentials the application will use, then confirm the first start creates Open WebUI's tables on the PostgreSQL instance rather than in a local file.
Add Redis and confirm shared sessions
Deploy one Redis service that all replicas share, and point Open WebUI at it for sessions, websocket connections and application state. Without Redis, signing out does not revoke tokens, which stay valid until they expire, by default after 4 weeks, so a logout on one instance would leave the others open. Confirm the Redis configuration keys for your release in its documentation. Check: sign in through one replica, confirm the session works on a second replica, then sign out on the second replica and confirm the token is rejected on the first. Complete this check before adding more replicas so any gap is found while the topology is small.
Replace ChromaDB with an external vector database
Choose a vector database from the supported list, such as PGVector, Qdrant, Milvus or Elasticsearch, and configure Open WebUI to use it for retrieval. The scaling guide warns that the default ChromaDB will crash in multi-process setups, so this change is required once more than one worker or replica runs. Base the choice on your team's operating skills and your existing data platform, and confirm the exact configuration keys for the release in use. Check: upload a small knowledge document, run a query that should match it, and confirm the vector collection exists in the external database. If documents were already embedded in ChromaDB, plan a re-index before go-live.
Place shared file storage for every replica
Mount shared file storage that every replica reads and writes, so uploads and knowledge files stay reachable no matter which replica handles a request. The scaling guide requires shared storage for multiple replicas. Confirm that the storage supports concurrent access from all hosts and that mount paths and permissions match across replicas. Check: upload a file through the first replica, retrieve it through the second and confirm the content matches. Then open a file that was indexed for retrieval from the second replica. Ask your storage team to document latency and failover behavior in your environment, since both affect user experience during an outage.
Start two or more identical replicas
Start at least two Open WebUI replicas from the same image version and the same configuration, including the same database, Redis, vector store and storage paths. Any difference between replicas can make the same user see different behavior depending on where a request lands. Use the install method you chose: with Docker Compose or Helm, replicas are defined in one place, while a pip install runs a single process, so confirm how your setup launches multiple instances before relying on it. Check: compare the effective environment of each replica, then confirm both pass a health request and show the same model list after sign-in.
Put the load balancer in front
Place a load balancer in front of the replicas, terminate TLS there or at the ingress according to your standards, and route only to replicas that pass health checks. Confirm the health endpoint, timeouts and websocket support for the release in use, since long streaming responses need timeouts that allow them to finish. Check: send repeated requests through the balancer and confirm they land on more than one replica. Then stop one replica and confirm that traffic continues to the other without requiring a new sign-in, which shows that shared session state is working.
Enable sticky routing only if required
Turn on sticky or session-aware routing only if the release or the load balancer requires it, such as when websocket connections or in-flight uploads fail after a request lands on a different replica. Enabling it without a reason can hide session problems that Redis should solve and reduces how evenly load spreads across replicas. Check: during a load test in your environment, record whether websocket reconnects or upload errors occur with plain round-robin routing. If they do not, leave stickiness off and document that decision in the operations runbook.

The failure modes the scaling guide warns about and how they show up

The most common multi-replica failures in Open WebUI come from single-node habits carried into a setup with several processes. The scaling guide names three: SQLite write contention across processes, the default ChromaDB crashing under multiple workers or replicas, and tokens that survive sign-out because Redis is missing. Each produces symptoms that look like unrelated application bugs, so operators need to know which cause is active before they start changing settings. SQLite write contention is the first to check. The scaling guide requires PostgreSQL for multi-instance deployments because SQLite does not handle concurrent writes from several processes well. When it happens, the typical symptom is intermittent errors on actions that write data, such as saving a chat, changing settings or updating a user record, while reads still succeed. Check the database URL each replica is actually using. If any replica still points at a local SQLite file, that replica is a likely source of lock errors and inconsistent state.

SQLite remains acceptable in narrow cases: a single replica, evaluation, or a small team, and only when the database file sits on locally attached SSD or NVMe storage rather than network storage. A shared network volume holding the SQLite file is the combination to avoid. Confirm with your own storage team whether any volume you plan to use is network-attached, including volumes that look local inside a virtual machine or container. Default ChromaDB is the second. The guide warns that the default vector database will crash in multi-process setups, so an external vector database is required once you run several workers or replicas. The symptom is usually document retrieval failing, or uploads that appear to succeed and then fail during indexing. Operators sometimes read this as a file problem, but the cause is the vector store. Confirm which vector database each replica is configured to use and move every replica to the same external instance before you retest uploads.

Tokens that survive sign-out is the third and the hardest to notice. Without Redis, signing out does not revoke tokens. They stay valid until they expire, by default after 4 weeks. Users who sign out on one replica can still act through a token held in another browser or client, and security reviews will flag this as a session control gap. The symptom is a user reporting that a sign-out did not end access, or an administrator finding active sessions for disabled accounts. Test it directly: sign in, sign out, then replay the old token against a different replica.

What drives the effort and cost of Open WebUI high availability

This table lists the factors that move the scope of an Open WebUI high availability build and shows how to keep each one under control. Read each row as a question to answer in your written scope before comparing quotes. The main takeaway is that a fixed, narrow first release with existing shared services usually makes the work easier to price and verify.

Driver	Why it changes effort or cost	How to keep it down
Number of users and concurrent sessions	Replica count, Redis sizing, load balancer configuration and load testing all depend on peak concurrent sessions and websocket connections, not just registered users.	Ask for a named user count and an expected peak concurrency figure, then scope load testing against that number only.
Knowledge base size and upload volume	Shared file storage must hold every upload and knowledge file reachable from each replica, and the external vector database must index the full corpus. Volume drives storage, reindexing and backup effort.	Limit the first release to a fixed set of knowledge collections and defer bulk historical imports to a later phase.
Identity and model provider integrations	Each OIDC, LDAP, SCIM or model provider connection adds configuration, secret handling, group mapping and test cases that must pass on every replica.	Start with one identity provider and a fixed list of approved model providers, then add others as separate scoped items.
Number of environments (dev, test, production)	Each environment needs its own PostgreSQL, Redis, vector database, storage and load balancer configuration, plus a deployment pipeline and test runs.	Scope the first build to one production-like environment, and reuse infrastructure templates for any later environment.
Existing shared storage and database high availability	If the organization already runs highly available PostgreSQL, Redis, shared storage and a supported vector database, much of the infrastructure work becomes integration and configuration rather than new platform build.	Confirm which services already exist, their owners, their support model and their capacity before the quote is prepared.
Compliance evidence requirements	Assessors may expect documented architecture, access reviews, backup and restore test records, change logs and failover test results. Producing and retaining this evidence adds recurring and one-time effort.	Agree the evidence list in writing up front and map each item to the team that will produce it. DeployOpen prepares evidence but does not issue audit reports or certifications.
Failure mode testing scope	Testing Redis outages, token behavior after sign-out, replica failure during uploads and vector database unavailability takes separate test cycles. Each added failure case adds time.	Define the failure cases that must be proven before go-live and treat the rest as a documented risk for a later round.

How the design changes by deployment model

A single node runs one Open WebUI container with its data on local storage. It is the simplest design and the baseline for evaluation or a small team. Nothing is shared, so a host or container failure stops the service until it is restored. The scaling guide allows SQLite in this model only when the database file sits on locally attached SSD or NVMe storage.

Shared storage: Not required. Uploads and knowledge stay on the container's local volume.
Database: SQLite is acceptable only when the file sits on locally attached SSD or NVMe storage.
Redis and vector store: Redis is not needed for one replica. Confirm the default vector store and worker settings against the scaling guide before relying on them.
Load balancer: None. Clients connect to the host directly, so a restart interrupts every active session.
Updates and files: Pull a pinned image tag, back up the volume, then restart. Keep the run command or Compose file in version control.

Before go-live, confirm the database file location, the backup schedule and the restore time your users can accept.

Token revocation, secrets and access control across replicas

Running several Open WebUI replicas spreads session state, credentials, files and extensions across more components, and each one becomes a place where access can be wrongly granted or wrongly kept. The cards below cover the controls that matter specifically because of multi-replica operation. The wider hardening scope, including sign-up policy and API key scope, is covered in the separate security hardening topic.

Shared Redis for sign-out revocation

Without Redis, signing out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. In a multi-replica setup, Redis must be shared by every replica so a sign-out on one replica is honored on all of them. To verify, sign out on one replica's address, then replay the old token against another replica and confirm it is rejected.

Credentials kept out of source control

Database and Redis credentials should be injected at runtime from a secrets manager or the platform's secret store, never committed to Compose files, Helm values or Git repositories. Each replica should read the same secret source so rotation is applied consistently. To verify, search the deployment repository for connection strings and confirm none are present in plain text.

Credential rotation without downtime

Rotating the PostgreSQL and Redis passwords must be planned so that replicas restart or reload in a controlled order and no replica holds stale credentials. Confirm with the team which secret rotations are tested in staging before production. To verify, rotate the credential in staging during a load test and confirm all replicas reconnect without errors.

No exposed replica addresses or admin paths

The load balancer should publish only the user-facing hostname and should not expose individual replica addresses, health endpoints with internal detail, or administrative paths. Internal replica addresses let clients bypass the balancer and its controls. To verify, scan the public endpoint from outside the network and confirm only the intended routes respond.

Shared file storage access controls

Uploads and knowledge files on shared storage must carry access controls that match the permissions Open WebUI applies to users and groups, so a file hidden from a user in the application is also unreadable at the storage layer. Confirm the storage service account has only the rights the application needs. To verify, request a file that a restricted user cannot see in the interface directly from storage and confirm access is denied.

Consistent review of tools and functions

Tools and functions run code and must be reviewed and installed the same way on every replica, since a difference between replicas produces behavior that is hard to trace. Pin the same versions and keep the source under change control. To verify, compare the installed tool list and checksums across replicas after each change.

How to test that Open WebUI fails over safely before users depend on it

Before users depend on a multi-replica Open WebUI deployment, run a scripted set of failover tests that exercise the shared state the scaling guide says must be common to every replica: Redis for sessions, websocket connections and application state, PostgreSQL for data, and shared file storage for uploads and knowledge. A deployment that passes a single happy-path login has not proven that it fails over safely. The tests below are designed to expose the specific failure modes that appear when those components are misconfigured or only partly shared.

Start with session continuity. Sign in through the load balancer, note which replica served the session, then stop that replica's container or pod. Send the next request through the load balancer and confirm the session still works on another replica without a forced re-login. Repeat the check with the session pinned to a different replica. If the session drops, the likely causes are a Redis connection not shared by all replicas or a session secret that differs between instances. Next, confirm sign-out. With Redis in place, sign out on one replica, then present the old token to every other replica and confirm each one rejects it. Without Redis, the scaling guide states that tokens stay valid until they expire, by default after 4 weeks, so a failed revocation test in a Redis-less build is expected behavior that you must document as a risk.

Next, test shared data under contention. Run concurrent writes from several clients, such as creating chats, editing user settings and updating a model preference, against all replicas at once. Watch PostgreSQL connection counts, lock waits and application error logs. The goal is to find dropped writes, duplicated records, or errors that show up only under concurrency. For knowledge, upload a document through one replica and then query the knowledge collection through each of the others. Confirm the file is reachable from every replica and that retrieval returns the same results. If a replica cannot read the file, shared storage is not mounted consistently. If retrieval differs, check that every replica points to the same external vector database rather than a local default.

Then restart one replica while a steady load is running and watch websocket behavior. Clients connected to that replica should reconnect to another replica and resume streaming responses. Record how long reconnection takes, whether any in-flight generation is lost, and whether users see a clean error or a silent hang. Confirm the restarted replica rejoins the pool and serves new requests. Also confirm the load balancer's health check marks the replica unhealthy during the restart, so traffic is not sent to a process that is still starting. Treat the observed reconnection time as a baseline to compare against your own requirements, not as a target taken from the vendor.

Include a negative test. Stop Redis, then stop PostgreSQL in a separate run, and confirm that the application fails in a visible and controlled way. Users should see a clear error or status message, the application should not accept writes it cannot persist, and logs should name the unavailable dependency. Restore the dependency and confirm service resumes without a manual rebuild. Repeat the full test plan after every upgrade, since release changes can alter session handling, migrations or dependency requirements. Write the scripts against the exact version in use, and record that version alongside each test result so later runs can be compared.

What to monitor, back up, upgrade and document after go-live

A high availability cluster is only as dependable as its shared components and the records that describe them. The cards below cover what to watch, how to back up state consistently, how to plan upgrades and what to document so a failover can be run by an engineer who did not build the system.

Replica and load balancer health

Each Open WebUI replica should pass a health check at the load balancer, and a failing replica should leave the rotation without taking healthy peers down with it. Track error rates and latency per replica rather than only the pool average, because one degraded replica can hide behind healthy ones. Confirm with your load balancer vendor how websocket connections and session affinity behave when a replica is removed, and test that behavior during a planned drain.

PostgreSQL and Redis availability

PostgreSQL is the shared database for every replica, so watch open connections against the server limit, lock waits and, if you run standby nodes, replication lag. Redis holds sessions, websocket connections and application state. Without it, signing out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. Treat Redis unavailability as a security event as well as an outage, and alert on it immediately.

Vector store and shared storage capacity

The scaling guide warns that the default ChromaDB will crash in multi-process setups, so the external vector database needs its own health checks, index growth tracking and version pinning. Shared file storage holds uploads and knowledge documents that every replica must reach. Track free capacity and inode counts, not only total size, because a full volume produces failed uploads that users will report as application bugs.

Consistent backups across three stores

Back up PostgreSQL, the vector store and file storage on one schedule, and take them as close to the same recovery point as your storage tooling allows. A PostgreSQL backup alone does not restore knowledge bases if vector or file state is out of step, because the database can reference chunks or files that no longer match. Test a full restore into an isolated environment, and confirm with each storage vendor how consistent snapshots are taken.

Upgrades with a tested rollback path

Open WebUI publishes releases frequently. The v0.12.x line shows the cadence, with v0.12.0 on October 10 and v0.12.3 on October 16, 2026. Stage each upgrade against a copy of production data, run the database migration there, and keep the previous image and a fresh database backup ready for rollback. Confirm the exact database migration behavior between your current and target versions in the release notes before scheduling the change.

Topology, secrets and failover runbooks

Record the replica count, load balancer configuration, and the PostgreSQL, Redis, vector store and storage endpoints, including which network zone each sits in. Name an owner for every secret, such as database credentials, Redis credentials, vector store keys, storage keys and the application signing key, and state how each one rotates. Write failover runbooks that a second engineer can follow during an incident, and rehearse them before you need them.

Questions teams ask before running Open WebUI on several replicas

How much does it cost to run Open WebUI on several replicas?

Cost depends on the scope of work and the platforms you run, so no single figure applies. The one-time work covers design, building PostgreSQL, Redis, shared storage and an external vector database, identity integration, load and failover testing, and documentation. Recurring costs cover the infrastructure for those services, monitoring, upgrades, on-call staffing and any support retainer. Model and GPU or API spend is separate. Costs rise with the number of replicas, the number of users, storage size, the identity integration, and whether you build the database and Redis layers yourself or use managed services. Ask any quote to itemize DeployOpen fees, your internal staff time, and each infrastructure component so you can compare it with your own estimate.

How long does a high availability Open WebUI setup take to build?

The duration depends mainly on scope, so ask for a timeline tied to a written scope rather than a generic estimate. A deployment that reuses existing PostgreSQL, Redis and shared storage with a standard identity provider takes far less time than one that adds a new vector database, a custom load balancer, SCIM provisioning and a migration from an earlier single-container install. Failover testing and a period of load testing usually take longer than the initial installation, and they are the steps teams most often shorten. Confirm with your platform team how quickly they can provision the database, cache and storage, because those dependencies often set the pace of the project.

What does our team need to provide before an Open WebUI high availability project?

Your team must provide the platforms and people the deployment depends on. You need an identity provider for OIDC or LDAP sign-in, a PostgreSQL service that is not SQLite, a Redis service shared by all replicas, shared file storage that every replica can read and write, and an external vector database if you use retrieval features. You also need network paths between the load balancer, replicas and those services, certificates, and DNS. Most important is a named owner for operations who will approve changes, receive alerts and decide on upgrades. Confirm access, change windows and backup responsibilities in writing before the work starts.

Can our in-house team run Open WebUI with multiple replicas itself?

Yes, an in-house team can run it if it can do two things reliably: test failover and own upgrades. Failover testing means stopping a replica, a Redis node or a database connection during load and confirming that sessions, websocket connections and uploads behave as expected. Upgrade ownership means testing each new release in a staging environment, checking database migrations, keeping a rollback plan and scheduling the change. The Open WebUI scaling guide warns about specific failure modes, including that the default ChromaDB will crash in multi-process setups and that sign-out does not revoke tokens without Redis. A team that has checked these before go-live is ready to operate the deployment.

Is the free Open WebUI license enough for a multi-replica deployment?

The free license covers the software, but its branding rule still applies at scale. Since v0.6.6, Open WebUI code is distributed under the Open WebUI License. It forbids altering or removing Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written contributor permission. Adding replicas does not change the user count, but a larger user base does. If you plan to white-label the interface or apply custom branding above that threshold, you need an enterprise license, which is quoted after contacting Open WebUI's enterprise sales team with an expected seat count. Have your legal team read the license text against your user numbers.

Do we need an implementation partner for Open WebUI high availability?

A partner is not required, but it can help if your team lacks capacity or wants a fixed scope before committing. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. Whether you choose a partner or build internally, ask for a written scope that lists each replica, dependency, test and handover item, so you can judge the work the same way regardless of who delivers it.

What breaks first when Open WebUI runs without Redis or shared storage?

Without Redis, replicas do not share session, websocket and application state, so users can be logged out, lose live connections or see inconsistent behavior after a request reaches a different replica. Sign-out also fails to revoke tokens, which stay valid until they expire, by default after 4 weeks. Without shared file storage, uploads and knowledge base content are available only on the replica that received them, so users see missing files depending on where their request lands. To check this before go-live, sign in on one replica, upload a document, sign out, stop a replica and confirm that the session, file and token behavior matches what you expect.

How DeployOpen scopes, builds and hands over Open WebUI high availability

DeployOpen plans, builds and documents multi-replica Open WebUI inside your own infrastructure, from the load balancer and PostgreSQL through Redis, shared storage and an external vector database. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Inventory current Open WebUI installs, user counts and whether any still run on SQLite.
Agree the target topology: replica count, load balancer, PostgreSQL, Redis and shared file storage.
Confirm the external vector database choice and the identity provider that will sign users in.

How we build

Deploy replicas through your chosen install path, Docker Compose, Kubernetes with Helm or another method you approve.
Wire every replica to shared PostgreSQL, Redis and file storage, then test session and websocket behavior across instances.
Test failover by stopping replicas and the Redis service, and record how sign-in and token revocation behave.

How we hand over

Deliver the written configuration, network diagram, runbook and the failure-mode checklist for your operations team.
Walk your engineers through restart, scaling, backup and restore procedures in a session tied to the runbook.
Confirm the handover checklist is signed off in writing before the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
Retainers can cover testing of new Open WebUI releases before they reach production replicas.
Ask in the quote which support hours, response expectations and upgrade testing the retainer includes.