Open WebUI upgrades and support

Who keeps Open WebUI upgrades and support running after go-live

Someone must own every Open WebUI upgrade from the day the platform goes live. That owner is either your own platform team or an implementation partner working under a written scope, and it tests each release, runs any database migration, decides whether to roll back and keeps the service supported. Upgrades recur after go-live. The project's GitHub releases page lists v0.11.0 in July, then v0.12.0 on October 10 and v0.12.3 on October 16, 2026, so a team that deploys once and waits will fall behind quickly. Before launch, ask who reads each release note, who approves the change and who is on call when a new version breaks sign-in or chat.

Four situations usually call for outside help. The first is a release that carries a database migration your team has not rehearsed against a copy of production data. The second is a version that has fallen several releases behind and must be moved forward across multiple changes at once. The third is a go-live with no named owner for upgrades, which is common when the rollout project closes and the people who built it move on. The fourth is growth from a single container to several replicas, because the scaling guide requires PostgreSQL, Redis and shared file storage in that case, and each upgrade must keep those components aligned. Any of these should trigger a formal decision, not an informal one.

The short answer on in-house versus partner depends on time and evidence. Keep upgrades in-house when a named engineer has protected time each release cycle, a staging environment mirrors production, and the team can read migration notes and check services after a change. A partner suits the case where nobody holds that time, where the platform supports regulated workloads and each change needs documented evidence, or where a major release lands during a fixed deadline. A hybrid model is also common: your team applies routine releases and a partner handles migrations and rollback planning. Whichever model you pick, write down who holds each step.

Each upgrade touches two layers at once. Data changes through database migrations in PostgreSQL or SQLite, while running services depend on Redis for sessions and websocket state, on an external vector database and on shared storage for uploads and knowledge. Redis also matters for access control. Without it, signing out does not revoke tokens, which remain valid until they expire, by default after 4 weeks. After every upgrade, confirm that sign-out still revokes tokens across all replicas and that uploads and knowledge stay reachable from each one. These checks belong in the upgrade runbook, not in someone's memory.

Before go-live, record the upgrade owner, the release review cadence, the staging environment, the backup point taken before each migration and the rollback path in writing. When you request a quote from any partner, ask who tests each release, who takes and verifies the database backup, who signs off the change and what support covers after a failed upgrade. Check the migration notes for every release you plan to adopt with the Open WebUI project and confirm which of your environment's components each note affects.

What an Open WebUI upgrade and support engagement includes

An upgrade engagement covers the one-time work of moving a live Open WebUI deployment to a newer release without losing data or access. Ongoing support covers what happens between upgrades, and it is offered as a retainer. Every item below is written into the scope agreed before work starts.

Release review against the changelog

Before any change, the team reads the release notes for every version between the current install and the target, including breaking changes, deprecated settings and environment variables that changed. The output is a written list of what affects this deployment, such as model connection settings, authentication options or retrieval configuration. Confirm with the client which features are in use, because those decide which changes matter.

Test upgrade in a staging copy

The upgrade is first run against a staging copy built from a recent production backup, with the same database engine, Redis, vector database and storage layout. This shows whether the new release starts, serves existing chats and reaches every model provider before production is touched. Staging should match production closely enough that its results can be trusted, so differences in topology are documented.

Database migration verification

Open WebUI applies schema changes when a new version starts, so the engagement checks that migrations complete on a copy of the real data. Row counts for users, chats, groups and knowledge collections are compared before and after, and any migration errors are logged. Confirm which database engine the deployment uses, since the scaling guide requires PostgreSQL for multi-instance installs.

Production upgrade window

The production change runs inside a window agreed with the client, with a named owner for go or no-go decisions and a defined set of checks to pass before users return. The team records the exact versions, image digests or package versions deployed. The window length and approval steps are set in the written scope, not assumed.

Rollback rehearsal

The rollback path is tested before the production window, not described only on paper. The team restores the pre-upgrade backup into a scratch environment, confirms the previous version starts against it, and times the steps. Note that a database migration may not run backward, so the restore point and the data written after it must be understood by the client.

Runbook updates and handover

