2026 Open WebUI 0.13.0 升级前要检查什么？

升级后容器能启动，却发现历史会话或知识库不可用——这类问题不能靠重新拉一次镜像解决。
判断框｜适合升级：先备份，再核对迁移与新版本行为；多实例或多 Worker 要按官方要求协调更新所有实例。不适合直接换镜像：尚未确认备份可恢复、无法安排更新窗口，或团队还没评估工具调用与子 Agent 默认限制变化。

维护单实例的开发者，可以按本文准备备份、更新和验收。
负责多实例或多 Worker 的运维人员，应先安排协调更新并确认版本一致。
使用工具、终端或子 Agent 的团队负责人，还要先判断新行为是否符合工作流。

升级前：核对版本变化，而不是只改镜像标签

截至 2026 年 11 月 7 日，官方发布页将 v0.13.0 列为最新版本；该版本于 2026 年 11 月 3 日发布。官方更新文章说明本次含数据库迁移，并要求升级前备份；混用不同版本的 Worker、服务器或负载均衡实例可能出错。发布前仍应重新查看官方发布记录和官方版本说明，确认是否有补丁或更正。

怎样判断这次 Open WebUI 0.13.0 升级是否能直接安排？先记录当前版本、镜像标签或 Python 安装方式、实例数、Worker 设置，以及数据库和文件存储的实际位置。别把镜像名里的 latest 当作当前运行版本；检查正在运行的容器和部署配置，才能确认回退时要恢复什么。

如果你用 Docker Compose，可先查看配置解析出的镜像：

docker compose config --images

输出示意：

<当前 Open WebUI 镜像及版本标签>

这条命令用于解析 Compose 配置中的镜像，具体结果取决于你的配置文件；可对照 Docker Compose config 命令说明确认用法。再按你的部署方式核对容器挂载、环境变量和 Worker 数量。例如，下面只用于查看容器实际挂载，不代表所有安装都把数据放在同一个卷：

docker inspect <容器名> --format '{{json .Mounts}}'

Open WebUI 自托管的数据库迁移为什么要特别检查？迁移会改变数据库结构；官方更新指南指出，数据库迁移是单向的，单纯把镜像标签改回旧版，不会把数据库结构倒回去。若新版本已完成迁移而应用异常，通常需要恢复升级前备份，而不是只重启旧镜像。请以官方更新指南中的当前说明为准。

备份阶段：保护数据，也准备可执行的回退

Open WebUI 数据库迁移前要备份哪些内容？按当前部署逐项列，而不是照抄一份假设所有人都使用同一目录的清单：

• 持久化目录或 Docker 卷中实际保存的数据库、上传文件、知识库文件和其他应用数据。
• 如果使用外部数据库、向量库、对象存储或共享文件系统，分别使用对应服务的备份方法；应用卷备份不等于这些外部数据已备份。
• 当前镜像标签、Compose 配置、关键环境变量和密钥的安全副本。敏感配置应放在受控位置，不要把密钥连同日志或备份公开分享。
• 升级前运行状态：实例数、Worker 数、健康检查结果、登录方式，以及团队依赖的模型连接、工具和知识库流程。

官方文档给出了 Docker 卷备份与恢复示例，但你的数据布局如果不同，不能直接套用示例中的卷名或恢复路径。对数据库采取与实际数据库类型相符的备份方式；升级前确认备份文件可读，并在隔离环境或既定演练流程中验证恢复路径。官方也明确提醒，回退遇到数据库迁移时，应恢复升级前的备份。

执行阶段：单实例换版本，多实例先协调

这次怎样完成版本切换？先按官方更新指南核对与你的部署方式相符的步骤。生产或团队环境应固定到明确的版本标签，并先检查发布说明；不要在生产配置中只写会持续指向新构建的浮动标签。官方指南分别列出 Docker、Compose 和 Python 的更新方式，因此不要把某一种部署的命令当成通用做法。

• 单实例 Docker Compose：确认 Compose 文件中的镜像标签已改为目标版本，再执行官方指南中的拉取与重建步骤。不要在没有核对卷挂载和环境变量时，照搬另一套 Compose 文件。
• 多实例或多 Worker：先安排维护窗口，确认所有实例都会切到同一版本。官方要求这类部署同步更新；更新指南建议先停止所有副本，让一个实例执行迁移，再以新版本启动其余实例。不要让新旧版本共用已经迁移的数据库。
• Python 部署：按官方更新指南核对安装方式、服务重启方式和当前运行环境；不要把容器更新命令用于 Python 部署。
• 异常处理：保留迁移日志。遇到数据库错误、启动循环或健康检查失败时，先停止继续扩大变更范围，按部署手册排查；不要反复切镜像标签碰运气。

