自托管 OpenStatus：8 个服务 + libSQL 依赖 + db-migrate 一次性迁移

OpenStatus 是开源的「状态页 + 可用性监控」平台，AGPL-3.0，官方定位是 built for infra as code：monitors、status pages、notification channels 用 YAML 或 Terraform 声明，从 CLI 或 CI 应用，也能通过 MCP 从 Claude / ChatGPT / Cursor 操作。

• 仓库：
• 官网 / 文档：

技术栈：Next.js（Dashboard）、Hono（API server）、Go（Checker）、Turso（数据库）、Drizzle（ORM）、Tinybird（Analytics）、Tailwind、shadcn/ui。

官方预构建镜像（GHCR）

ghcr.io/openstatushq/openstatus-server:latest             主 API server
ghcr.io/openstatushq/openstatus-dashboard:latest          Web dashboard
ghcr.io/openstatushq/openstatus-workflows:latest          工作流引擎
ghcr.io/openstatushq/openstatus-private-location:latest   私有监控节点（单个 8.5MB Docker 镜像）
ghcr.io/openstatushq/openstatus-status-page:latest        公开状态页
ghcr.io/openstatushq/openstatus-checker:latest            监控检查服务

Docker 快速开始

按官方 DOCKER.md：

cp .env.docker.example .env.docker
docker compose up -d
# Dashboard    http://localhost:3002
# Status Pages http://localhost:3003

Coolify 部署

以下内容基于仓库根目录的 COOLIFY_DEPLOYMENT.md。

前提：一台 Coolify 实例（自托管或云）、一个有仓库访问权限的 GitHub 账号、环境变量已配置好。

1. 新建 Application

新建 Application，类型选 Docker，image source 选 Public Repository。

2. 逐个配置服务

3. 外部依赖

• LibSQL 数据库：ghcr.io/tursodatabase/libsql-server:latest，端口 8080，SQLD_NODE=primary
• TinyBird（可选）：tinybirdco/tinybird-local:latest，端口 7181，COMPATIBILITY_MODE=1

4. 网络

为所有服务建一个共享网络，用容器名互通，并为每个服务配置健康检查。

5. 部署顺序

LibSQL(数据库) -> TinyBird(如使用) -> Workflows -> Server -> Private Location -> Checker -> Dashboard -> Status Page

环境变量统一放在 .env，完整清单参考仓库的 .env.docker.example。

健康检查（镜像内置）

# Server / Workflows
curl -f http://localhost:3000/ping

# Dashboard / Status Page
curl -f http://localhost:3000/

# Private Location
wget --spider -q http://localhost:8080/health

# Checker
curl -f http://localhost:8080/health

版本管理

latest 指向 main 的最新构建；具体提交用 SHA 打 tag；生产环境用具体 tag。

排障

• 拉镜像失败：给 Coolify 加 GitHub token 作为 registry credential，token 需要 packages: read 权限。
• 服务间通信：确认在同一网络、容器名匹配、端口映射正确。
• 数据库连接：等 LibSQL 完全健康再启动其它服务，DATABASE_URL 格式为 http://libsql:8080。

更新

main 推送或手动 workflow dispatch 会自动构建并推送镜像。在 Coolify 里拉新镜像，按正确顺序重新部署，再验证健康检查。

社区 Compose 部署要点

仓库根目录的 coolify-deployment.yaml。

• 所有服务通过 openstatus 桥接网络互通，容器名即服务发现主机名（如 libsql、server）。
• 一次性迁移服务 db-migrate（镜像 ghcr.io/openstatushq/openstatus-db-migrate:latest）依赖 LibSQL 健康后才启动，执行 Drizzle 迁移。迁移幂等，已应用的会被跳过，每次部署都能安全运行。restart: on-failure:3 与 pull_policy: always 用来吸收瞬时数据库竞争，并保证每次拉取最新迁移镜像。业务服务用 depends_on: db-migrate: condition: service_completed_successfully 等迁移完成，不需要手动迁移步骤。

最小可用环境变量

只有 5 个：

DATABASE_URL=http://libsql:8080        # libsql 为容器名
DATABASE_AUTH_TOKEN=                   # 本地 LibSQL 留空
AUTH_SECRET=                           # ≥32 字符随机串，openssl rand -base64 32
NEXT_PUBLIC_URL=https://your-domain.com  # 必须带协议前缀
RESEND_API_KEY=                        # Resend 邮件密钥，用于发送登录魔法链接

LibSQL 容器

容器名 openstatus-libsql，内部端口 8080（宿主 8085 -> 容器 8080，另开放 5001），SQLD_NODE=primary，数据卷 libsql-data:/var/lib/sqld，健康检查 start_period: 10s。

业务服务探针

通用参数：interval: 15s、timeout: 10s、retries: 3、start_period: 30s~45s。首次部署时数据库迁移和依赖启动需要时间，宽限期内探针失败不会误判。