The operating runbook is revised to reflect the new version, changed settings, updated container images or Helm values, and the rollback steps that were rehearsed. The client's operators receive the updated documents and a walkthrough. Clients should confirm who keeps the runbook current after handover.

Post-upgrade checks of integrations

After go-live, the team verifies that model connections to Ollama or OpenAI-compatible providers respond, that OIDC or LDAP sign-in and group mapping still work, and that retrieval returns results from the vector database. These checks are run with test accounts and documented with pass or fail results. Any failed check is recorded as an open item with an owner.

Ongoing support under a retainer

Between upgrades, a retainer can cover monitoring, response to reported issues and scheduled upgrade cycles that follow the project's release cadence. Support is a recurring cost, separate from the one-time upgrade fee, and its response expectations are defined in the written agreement. Ask what the retainer excludes, such as model or GPU costs and changes to customization.

How the Open WebUI release cadence changes your upgrade plan

Plan upgrades on a fixed calendar, not release by release. The project published v0.11.0 in July, then v0.12.0 on October 10 and v0.12.3 on October 16, 2026, all on its GitHub releases page. A patch release arriving six days after a minor release shows why waiting for news before acting is a weak plan. Set a recurring review window, for example once a month or once a quarter, and decide in advance who reviews the releases published since the last window, who signs off and who schedules the change. Without that calendar, an instance can drift several versions behind while teams assume someone else is tracking the project.

A frequent cadence also means you will not adopt every release, so write a skip policy. A common approach is to target a minor version and wait for its first patch releases before moving production, while security fixes get a shorter path. The policy should name the trigger for an exception, such as a vulnerability advisory or a provider API change that breaks your model connections. Record each skip decision with the version, the reason and the date you will reconsider it, so the choice is visible to auditors and to the next person who inherits the instance.

Every release you do adopt needs its own test cycle in a staging instance. Restore a recent copy of your production database, then check sign-in through your identity provider, group and role mappings, model provider connections, knowledge bases and retrieval results against the vector database you run. If you operate several replicas, confirm that Redis and shared file storage behave the same after the upgrade. Define pass and fail criteria before the test starts, and keep the rollback path (a database backup and the previous image tag) ready until the new version has run cleanly in production for an agreed period.

Read the release notes for every version between your current release and your target, not only the latest one, and confirm them yourself against the GitHub releases page before each change. Release notes are the only reliable place to find database migration steps, configuration changes and removed settings, so do not apply an upgrade automatically. Licensing also needs a check at each step. Code through v0.6.5 remains BSD-3-Clause, while code from v0.6.6 (April 19, 2025) falls under the Open WebUI License, which restricts altering branding in deployments above 50 users in any rolling 30-day period unless you hold an enterprise license or written contributor permission. Confirm your licensing position with your legal or procurement team before you move to a new version, and ask Open WebUI enterprise sales to confirm how the current terms apply to your user count.

What drives the cost and duration of upgrades and support

This table lists the factors that change how much effort an Open WebUI upgrade or support arrangement takes. Read each row as a question to answer about your own deployment before you ask for a quote. The main takeaway is that multiple replicas, identity integration and compliance evidence add the most work, so keep the topology and integrations as simple as your requirements allow.

Driver	Why it raises effort	How to keep it down
Replica count and load balancer	Each replica is upgraded and checked in turn, and user sessions must survive a node being drained.	Run the fewest replicas your load requires, and write a rolling upgrade order before the first release.
Database engine	SQLite on one host is simple to upgrade, but multi-instance setups need PostgreSQL, which adds a database migration to test and roll back.	Complete any SQLite to PostgreSQL move as a separate project, then upgrade on the new engine.
Redis and shared storage	Redis holds session and websocket state, and shared storage keeps uploads reachable, so both need checks around every release.	Confirm Redis and file storage are healthy before and after each upgrade, and back up both.
External vector database	The default ChromaDB crashes in multi-process setups, so an external store adds a second system to upgrade, back up and monitor.	Choose one supported vector database early, and pin its version alongside Open WebUI.
Model providers, tools and functions	Each provider connection, tool or function can break on a new release and needs its own regression test.	Keep a short list of approved providers and tools, and test only those on each release.
Number of environments	Each environment, such as test, staging and production, repeats the upgrade, and configuration drift makes failures harder to trace.	Build environments with the same install method, and promote the same version through each one in order.
Identity integration complexity	OIDC or LDAP, SCIM 2.0 provisioning and MFA each depend on the identity provider, so a release can change sign-in or group mapping.	Document the identity settings, then test sign-in, group mapping and provisioning after every upgrade.
Compliance evidence needs	Assessors may ask for change records, test results and rollback proof, which adds documentation work to every release.	Agree the evidence list before the first upgrade, and build it into the standard upgrade runbook.
Gap between current and target version	A large version gap crosses more database migrations and changed settings, all of which must be tested in one window.	Upgrade in small steps on a regular schedule, and read each release's notes before testing it.

