Upgrading Open WebUI past v0.6.5 and the license change

The branding clause matters only if you upgrade to v0.6.6 or later. Since v0.6.6, released on April 19, 2025, Open WebUI code is distributed under the Open WebUI License, which forbids altering or removing Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period. Unless you hold an enterprise license or written contributor permission, that restriction applies to you once you cross the threshold. Code through v0.6.5 remains under BSD-3-Clause, so the upgrade is the point where this clause enters your deployment. Confirm the current license text with your legal team before you schedule the upgrade, because the test depends on the wording of the license, not on how the interface looks.

A rolling 30-day window means any 30 consecutive days, not a calendar month, so you need a daily count that looks back a full month at every point. Start by confirming how the license docs define a user. Ask whether accounts that exist but have never signed in count, whether service accounts and API key users count, and whether SCIM-provisioned accounts that are deactivated still count during the window. Then pull the same measure from your identity provider and from Open WebUI's own records for the trailing 30 days, and record the peak. Growth can cross the threshold without anyone noticing, so schedule a recurring check and keep the results with your change records.

Before you upgrade, make one of three decisions for each deployment. You can keep the Open WebUI branding unchanged, which avoids the clause entirely. You can request written contributor permission, but confirm with the project who grants it, what it covers and whether it lasts through future releases. Or you can buy an enterprise license. Because the upgrade changes the terms you run under, record the decision in the change request before the upgrade window opens. If the decision is to stay on v0.6.5 for now, document that as a deliberate choice with a review date, not as a default.

Enterprise licenses allow white-labeling and custom branding, and they include dedicated support options. Pricing is not published. You request a quote by contacting Open WebUI enterprise sales with an expected seat count, so state the number you can defend from the peak rolling 30-day count, not total headcount. Ask the vendor what the license covers, how seats are measured and billed, the term and renewal conditions, which support levels are included, and whether the license applies to future upgrades. Those answers determine whether the cost is one-time or recurring, and they belong in the written scope your team approves before the upgrade begins.

Moving past v0.6.5 is also a moment to decide where Open WebUI keeps its state. The scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, because SQLite does not handle concurrent writes from multiple processes well. If your current installation uses the default SQLite file and you plan to run more than one replica or worker, the database move is a prerequisite, not an optimization. Plan the data migration from SQLite to PostgreSQL as its own step with a rehearsal against a copy of production data, and confirm with your database team who will own backups, failover and connection limits for the new instance.

Multiple replicas also need Redis as a shared state store for sessions, websocket connections and application state. Shared file storage is required as well, so uploads and knowledge documents stay reachable from every replica. Ask your platform team which storage option they will provide for that shared path, and confirm how it behaves under concurrent reads and writes before you point Open WebUI at it. Network file systems vary widely in locking and latency, so test uploads and knowledge ingestion from two replicas at once instead of assuming the volume works because a single replica does.

The default ChromaDB will crash in multi-process setups, according to the scaling guide, so an external vector database is required when you run several workers or replicas. Open WebUI's retrieval features support a range of vector databases, and the choice should be made before the upgrade so that the knowledge base can be re-indexed once. Confirm the engine you select with your knowledge owners, and plan how existing collections will be rebuilt, since embeddings are tied to the vector store that produced them.

Redis has a security consequence that is easy to miss. Without Redis, signing out of Open WebUI does not revoke tokens, which stay valid until they expire, by default after 4 weeks according to the scaling guide. For a company deployment with SSO, a departing employee's session could remain usable for that window after sign-out. Treat Redis as part of your access control design, and test sign-out and session revocation on every replica before go-live.

SQLite is still acceptable in narrower cases. The scaling guide allows it for single-replica deployments, evaluation and small teams, but only when the database file sits on locally attached SSD or NVMe storage rather than network storage. If you keep SQLite for a small internal team after the upgrade, document that decision, confirm the disk type with your infrastructure group, and record when you will revisit it if user numbers or replica counts grow.

Test the upgrade on a copy of production data before you touch production. Open WebUI runs its database migrations when the new image starts, so the schema change happens against your actual users, groups, chats, knowledge base records and model settings, not against a fresh install. Restore a recent backup of your production PostgreSQL database (or the SQLite file, if you run a single-replica evaluation or small-team deployment on locally attached SSD or NVMe storage) into a separate environment. Pair it with a copy of the file storage and the vector database that your knowledge bases use, so retrieval is tested against matching data. Start the target image against that copy, record how long the migration takes and whether it completes, and keep the logs. Repeat the test at least once with a second, fresh copy so you know the result is repeatable.

Once the migration completes, verify the functions your users and administrators depend on. Sign in through each login path you run: local accounts, OIDC or LDAP single sign-on, and authenticator-app MFA where it is enabled. Check that group membership and per-resource permissions still map to the same access, especially for groups provisioned through SCIM 2.0. Run searches against each knowledge base and confirm the results are relevant, since retrieval depends on the vector database and reranking settings. Open a chat against every model connection you use, whether Ollama, OpenAI, Anthropic or an OpenAI-compatible provider, and send a short test prompt to each. Finally, confirm each scheduled job that your version runs, such as cleanup or sync tasks, executes once and produces the expected result. Write these checks down as a sign-off list before the test begins.

When a production upgrade fails, the first decision is whether to roll back the image or restore the database. If the migration did not finish, or the old image cannot start against the new schema, an image rollback alone will not recover the service, and you need the database backup taken before the upgrade. If the migration finished and the old image starts, you may be able to keep the new data and run the previous version, but only if you confirm that the older release reads the new schema. The decision also depends on writes. Any chats, uploads, permission changes or knowledge base edits made after the upgrade may be lost on restore, so record the time of the upgrade and the time of the failure, and tell users which window of changes could be affected. Back up the database, file storage and vector store together, so a restore brings back a consistent set.

Before you plan a rollback, confirm the supported downgrade behavior for your target version with the Open WebUI project. Migrations are not always reversible, and the project's documentation or release notes for your version should state whether a downgrade is supported and which schema changes block it. Check the GitHub releases page for the versions you are moving between, and ask the project or your enterprise support contact directly if the notes are unclear. Also confirm which license terms apply to each release you pin, since the move past v0.6.5 changes the branding clause and the user threshold. Keep the previous image digest and the pre-upgrade backup until the new version has run in production for a period your change board accepts. A DeployOpen scope for this work would normally cover the test environment, the test plan, the rollback runbook and the restore drill, and the quote should list who runs each step and who reviews the results.