升级

更新现有部署前，先备份账本并保留部署配置，再按本页升级和验证。

升级不需要手动处理数据。数据库结构的变化以迁移文件的形式随代码发布，部署时自动执行；旧的记录、旧格式的备份都会继续可用。

升级前建议先在「设置 → 数据 → 导出完整备份」导出一份。

导出完整备份，记录当前版本、数据卷与环境变量。
按下面对应方式更新代码或镜像，保留自定义域名、密钥和持久化配置。
登录应用，核对订阅、钱包和通知渠道，并测试 MCP 或日历等已启用的接入。

Cloudflare

命令行部署的：

cd calends
git pull
npm ci
npm run deploy

npm run deploy 会在部署后对远程数据库执行新的迁移。即使漏了这一步，Worker 在处理第一个请求时也会补齐缺失的迁移。

一键部署的：仓库在你自己的 GitHub 账号下。把上游 imetn/calends 的更新同步到你的仓库（GitHub 页面上的 Sync fork，或者手动合并），Cloudflare 会按你的仓库重新构建部署。

如果你改过 wrangler.jsonc（自定义域名、邮件绑定），git pull 时注意保留这些修改。

Docker

docker pull xizozhe/calends:latest
docker stop calends
docker rm calends
docker run -d --name calends --restart unless-stopped \
  -p 8787:8787 -v calends-data:/data \
  xizozhe/calends:latest

使用 Docker 指南中的预构建镜像 compose.yaml 时，在其部署目录运行：

docker compose pull
docker compose up -d

上面的 docker run 是最小配置。重建时必须带回原来的 SITE_URL、TRUST_PROXY、SETUP_TOKEN、端口和其他环境变量；数据卷名称也必须相同。

数据在数据卷里，删除容器不会丢失。新容器启动时会先对数据库执行迁移。

想固定版本、自己决定什么时候升级，把 latest 换成具体的版本号标签，比如 xizozhe/calends:1.6.0。

GHCR 可作为匿名拉取的备选：将 xizozhe/calends 换成 ghcr.io/imetn/calends，拉取和启动命令中的标签保持一致。两个仓库均提供 latest、1.6.0 和 1.6；建议用 1.6.0 这样的具体版本控制升级节奏。

Compose 源码构建

使用仓库的 docker/docker-compose.yml 时，应更新源码并重新构建，而非拉取预构建镜像。在仓库根目录执行：

git pull
cd docker && docker compose up -d --build
docker compose logs calends

保留 Compose 项目名 calends 和已有的 calends_calends-data 数据卷。它与预构建镜像示例的 calends-data 是两个独立的卷，应使用原部署的数据卷，不要运行 docker compose down -v。

回退

数据库迁移不会因为切回旧代码而撤销。回退前先确认旧版本能读取当前数据结构；不能仅凭应用能启动就判断兼容。