How an upgrade moves from release review to post-upgrade support

The sequence turns a planned Open WebUI version change into a tested, reversible production change with signed-off evidence and a clear handover into ongoing support. Each phase produces an artifact the next phase depends on, so no step is skipped under schedule pressure. The length of each phase depends on the drivers listed in the written scope.

Take inventory of the current version
The team records the Open WebUI version in production, the install method (Docker, Docker Compose, Helm or pip), the database backend, the vector database, the Redis and shared storage setup where they exist, and the identity and provider connections in use. DeployOpen works from that inventory with the client's platform owner. The step closes with an inventory record that names every component the upgrade could touch, so nothing is discovered for the first time during the change window.
Capture the configuration and data baseline
Configuration, environment variables, custom model settings, group permissions and knowledge base contents are exported or snapshotted, and the database and file storage are backed up. The team confirms the backup can be restored into an isolated environment, not just that a backup job reported success. The output is a configuration baseline and a backup verified for restore, which become the reference points for every later comparison.
Review the release and run gap analysis
The target release notes, including any database migrations between the current and target versions, are reviewed against the client's configuration and enabled features. Gap analysis lists deprecated settings, changed defaults, dependency changes for the chosen install method and any features the organization uses that the release affects. Open WebUI releases arrive often, so the review covers every version between current and target. The output is a gap register with an owner and a decision for each item.
Rehearse the upgrade in staging
The upgrade is applied to a staging copy built from the production backup, with the same install method, database, vector store and identity settings. The database migration is run and timed, and the team checks chat history, knowledge bases, users, groups, API keys and model connections. Any failed migration, data mismatch or configuration drift is logged and fixed in the runbook. The output is a tested runbook with recorded results from each run.
Rehearse the rollback path
The team practices returning the staging environment to the previous version from the verified backup, including any database step that cannot be reversed by reinstalling the old image. It checks that users can sign in again, that sessions and tokens behave as expected and that stored data reads correctly after restore. The output is a rollback procedure with a recorded rehearsal and a named decision owner for invoking it during the change window.
Execute the production change window
The approved runbook is executed in the agreed window with a fresh backup taken immediately beforehand. The team follows the recorded steps in order, logs each command and checkpoint, and stops at any defined failure gate to decide between fixing forward and rolling back. Users are notified before and after the window. The output is a signed-off change record that lists what was run, when, by whom and what was observed.
Verify the upgraded system after go-live
Post-upgrade checks confirm sign-in through the configured identity provider, model connections and responses, retrieval against the knowledge base, group permissions, API key access, file uploads and any scheduled jobs. Logs are reviewed for migration warnings and errors. The team compares results against the configuration baseline from the earlier step. The output is a verification report that either closes the change or records open items with owners.
Hand over into the support cycle
The updated runbook, change record, verification report, backup schedule and open items are transferred to the operating team, and the agreed support scope is confirmed in writing. The handover states who monitors releases, who approves the next upgrade and how security advisories are tracked. Whether support is provided through a retainer or handled internally is agreed in the written scope. The output is a handover record that starts the next upgrade cycle from a known baseline.

Which parts of Open WebUI upgrades your team keeps and which it outsources

An Open WebUI upgrade touches the release process, the database, shared state, the container platform, identity settings and the recovery path at once. Most teams keep the decisions that carry business risk and outsource the hands-on engineering that needs deep, repeatable skill. The cards below show where that line usually falls and what the internal owner must still sign off.

