2026 Open WebUI 0.13.0: What to Check Before Upgrading?

Your Open WebUI upgrade is ready, but a routine image replacement could leave the database migration or other instances out of step.

Fastest safe path: You can upgrade to Open WebUI 0.13.0, but back up first, check the release notes, update every instance together if you run multiple instances or workers, and verify your team’s workflows afterward. Confirm that your team is ready for the documented interface and default-behavior changes before scheduling the change.

This guide is for developers maintaining a single Open WebUI instance who need a backup and validation plan.
It also helps operators coordinate a multi-instance or multi-worker update and check version consistency.
Team leads using tools, terminal features, or sub-agents can use the checks to assess workflow impact before approving the release.

Last updated November 7, 2026. Version details checked against the official v0.13.0 release, official version announcement, and official updating guide. Check those sources again before deployment in case the project has published a correction or a later patch.

Before the upgrade: check the release and your deployment shape

Open WebUI 0.13.0 includes a database migration, according to the official version announcement. That makes this more than a container refresh: your plan needs a recoverable copy of the data and a clear way to tell whether migration finished. The official guidance also calls out coordinated updates for multi-instance and multi-worker deployments. Do not leave a mixture of old and new instances serving requests during the change.

How do you upgrade Open WebUI 0.13.0? Follow the project’s official updating guide for your installation method, after checking the release notes and preparing recovery. The steps are not safely interchangeable across deployments: Docker Compose and Python installations do not necessarily use the same configuration, data locations, or update process.

Start by recording what is actually running, rather than relying on an old deployment note:

• Identify the current Open WebUI version and the image tag or package version that produced it.
• Record whether you use Docker Compose, a single container, or a Python-based installation. Note any custom startup process.
• List the number of application instances and workers, and identify how each instance reaches the database and persistent data.
• Record the environment variables and configuration values that affect database access, storage, authentication, and enabled features.
• Review the v0.13.0 release information for changes that apply to your deployment and note any later official correction or patch before you schedule the work.

For a Compose deployment, inspect the rendered configuration before changing it:

docker compose config

This command renders and validates the Compose configuration; the Docker CLI reference explains its behavior. It is a useful way to catch an unexpected image tag or configuration difference, but it does not prove that the live container is using the configuration you expect. Compare the rendered result with the actual running service and your deployment records.

Does Open WebUI self-hosting change what you need to check? Yes. In a self-hosted installation, you own the recovery plan and must identify the data store and persistent paths used by your deployment. Do not assume that another installation’s directory layout applies to yours.

Before the change: protect data and define your recovery point

What should you back up before an Open WebUI database migration? Protect the database and every persistent data location your deployment relies on, along with the configuration needed to reconnect the service. The exact set depends on your installation; confirm it against your Compose file, environment, and actual storage mounts. The official environment-variable reference can help you identify relevant settings, but it does not replace checking your own configuration.

A backup is not ready just because a backup command completed. Confirm that the resulting files can be read and that you know how to restore them to a compatible deployment. If your recovery plan depends on a database dump, check that the dump can be opened and that the restoration procedure is documented. If it depends on copied files, confirm that the copy includes the data your service actually uses.

Keep the old image tag or package version available until the upgraded application and its data pass acceptance checks. Do not assume that changing the application version alone reverses a database migration. If the upgrade fails after migration begins, stop expanding the change, preserve relevant logs, and follow the project’s database migration troubleshooting guidance. Restore only according to a procedure you have verified for your deployment.

During the upgrade: coordinate instances instead of swapping one at a time

For a single-instance deployment, use the official update path that matches your installation method. For a multi-instance or multi-worker deployment, the official guidance calls for updating all instances in sync. Do not let old and new application instances share traffic while the database is being migrated unless the project’s current instructions explicitly support that arrangement.

During the maintenance window, record when the update starts and what each service reports. Use the deployment’s own process and logs to confirm that the migration completed; do not infer success from a container starting or a login page appearing. If you run several instances, verify each one is on the intended version before returning traffic.

