Tabby 自托管 AI 编程助手升级完全指南从备份、镜像拉取到数据库迁移【免费下载链接】tabbySelf-hosted AI coding assistant项目地址: https://gitcode.com/GitHub_Trending/tab/tabbyTabby 是一个快速迭代的 Self-hosted AI coding assistant其升级流程涉及数据库备份、部署产物替换与实例重启三个环节。本文以官方 upgrade.md 为骨架结合仓库内数据目录实现、Docker 镜像构建配置与 SQL 迁移脚本给出可直接落地的升级操作手册并解释为何升级前必须备份、为何不支持降级的底层原因。读完本文你将能够安全、可回退地完成任意部署形态Docker / Docker Compose / 独立发行版下 Tabby 的升级。:::caution 升级前请务必先备份数据库。Tabby 不支持降级请确保在升级前完整保存元数据。 :::一、升级前的准备工作理解 Tabby 的数据存放位置Tabby 是一个快速演进的软件项目官方持续引入新特性并修复缺陷可在仓库根目录的 CHANGELOG.md 中看到按语义化版本组织的迭代记录例如 v0.30.x、v0.31.x 系列。因此官方建议定期升级安装实例但升级动作本身存在数据兼容风险这正是文档反复强调先备份的原因。1.1 数据根目录与 TABBY_ROOT默认情况下Tabby 将全部运行数据存放在$HOME/.tabby目录下也可以通过TABBY_ROOT环境变量覆盖该位置。仓库中 crates/tabby-common/src/path.rs 是这一行为的源码级定义static ref TABBY_ROOT: MutexCellPathBuf { Mutex::new(Cell::new(match env::var(TABBY_ROOT) { Ok(x) PathBuf::from(x), Err(_) home::home_dir().unwrap().join(.tabby), })) };也就是说设置了TABBY_ROOT时使用其值否则回退到用户主目录下的.tabby。该根目录内集中存放着数据库、事件日志、配置文件、模型缓存、代码仓库与索引等全部运行资产config.toml配置文件config_file()Tabby 不会默认创建需要手动新建详见 config-toml.mdrepositories/代码仓库数据repositories_dir()index/代码检索索引index_dir()models/本地模型缓存models_dir()events/事件日志events_dir()。在 Docker 部署中容器内通过ENV TABBY_ROOT/data见 docker/Dockerfile.cuda将数据根目录固定为/data并要求将宿主机$HOME/.tabby以数据卷形式挂载到该路径从而保证容器重建后数据不丢失。这解释了升级时替换镜像但保留数据卷的关键所在。1.2 需要备份的三类数据按照官方 backup.md升级前至少应备份以下内容① 数据库必须Tabby 使用 SQLite 存储业务数据默认数据库文件位于$HOME/.tabby/ee/db.sqlite。备份方法如下需安装 SQLite CLIsqlite3 $HOME/.tabby/ee/db.sqlite进入 SQLite CLI 后执行.backup backup_database.db执行完毕后当前工作目录下会生成名为backup_database.db的备份文件。② 事件日志建议所有事件日志存放在~/.tabby/events目录以 JSON 格式按日期命名如2024-03-06.json。该目录可直接整目录复制保存。③ 后台任务日志v0.27.0 及以上建议从 v0.27.0 起后台任务日志保存在~/.tabby/ee/jobs目录管理界面management UI中的任务日志展示依赖该目录因此也需要一并备份。二、标准升级流程三步完成官方给出的标准升级过程分为三步备份 Tabby 数据库按上文第一节执行执行升级根据部署形态选择对应方式重启 Tabby。2.1 Docker 部署拉取最新镜像如果使用 Docker 部署升级的核心动作是拉取最新镜像并重建容器docker pull tabbyml/tabby官方快速入门文档website/docs/quick-start/installation/docker.mdx展示了完整启动命令其中数据卷挂载是关键docker run -d \ --name tabby \ --gpus all \ -p 8080:8080 \ -v $HOME/.tabby:/data \ registry.tabbyml.com/tabbyml/tabby \ serve \ --model StarCoder-1B \ --chat-model Qwen2-1.5B-Instruct \ --device cuda升级时只需重复这一启动流程或先docker rm -f tabby再重新创建由于宿主机$HOME/.tabby已挂载为容器内/data旧数据会完整保留给新版本使用。查看新实例日志使用docker logs -f tabby2.2 Docker Compose 部署若使用 Compose 编排升级等价于拉取镜像并重建服务。仓库 experimental/deploy/docker-compose.yaml 给出了典型 Compose 配置其要点同样是数据卷持久化tabby: restart: always image: tabbyml/tabby command: serve --model TabbyML/T5P-220M volumes: - $HOME/.tabby:/data配合快速入门文档 docker-compose.mdx 中带 GPU 预留的完整示例升级操作序列为docker compose pull docker compose up -d2.3 独立发行版standalone release替换可执行文件如果使用官方发布的独立发行版standalone release升级方式是下载新版本的可执行文件替换旧的 Tabby 二进制然后重启服务。安装时使用的模型、配置文件均位于~/.tabby数据目录与二进制相对独立因此替换二进制本身不会触碰数据。从 docker/Dockerfile.cuda 可以看到正式构建产物由tabby主程序与llama-server本地推理后端两个二进制组成统一安装到/opt/tabby/bin并被加入PATH。独立发行版升级时应同时确保这两个组件来自同一版本避免主程序与推理后端版本不匹配。2.4 其他方式对于非 Docker、非独立发行版的部署例如从源码自行构建在完成数据备份后直接以相同配置重启新构建的 Tabby 进程即可。这类场景下更应关注数据库迁移是否成功见下文第四节因为源码版本之间的 schema 差异可能更大。三、升级验证如何确认升级成功重启 Tabby 后可通过以下方式验证升级是否生效检查进程与端口确认 8080 端口正常监听访问http://localhost:8080能看到 Web 界面查看启动日志Docker 部署执行docker logs -f tabby独立部署观察标准输出重点关注数据库迁移migration与模型加载日志验证核心 APITabby 提供健康检查与版本接口在 crates/tabby/src/serve.rs 的 OpenAPI 定义中暴露了health与setting等路由可通过健康检查确认服务就绪回归功能在 IDE 扩展中重新连接服务端验证代码补全与问答功能正常。四、升级背后的原理数据库迁移与不支持降级的由来4.1 版本演进与语义化版本Tabby 遵循 Keep a Changelog 与语义化版本规范见 CHANGELOG.md升级路径通常是v0.30.x → v0.31.x这样的顺序。每次发版都可能伴随数据库 schema 的演进。4.2 SQL 迁移脚本schema 如何前进Tabby 的数据库迁移脚本集中存放在 ee/tabby-db/migrations 目录下每个迁移都包含一对文件NNNN_名称.up.sql向前迁移升级 schemaNNNN_名称.down.sql回退迁移还原 schema。仓库中已存在从0001_registration-token-table到0050_add-repository-refs共 50 个迁移覆盖了用户表、邀请、OAuth 凭据、任务运行、仓库、线程消息等持续演进的数据结构。可以推断每升级一个大版本Tabby 都会按序执行新增的 up 迁移将旧库结构推进到新版本所需的结构。同时仓库中的 sqlx-migrate-validate crate 提供了对迁移脚本的校验能力其测试用例crates/sqlx-migrate-validate/tests/validate.rs展示了迁移前后结构一致性验证的方式说明官方对迁移的正确性有专门的工程保障。4.3 为什么官方明确不支持降级官方文档明确警告Tabby 不支持降级downgrade。从迁移机制可以理解其原因升级是按顺序应用 up 迁移的单向前进过程虽然仓库保留了 down 脚本但降级意味着要反向执行多个 down 迁移而历史数据在升级过程中可能已被改写或清理无法保证能安全回退到旧版本的数据语义。因此升级前必须备份db.sqlite、events、jobs一旦升级完成就不要尝试用旧版本二进制加载新 schema 的数据库若升级后出现异常可靠的做法是基于备份恢复而不是降级。五、升级常见问题与注意事项事项说明忘记备份升级是不可逆的务必先执行第一节的数据库备份.backup backup_database.db数据卷未挂载Docker 升级时若未将$HOME/.tabby挂载到/dataTABBY_ROOT新容器会丢失全部数据见 path.rs配置兼容性~/.tabby/config.toml中的模型与补全配置可能随版本增加新字段升级后按 config-toml.md 核对配置是否仍被支持迁移失败观察启动日志中的迁移错误保持备份完整必要时基于备份重建实例SELinux 环境官方提示启用 SELinux 的系统可能需要给挂载卷加:Z选项见 docker.mdx升级完成后Tabby 将携带最新的特性与缺陷修复继续运行。如果过程中遇到问题可以在保留备份的前提下检查日志定位原因并通过官方社区渠道获取帮助。始终记住三条铁律先备份、再升级、不降级——这能让每一次版本前进都安全可控。【免费下载链接】tabbySelf-hosted AI coding assistant项目地址: https://gitcode.com/GitHub_Trending/tab/tabby创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Tabby 自托管 AI 编程助手升级完全指南：从备份、镜像拉取到数据库迁移
Tabby 自托管 AI 编程助手升级完全指南从备份、镜像拉取到数据库迁移【免费下载链接】tabbySelf-hosted AI coding assistant项目地址: https://gitcode.com/GitHub_Trending/tab/tabbyTabby 是一个快速迭代的 Self-hosted AI coding assistant其升级流程涉及数据库备份、部署产物替换与实例重启三个环节。本文以官方 upgrade.md 为骨架结合仓库内数据目录实现、Docker 镜像构建配置与 SQL 迁移脚本给出可直接落地的升级操作手册并解释为何升级前必须备份、为何不支持降级的底层原因。读完本文你将能够安全、可回退地完成任意部署形态Docker / Docker Compose / 独立发行版下 Tabby 的升级。:::caution 升级前请务必先备份数据库。Tabby 不支持降级请确保在升级前完整保存元数据。 :::一、升级前的准备工作理解 Tabby 的数据存放位置Tabby 是一个快速演进的软件项目官方持续引入新特性并修复缺陷可在仓库根目录的 CHANGELOG.md 中看到按语义化版本组织的迭代记录例如 v0.30.x、v0.31.x 系列。因此官方建议定期升级安装实例但升级动作本身存在数据兼容风险这正是文档反复强调先备份的原因。1.1 数据根目录与 TABBY_ROOT默认情况下Tabby 将全部运行数据存放在$HOME/.tabby目录下也可以通过TABBY_ROOT环境变量覆盖该位置。仓库中 crates/tabby-common/src/path.rs 是这一行为的源码级定义static ref TABBY_ROOT: MutexCellPathBuf { Mutex::new(Cell::new(match env::var(TABBY_ROOT) { Ok(x) PathBuf::from(x), Err(_) home::home_dir().unwrap().join(.tabby), })) };也就是说设置了TABBY_ROOT时使用其值否则回退到用户主目录下的.tabby。该根目录内集中存放着数据库、事件日志、配置文件、模型缓存、代码仓库与索引等全部运行资产config.toml配置文件config_file()Tabby 不会默认创建需要手动新建详见 config-toml.mdrepositories/代码仓库数据repositories_dir()index/代码检索索引index_dir()models/本地模型缓存models_dir()events/事件日志events_dir()。在 Docker 部署中容器内通过ENV TABBY_ROOT/data见 docker/Dockerfile.cuda将数据根目录固定为/data并要求将宿主机$HOME/.tabby以数据卷形式挂载到该路径从而保证容器重建后数据不丢失。这解释了升级时替换镜像但保留数据卷的关键所在。1.2 需要备份的三类数据按照官方 backup.md升级前至少应备份以下内容① 数据库必须Tabby 使用 SQLite 存储业务数据默认数据库文件位于$HOME/.tabby/ee/db.sqlite。备份方法如下需安装 SQLite CLIsqlite3 $HOME/.tabby/ee/db.sqlite进入 SQLite CLI 后执行.backup backup_database.db执行完毕后当前工作目录下会生成名为backup_database.db的备份文件。② 事件日志建议所有事件日志存放在~/.tabby/events目录以 JSON 格式按日期命名如2024-03-06.json。该目录可直接整目录复制保存。③ 后台任务日志v0.27.0 及以上建议从 v0.27.0 起后台任务日志保存在~/.tabby/ee/jobs目录管理界面management UI中的任务日志展示依赖该目录因此也需要一并备份。二、标准升级流程三步完成官方给出的标准升级过程分为三步备份 Tabby 数据库按上文第一节执行执行升级根据部署形态选择对应方式重启 Tabby。2.1 Docker 部署拉取最新镜像如果使用 Docker 部署升级的核心动作是拉取最新镜像并重建容器docker pull tabbyml/tabby官方快速入门文档website/docs/quick-start/installation/docker.mdx展示了完整启动命令其中数据卷挂载是关键docker run -d \ --name tabby \ --gpus all \ -p 8080:8080 \ -v $HOME/.tabby:/data \ registry.tabbyml.com/tabbyml/tabby \ serve \ --model StarCoder-1B \ --chat-model Qwen2-1.5B-Instruct \ --device cuda升级时只需重复这一启动流程或先docker rm -f tabby再重新创建由于宿主机$HOME/.tabby已挂载为容器内/data旧数据会完整保留给新版本使用。查看新实例日志使用docker logs -f tabby2.2 Docker Compose 部署若使用 Compose 编排升级等价于拉取镜像并重建服务。仓库 experimental/deploy/docker-compose.yaml 给出了典型 Compose 配置其要点同样是数据卷持久化tabby: restart: always image: tabbyml/tabby command: serve --model TabbyML/T5P-220M volumes: - $HOME/.tabby:/data配合快速入门文档 docker-compose.mdx 中带 GPU 预留的完整示例升级操作序列为docker compose pull docker compose up -d2.3 独立发行版standalone release替换可执行文件如果使用官方发布的独立发行版standalone release升级方式是下载新版本的可执行文件替换旧的 Tabby 二进制然后重启服务。安装时使用的模型、配置文件均位于~/.tabby数据目录与二进制相对独立因此替换二进制本身不会触碰数据。从 docker/Dockerfile.cuda 可以看到正式构建产物由tabby主程序与llama-server本地推理后端两个二进制组成统一安装到/opt/tabby/bin并被加入PATH。独立发行版升级时应同时确保这两个组件来自同一版本避免主程序与推理后端版本不匹配。2.4 其他方式对于非 Docker、非独立发行版的部署例如从源码自行构建在完成数据备份后直接以相同配置重启新构建的 Tabby 进程即可。这类场景下更应关注数据库迁移是否成功见下文第四节因为源码版本之间的 schema 差异可能更大。三、升级验证如何确认升级成功重启 Tabby 后可通过以下方式验证升级是否生效检查进程与端口确认 8080 端口正常监听访问http://localhost:8080能看到 Web 界面查看启动日志Docker 部署执行docker logs -f tabby独立部署观察标准输出重点关注数据库迁移migration与模型加载日志验证核心 APITabby 提供健康检查与版本接口在 crates/tabby/src/serve.rs 的 OpenAPI 定义中暴露了health与setting等路由可通过健康检查确认服务就绪回归功能在 IDE 扩展中重新连接服务端验证代码补全与问答功能正常。四、升级背后的原理数据库迁移与不支持降级的由来4.1 版本演进与语义化版本Tabby 遵循 Keep a Changelog 与语义化版本规范见 CHANGELOG.md升级路径通常是v0.30.x → v0.31.x这样的顺序。每次发版都可能伴随数据库 schema 的演进。4.2 SQL 迁移脚本schema 如何前进Tabby 的数据库迁移脚本集中存放在 ee/tabby-db/migrations 目录下每个迁移都包含一对文件NNNN_名称.up.sql向前迁移升级 schemaNNNN_名称.down.sql回退迁移还原 schema。仓库中已存在从0001_registration-token-table到0050_add-repository-refs共 50 个迁移覆盖了用户表、邀请、OAuth 凭据、任务运行、仓库、线程消息等持续演进的数据结构。可以推断每升级一个大版本Tabby 都会按序执行新增的 up 迁移将旧库结构推进到新版本所需的结构。同时仓库中的 sqlx-migrate-validate crate 提供了对迁移脚本的校验能力其测试用例crates/sqlx-migrate-validate/tests/validate.rs展示了迁移前后结构一致性验证的方式说明官方对迁移的正确性有专门的工程保障。4.3 为什么官方明确不支持降级官方文档明确警告Tabby 不支持降级downgrade。从迁移机制可以理解其原因升级是按顺序应用 up 迁移的单向前进过程虽然仓库保留了 down 脚本但降级意味着要反向执行多个 down 迁移而历史数据在升级过程中可能已被改写或清理无法保证能安全回退到旧版本的数据语义。因此升级前必须备份db.sqlite、events、jobs一旦升级完成就不要尝试用旧版本二进制加载新 schema 的数据库若升级后出现异常可靠的做法是基于备份恢复而不是降级。五、升级常见问题与注意事项事项说明忘记备份升级是不可逆的务必先执行第一节的数据库备份.backup backup_database.db数据卷未挂载Docker 升级时若未将$HOME/.tabby挂载到/dataTABBY_ROOT新容器会丢失全部数据见 path.rs配置兼容性~/.tabby/config.toml中的模型与补全配置可能随版本增加新字段升级后按 config-toml.md 核对配置是否仍被支持迁移失败观察启动日志中的迁移错误保持备份完整必要时基于备份重建实例SELinux 环境官方提示启用 SELinux 的系统可能需要给挂载卷加:Z选项见 docker.mdx升级完成后Tabby 将携带最新的特性与缺陷修复继续运行。如果过程中遇到问题可以在保留备份的前提下检查日志定位原因并通过官方社区渠道获取帮助。始终记住三条铁律先备份、再升级、不降级——这能让每一次版本前进都安全可控。【免费下载链接】tabbySelf-hosted AI coding assistant项目地址: https://gitcode.com/GitHub_Trending/tab/tabby创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考