Release monitoring and triage

Someone must watch the Open WebUI releases page, read each release note and decide which versions are worth testing and when. Teams usually keep the approval decision in-house because it depends on their feature needs and risk appetite, and outsource the routine reading and impact summary. The internal owner still sets the upgrade window, the acceptance criteria and the cutoff for skipping a release. Confirm who receives alerts when a release touches authentication, storage or the license.

Staging and test automation

A staging copy of production needs the same PostgreSQL version, Redis, shared storage, model connections and identity settings as production, with test data that reflects real usage. Teams often outsource building the scripted smoke tests and the environment, then run them in-house before each change. The internal owner must define pass and fail criteria, such as login, model response, file upload and knowledge retrieval. Ask who maintains the tests as the interface changes between versions.

Database and migration work on PostgreSQL

Each Open WebUI release can run schema migrations against PostgreSQL, and a failed migration is the most common reason an upgrade needs rollback. Outsourcing the preparation work, including a verified dump, migration dry runs and lock and duration checks, usually reduces risk. The internal owner should approve when the migration runs and who may stop it. Confirm how long the production database is unavailable during migration and whether replicas need a coordinated restart.

Redis and shared storage operations

For multiple replicas, Redis holds sessions, websocket connections and application state, and shared file storage keeps uploads and knowledge reachable from every replica. Upgrades can change how these components are read or written, so a mismatch can cause sign-out loops or missing files. Teams commonly keep day-to-day operation in-house and outsource the upgrade-specific checks. The owner must decide the Redis persistence and eviction settings, and confirm that token revocation still works after the change.

Container and Kubernetes deployment changes

Upgrades change image tags, Helm values, environment variables and sometimes resource requests or probes. Teams with an existing platform team usually keep routine image promotion in-house and outsource chart changes that need custom values or new configuration keys. The internal owner must approve the pinned image version, the rollout strategy and the rollback image. Check whether the deployment uses a floating tag, because an unpinned tag makes upgrades happen without a review.

Identity and provider reconfiguration

A release can change how OIDC, LDAP, SCIM provisioning, group role mapping or model provider connections behave, and each change can lock users out or expose a provider key. Outsourcing the reconfiguration and regression checks is common, while the identity owner keeps approval of role mappings and access scope. Confirm which settings are stored in the database and which come from environment variables, since that determines whether a rollback restores them.

Rollback and backup verification

A rollback is only as good as the last restorable backup, and a database restored to an older schema may not match an older application image. Teams often outsource the rehearsal of restore and rollback steps, then keep the decision to roll back in-house. The internal owner must set the recovery point and recovery time targets and sign off the restore test evidence. Ask whether backups include the vector store and shared file storage, not only PostgreSQL.

On-call response during and after upgrades

Post-upgrade issues often appear hours or days later, when a particular model, group or background job is first used. Outsourcing on-call coverage through a support retainer is common for teams without 24-hour staff, while incident command usually stays with the internal owner. The owner must define severity levels, escalation contacts and the authority to roll back without further approval. Confirm the response times in writing before go-live, since no standard response times are assumed here.

What recurs after go-live when you run Open WebUI upgrades and support

This table lists each cost component that continues after an Open WebUI rollout goes live, who is paid for it and what drives it up or down. Use it to separate one-time project work from ongoing spend, then ask each vendor or partner to price the recurring items separately. Most of the long-term cost sits in people's time for testing and approving releases, plus the infrastructure that keeps staging and backup copies current.

