升级
怎么升到新版本、迁移失败会怎样、以及为什么回滚意味着恢复备份而不是降级。
开始之前
先备份。不是走流程——它就是你唯一的回滚方案，下面会说明为什么没有别的。
Compose
./backup.sh /var/backups/busabase
docker compose pull
docker compose up -dmigrate 会先跑、跑完，然后 app 才启动。如果它失败，会以非零码退出，app 根本不会起来——condition: service_completed_successfully 保证了这一点。你得到的是一套停着的部署和日志里清楚的原因，而不是一套跑在半迁移 schema 上的部署。
docker compose logs migrate输出里会给出失败的 SQL 语句和数据库报错，但不会给出它来自哪个迁移文件。要定位文件，拿那条语句去迁移目录里搜：
docker compose run --rm --entrypoint sh migrate -c \
"grep -rl 'this_table_does_not_exist' apps/busabase-cloud/src/db/migrations"请把那个文件连同支持包一起发给我们，不要自己手改 schema——「迁移只跑了一半」这个状态我们能从文件层面修复，但「有人直接改过表」之后就难修得多了。
一体机
docker pull busabase/busabase-premium-allinone:trial
docker rm -f busabase
docker run -d --name busabase \
-p 3000:3000 \
-v busabase-data:/data \
--restart unless-stopped \
busabase/busabase-premium-allinone:trial-v busabase-data:/data 才是「这是升级而不是全新安装」的关键。同一个卷名，同一份数据。漏掉它你会得到一个全新的空实例，看起来就像数据被删了。
这里迁移同样在启动时执行，失败同样是致命的：容器会停掉，而不是拿一个它读不懂的 schema 去对外服务。
回滚
没有向下迁移的路径。一个已经加了列的迁移，不存在一个「知道该拿新写入的行怎么办」的逆操作。
所以回滚意味着：跑上一个镜像 tag，并恢复你升级前做的那份备份。整个流程就这些——这也是为什么备份那一步不是可选的。
BUSABASE_IMAGE=busabase/busabase-premium:<上一个-tag> docker compose up -d
# 然后按 /docs/self-hosted/backup-restore 恢复确认升级生效
curl -s http://localhost:3000/api/health返回里的 version 字段告诉你实际在对外服务的是哪个构建——值得确认一下而不是想当然，尤其是在本地缓存过旧镜像的机器上。