能启动不等于完成发布
有数据库、上传文件和反向代理的应用，发布不能简化为拉取镜像后重启。镜像来源是否正确、迁移是否可执行、备份是否可恢复、容器是否健康、HTTPS 路径是否返回预期内容，都需要在切换过程中得到证据。
CTY Log 的公开部署脚本使用唯一发布标识、离线镜像包和校验文件，发布前创建 PostgreSQL 自定义格式备份，再执行 Alembic 正向迁移。本文说明这种单机 Compose 架构的顺序；多副本和零停机集群需要不同的流量切换机制。
发布输入必须不可变
每个发布标签只对应一次构建，不能移动或复用。发布包包含镜像归档、SHA-256 和描述镜像名称及源码版本的环境文件。目标机在加载前同时校验文件摘要和允许的镜像来源，避免把临时本地镜像误当成正式版本。
环境秘密不进入发布包。生产 .env、证书、上传和备份保留在服务器受限目录或持久卷中，代码仓库和 Release 产物只携带非秘密发布元数据。
有状态发布顺序
备份在迁移之前，因为数据库结构改变后，旧应用未必能继续读取。迁移使用独立短任务，成功后才切换应用容器。API 健康检查不仅确认进程存在，还执行最小数据库查询；Web 检查确认服务端渲染能读取 API。
回滚边界
应用镜像回滚和数据库回滚不是同一件事。发布脚本可以在新容器不健康时恢复上一版镜像，但迁移必须设计为向后兼容：先增加可空字段或新表，应用稳定后再在后续版本移除旧结构。生产数据库不能因为应用检查失败就自动恢复备份，这可能覆盖发布后产生的新数据。
若迁移本身失败，事务型迁移应回滚并停止切换。若已经发生不可逆数据变化，必须进入人工处置和隔离恢复流程，而不是继续尝试旧镜像。备份恢复先在独立数据库验证，确认校验和、格式与迁移版本，再制定生产恢复窗口。
验证与演练
发布前在 CI 构建前端、运行 API 测试并验证容器配置；发布后检查三个容器、当前发布记录、最新备份校验和以及站内健康端点。公网域名受备案或上游网络策略影响时，应把服务器内部健康与外部可达性分别报告，不能通过关闭 HTTPS规避合规问题。
回滚能力需要演练。可以在隔离环境故意让新 API 健康检查失败，确认镜像回退；也可以把备份恢复到第二个数据库，核对 Alembic 版本和关键表数量。未经演练的备份只能证明文件存在。
结论
可靠发布依靠不可变输入、迁移前备份、分层健康检查和明确的回滚边界。Compose 足以支撑单机有状态应用，但必须像对待正式发布系统一样记录版本、校验证据并保护持久卷。