Cost component	One-time or recurring	What drives it	What to ask for in a quote
Staging and backup infrastructure	Recurring	A staging copy must mirror production's database, Redis, shared storage and external vector database to test upgrades meaningfully	Itemized hosting for staging, backup storage and retention period, in your own cloud account or data center
Enterprise license decision	Recurring if chosen	Required for white-labeling or removing branding in deployments above 50 users in a rolling 30-day period, or where dedicated support matters	Written confirmation of the expected seat count used for the quote and the renewal terms
Support retainer scope	Recurring if chosen	Number of supported versions, response expectations, hours of coverage and whether upgrades are included	Defined list of covered components, escalation path, and what is excluded from the retainer
Upgrade cycles	Recurring	Open WebUI ships releases frequently, such as v0.11.0, v0.12.0 and v0.12.3 in the project's own release history, and each one needs review	How many upgrades per year the retainer covers and whether database migration testing is part of each one
Database migration testing	Recurring	Schema changes between releases must be rehearsed against a copy of production data before a live upgrade	Test environment size, the restore procedure used to rehearse, and the rollback plan written for each upgrade
Internal release review skills	Recurring, staff time	Someone must read release notes, check breaking changes and approve or defer each change against your own policies	Which roles your team needs, how much of their time the review takes, and whether the partner provides written release summaries
Monitoring and incident handling	Recurring	Session, websocket and provider connection health must be watched across replicas, and failures need an owner	Monitoring tools covered, on-call responsibilities and who receives alerts outside working hours

How upgrades differ by starting point and environment

A single container with its database file on locally attached SSD or NVMe is the simplest starting point. The scaling guide accepts SQLite only for a single replica, evaluation or a small team, and only when the file sits on local storage rather than network storage. Upgrades here center on one data volume, because a release can change the database schema at startup.

Test scope: start the new image against a copy of the production volume, let the migration run on that copy, then check sign-in, chat history and knowledge files.
Rollback: stop the container, restore the pre-upgrade volume snapshot and pin the previous image tag. Confirm with the vendor whether a schema change can be reversed before you rely on that step.
Evidence: record the image digest, the checksum of the volume backup and the migration log from the upgrade window.
Storage check: confirm the volume is still on local disk after any host rebuild or storage change.
Growth trigger: a second replica or a larger team means moving to PostgreSQL. That move is a separate engagement with its own scope and test plan.

Before the upgrade window opens, confirm the backup restores on a clean host.

What goes wrong during Open WebUI upgrades and how to prevent it

Open WebUI upgrades tend to fail in four places: the database, the shared state, the search index and the license terms. Each card names one failure, the step that prevents it and the rollback point you should be able to confirm before you start. If you cannot confirm the rollback point, treat that as a reason to pause the change.

Upgrading without a verified backup

Each release can change the database schema, so a failed upgrade may leave user data and settings in a state the previous release cannot read. Before any version change, back up the PostgreSQL database, the shared file storage that holds uploads and knowledge, and the environment and configuration values. Restore the backup into a separate instance and open a sample chat and a knowledge file to confirm it works. Rollback point to confirm: the restored backup starts on the previous release version.

Migrations that fail on production data

Database migrations run against the data your users have already created, so a migration can pass on a small test instance and fail on one with long chat histories, large knowledge bases or many accounts. Skipping the rehearsal removes the chance to find this before users are affected. Run each target version against a recent copy of production data, record how long the migration takes and log any errors before scheduling the change. Rollback point to confirm: the copy returns to its pre-upgrade state after each rehearsal so the test can be repeated.

Replicas running mixed versions

In a multi-replica deployment behind a load balancer, a rolling change can leave some instances on the old release and others on the new one for a period. Mixed versions can read shared state or schema in ways that neither version was tested for. Drain one replica at a time, upgrade it, check health and sign-in, then move to the next, and confirm the migration has run once before the first upgraded replica takes traffic. Rollback point to confirm: every replica is back on one recorded image tag.

Sessions outliving sign-out without Redis

Without Redis, signing out of Open WebUI does not revoke tokens. They stay valid until they expire, which by default is 4 weeks, so a sign-out on a shared or lost device does not end access. Deploy Redis as the shared state store before running more than one replica, and test sign-out from two replicas to confirm the session ends on both. Rollback point to confirm: after a rollback, sign-out still revokes sessions on every instance and the Redis connection settings match the earlier configuration.

External vector database out of step

The scaling guide warns that the default ChromaDB crashes in multi-process setups, so an external vector database is required when running several workers or replicas. A release can change how collections and indexes are created or queried, so check the target release notes against your database version. Confirm your chosen database is one of the 13 that the retrieval features support, snapshot the index, and reindex a test knowledge base before production. Rollback point to confirm: the snapshot restores and a fixed set of test questions returns the same results.

Branding changes without a license check