For Compose users, inspect the active services after applying your documented update procedure and compare them with the configuration you reviewed earlier. The Open WebUI scaling guide provides project guidance for scaled deployments. Use it alongside the update instructions rather than improvising a rolling update that leaves different versions active together.

Should all Open WebUI instances be updated together? For multi-instance or multi-worker deployments, yes: the official upgrade guidance says to synchronize the update across all instances. Plan the work so you can account for every worker and service, then verify version consistency before allowing normal traffic.

After the upgrade: verify the migration and the workflows people use

Treat the release as incomplete until you have checked both application health and the data and workflows your team relies on. Compare the result with your pre-upgrade record. A page loading is only one signal; it does not establish that historical data, settings, or integrations are intact.

Use an acceptance pass that matches your deployment:

• Confirm that each application instance starts and reports the intended version.
• Check the migration result in the application output or logs. If it reports an error, stop and follow the official database migration guidance rather than repeatedly restarting services.
• Sign in using a real team account and confirm that expected conversation history and workspace settings remain available.
• Check your knowledge-base data and any other persistent information your team uses.
• Test the model connection and any tools, terminal features, or related workspace actions that are enabled in your deployment.
• Confirm that the team can complete its normal task without relying on a setting or behavior that changed in the release.

The release announcement identifies behavior changes that teams should review, including the location of controls, the handling of tool-call rounds, and default behavior related to sub-agent limits. Those are version-specific notes, not a claim about how every Open WebUI release behaves. Check the v0.13.0 release notes against the features your team actually uses.

What changes to tool calls should you check after the upgrade? Review the version notes for the documented tool-call-round behavior, then test a representative workflow using your own tools and expected stopping conditions. If your team’s instructions assume the previous behavior, update those instructions or the relevant configuration before declaring the upgrade complete.

After acceptance: decide whether the server needs to change

A version upgrade does not, by itself, prove that you need a larger server. Separate the Open WebUI application workload from any model inference service, then review actual resource use during normal team activity and after the update. Look for sustained memory pressure, CPU saturation, storage growth, or network limits in your own monitoring rather than applying an unverified minimum configuration.

Make the capacity decision using observable symptoms:

• If the application remains responsive and resource use has headroom during the workflows you tested, keep the current server and continue monitoring.
• If memory pressure coincides with application or database instability, measure which process is consuming it before choosing a larger memory tier.
• If CPU use rises during model inference, first establish whether inference runs on the same host or through an external service. Do not attribute all CPU load to the Open WebUI application.
• If database or persistent-data growth is the constraint, check free storage and backup requirements before changing disk capacity.
• If multiple services compete for the same resources, isolate their measurements so a server change addresses the observed bottleneck rather than an assumed one.

This is a practical reason to keep a before-and-after record: it helps distinguish an upgrade-related regression from the workload your team already had. For capacity planning, compare your measured usage with the available memory and disk options; for operating boundaries, review the service scope and terms. Neither page substitutes for measuring your specific deployment.

Use this decision branch before changing infrastructure:

• If the migration completed, all instances agree on the version, and your core workflows pass, keep the current server and monitor the workload.
• If the upgrade is healthy but a measured resource bottleneck remains, compare the observed requirement with available server options before moving.
• If the migration or data checks fail, pause capacity changes and resolve the upgrade or recovery issue first.
• If your workload is temporary or light enough for a shared environment, do not rent a dedicated physical server solely for this release.

Once acceptance is complete, decide based on the application, database, and model-service workload you actually run. A shared VPS or cloud instance may be sufficient for a light deployment, but shared CPU contention, uncertain resource isolation, or limits on storage and system control can become poor fits for a steady team workload. If you need dedicated compute and control over the server environment for long-running self-hosted services, an AMD bare-metal server from OSFP Cloud may fit better; check the current configuration and operating-system options rather than assuming a capacity or performance guarantee. You can review the current OSFP Cloud options before comparing them with your measured requirements.