多实例的扩缩容方式和迁移顺序取决于部署架构。官方扩展指南建议只让一个进程执行数据库迁移，并说明副本扩展需要共享状态和协调配置；如果你不确定哪一实例负责迁移，先不要启动全部副本。

验收阶段：从启动成功到工作流可用

界面能打开只证明前端可访问，不代表数据迁移、登录和团队工作流都正常。按升级前记录逐项检查：

• 查看启动日志，确认目标版本和数据库迁移结果；出现错误时保存完整上下文，避免只截取最后一行。
• 用真实团队账号登录，检查历史会话、上传文件、知识库和管理员配置是否仍可访问。
• 对实际启用的功能做端到端验证：模型连接、工具调用、终端或其他工作区操作；未启用的功能不必为升级验收临时添加。
• 多实例环境中，确认所有实例运行相同版本，并验证负载均衡下登录、会话和功能访问没有因副本差异而异常。
• 界面显示不完整时，按更新指南建议清理浏览器缓存后复查；这不能替代数据库迁移和功能检查。

怎样确认不是“只启动了应用”而已？将验收结果与升级前基线逐条对照：版本、数据、登录、模型连接、工具工作流和多实例一致性都通过，才结束升级窗口。官方数据库迁移排障文档列出了迁移中断、表缺失和多副本等故障成因；出现相应迹象时，按具体错误处理，不要擅自跳过未完成的迁移。

行为变化：提前调整团队操作和限制策略

v0.13.0 不只有数据库结构变化。官方升级说明还列出界面控制入口移动、工具调用轮次上限变化，以及子 Agent 限制默认行为变化。你应当在升级前检查团队是否依赖旧入口或旧限制，并把必要的设置纳入配置审核。

工具调用升级后有什么需要留意？官方说明，一次回复允许的工具调用轮次从 256 提高到 1,024；若团队希望保留旧上限，可设置 CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS=256。这是该版本说明中的行为变化，不应推断成所有版本都使用相同默认值。该变量在官方环境变量参考中有说明。

官方还说明，子 Agent 的并发数、后台任务数、迭代次数和输出长度限制默认不再设限；如果团队依赖限制来约束任务范围或资源使用，应在管理员设置或对应环境变量中明确配置。另一个容易漏掉的变化是聊天控制入口移动，团队的操作说明和内部截图也要更新。

环境评估：升级应用，不等于扩容推理服务

升级后如果响应变慢，不要先假设需要增加服务器资源。Open WebUI 应用服务与模型推理服务可能运行在不同位置；先看升级后的实际监控、实例数量、数据库和文件读写情况，再判断瓶颈属于应用层、存储层还是模型推理层。不要据此推导未验证的最低配置或性能承诺。

下面的条件分支可用于安排升级窗口：

• 若你已确认备份可读、回退路径明确，且是单实例部署，则按对应官方步骤升级并完成验收。
• 若你使用多实例或多 Worker，只有在所有实例能协调切换、迁移执行方式已核实后才升级；否则先安排维护窗口。
• 若团队依赖子 Agent 或工具调用限制，先设定明确策略并通知使用者；若没有完成策略核对，先暂缓面向全员的更新。
• 若升级后只有模型生成变慢，而应用本身和数据库检查正常，就先分离模型服务与应用服务观察，不要仅凭升级时间点直接扩容。

以上规格以 OSFP Cloud 当前配置说明为准；选择内存、硬盘和带宽前，也可查看配置选项说明。OSFP Cloud 不提供 GPU，因此本机规格不能被理解为 GPU 推理或训练能力。

最后更新于 2026 年 11 月 7 日；官方信息核实自 Open WebUI v0.13.0 发布记录、版本文章与更新文档。发布前请再次确认是否有后续补丁或迁移说明。

升级完成后，再根据 Open WebUI、数据库和模型服务各自的实测负载决定是否需要调整主机；如果你要评估长期运行的独享服务器，可先核对 OSFP Cloud 已公布的配置与系统选项，而不是用未经测试的资源门槛代替验收结果。