Since v0.6.6, released April 19, 2025, Open WebUI code is distributed under the Open WebUI License. The license forbids altering or removing branding in deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written contributor permission. Check the user count and the license position before any upgrade that changes logos, names or footers, because a custom theme carried through an upgrade can change branding without a decision. Rollback point to confirm: the license position is recorded for the target version and the branding files return to their approved state.

What your team must provide before an Open WebUI upgrade starts

An Open WebUI upgrade cannot be scoped or started until your team has supplied the inputs below. Most delays on upgrade work come from missing access, an untested backup or an unnamed approver, not from the upgrade itself. Ask for this list in writing before a fixed-scope upgrade is agreed, because each item changes what the partner can verify and how long the work takes.

Start with access to the running environment and its deployment definitions. The partner needs the Docker Compose files, Helm values or equivalent definitions for the install method you use, along with the running configuration of the Open WebUI container or pods, the database, any Redis instance and the vector store. Read access to logs and release history is also required, so the partner can compare the current version against the target release and see errors that appear during previous upgrades. Confirm whether these logs are retained long enough to cover the last few release cycles, since the project has shipped several releases in a short period.

Next, provide a current backup and a restore test record. A backup that has never been restored is not a rollback plan. The record should show which database was backed up (SQLite file or PostgreSQL), when the backup was taken, where the uploaded files and knowledge base storage were copied, and the date and result of the most recent restore into a separate environment. Also provide a staging environment that mirrors production in version, database engine, Redis configuration, vector database and storage layout. An upgrade tested on a single-container SQLite staging instance will not predict how a multi-replica production deployment behaves. Confirm the differences in writing if the two cannot match.

Identity and model provider configurations are the next input. Supply the settings for the OIDC or LDAP connection, any SCIM provisioning, and the connections to Ollama, OpenAI or other OpenAI-compatible providers, but do not paste secrets, client secrets, API keys or tokens into tickets or chat threads. Share the configuration structure and reference the secret names in your secret management system. The partner should receive access to inject or read those values through a controlled path that your team owns. Name the owners who approve the upgrade, the person who can sign off acceptance criteria, the on-call contacts for the change window, and the decision maker for scope. Finally, agree on the change window, the acceptance criteria that define a successful upgrade, and which target versions are in scope. Confirm with the project's release notes which versions you intend to move through, and whether any intermediate releases need to be applied first.

Common questions about Open WebUI upgrades and support

How much does an Open WebUI upgrade cost?

There is no fixed price for an Open WebUI upgrade. Cost follows from the written scope, and the main drivers are the deployment shape, the database and vector store in use, the number of environments that need testing, and how many custom functions, tools and model connections must be checked after the move. A single Docker container with SQLite is a smaller job than several replicas with PostgreSQL, Redis and shared file storage. Most of the work is one-time: planning, staging, cutover and verification. Ongoing upgrades can recur through a retainer. In a quote, ask for the versions covered, the environments, the test plan, the rollback steps, who performs cutover, and what happens if verification fails. DeployOpen does not publish a price list. A quote follows from the scope agreed in writing.

How long does an Open WebUI upgrade take?

The duration depends on how many releases separate your current version from the target, how complex your deployment is, how much data the migration touches, and how much custom configuration needs retesting. Open WebUI ships often. According to the project's GitHub releases, v0.11.0 arrived in July, v0.12.0 on October 10, and v0.12.3 on October 16, 2026. Jumping several versions means reading more release notes and running more checks, so the work usually takes longer than a single-step move. No duration applies to every environment. Ask for a schedule in the quote that lists staging, the maintenance window, cutover, verification and the post-upgrade observation period, and confirm which of those steps your own team will perform.

Can our own team upgrade Open WebUI without outside help?

Yes, a team with Docker or Kubernetes experience can often upgrade a simple single-container install, provided it takes a verified backup, tests on a copy of production data and reads each release's notes. The work gets harder once Open WebUI runs as several replicas. The scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, Redis for shared state, shared file storage and an external vector database, because the default ChromaDB will crash in multi-process setups. Each of those components changes the upgrade order and the failure modes. Decide based on who owns the rollback, whether staff can test sign-in and retrieval after each change, and who is on call during the window. A review of your plan by an outside party is also an option.

What must we provide before an Open WebUI upgrade starts?

Start with access, then with the facts about your current system. Typical inputs:

Access to the current environments, container or Helm configuration and secrets handling
A recent backup of the database and uploaded files, with confirmation that it restores
The current version, install method and any custom tools, functions or model presets
The identity provider, model provider connections and vector database in use
A staging environment that can hold a copy of production data
Named owners for approvals, maintenance windows and sign-off

Agree these inputs in the written scope. Missing backups and undocumented configuration usually cause the most delay, so check them before a date is set.

How does rollback work after a failed Open WebUI migration?

Rollback depends on a backup taken before the upgrade, and that backup has to be tested. Database schema changes between releases may not reverse cleanly, so the usual route is to restore the database snapshot and file storage that matched the previous state, then run the previous image or chart version. Practice this in staging before production cutover. After a restore, check how sign-in behaves. Without Redis, signing out does not revoke tokens, and tokens stay valid until they expire, by default after 4 weeks. The rollback plan should name the decision point for rolling back, the person who makes that call, the restore steps in order, and the checks that confirm the service works again. Ask for this plan in writing before the upgrade.

Does an enterprise license change Open WebUI upgrade support?

An enterprise license changes the branding terms and the vendor support available to you. Under the Open WebUI License, deployments that exceed 50 users in any rolling 30-day period may not alter or remove Open WebUI branding unless the operator holds an enterprise license or written contributor permission. Open WebUI's enterprise licenses allow white-labeling and custom branding, with dedicated support options. Pricing is not published and is quoted after contacting enterprise sales with an expected seat count. The license does not set the scope of upgrade work from an implementation partner. That scope is defined in the written agreement, so confirm with both parties which support tasks each covers.

How often should we upgrade Open WebUI?

There is no universal schedule, so choose one your team can test. Open WebUI publishes releases frequently: v0.11.0 in July, v0.12.0 on October 10, and v0.12.3 on October 16, 2026, according to the project's GitHub releases. Read the release notes for each version and treat security fixes as a priority. Many teams pin a tested version in production, test new releases in staging on a regular rhythm, and avoid letting the gap grow so large that one upgrade covers many releases. Set the cadence by your test capacity and your exposure. Ask a partner to propose a cadence in the scope, including who reviews release notes, who tests, and how the go or no-go decision is made.

What does ongoing Open WebUI support cover after go-live?

Ongoing support is typically offered as a retainer, and its coverage is set by the written agreement. Common tasks include monitoring the deployment, reviewing new releases, testing and applying upgrades, checking backups and restores, and handling incidents within the agreed scope. The agreement should state who is responsible for each task and what counts as an incident. Ask for response expectations, change windows, whether the retainer includes upgrades or only advice, and how custom tools and functions are treated. Also confirm whether you need vendor support from Open WebUI enterprise alongside the retainer, since the two may cover different issues. Support does not promise outcomes beyond what the agreement describes.

How DeployOpen scopes, delivers and supports Open WebUI upgrades

DeployOpen treats each Open WebUI upgrade as a planned change to your own infrastructure, not a routine container pull. We agree the scope in writing, test the target release against your models, identity setup and database, then hand over runbooks and rollback steps before support begins.

How we scope

Inventory your current version, install method, database, vector store and any Redis or shared storage in use.
Confirm which target release you need and why, given that the project publishes releases frequently.
Agree in writing which providers, groups, tools and integrations are in and out of the upgrade.

How we build

Stand up a staging copy of your production configuration in your own environment before touching live data.
Test database migrations between releases on a restored copy and record the time and any errors.
Run regression checks on sign-in, model connections, permissions and knowledge base retrieval before approval.

How we hand over

Deliver a written upgrade runbook with pre-checks, the migration sequence and go or no-go criteria.
Document the rollback plan, including how the database backup is restored if a release fails.
Walk your operators through the procedure so they can repeat it without DeployOpen present.

How we support

Ongoing support covers upgrade planning, testing and go-live assistance for later releases.
Support is available as a retainer, with the covered systems and response expectations agreed in writing.
Ask any support provider to confirm which Open WebUI versions and install methods they cover.