Keel self-hosted部署
本documentation面向想self-hosted Keel 后端service(不用 Keel 托管商业版)的developer / enterprise。所有 Keel service端code Apache 2.0 open source,可以自己跑。
大多数developer不需要看这个——直接用 Keel Pro / Team / Enterprise 托管版,省运维。本documentation只对:
- data出境合规要求严格的customer
- private云 / 内网部署需求
- 想完全控制 / 二开的爱好者
…这几类人有用。
self-hosted vs 托管
| 维度 | 托管版(Pro / Team / Enterprise) | self-hosted |
|---|---|---|
| 运维 | Keel 团队 | 你自己 |
| SLA | 有(详见 pricing.md) | 无(社区支持) |
| 升级 | 自动 | 手动 |
| 计费 | ¥/月subscription | 自付云资源(Aliyun / Tencent Cloud / self-hosted机房) |
| feature | 完整 | 完整(不阉割,跟商业版一样的code) |
| 合规 | Keel 走 ICP ICP filing + 合规通道 | 你自己负责 |
5 个service可独立部署
Keel 后端是module化的,每个service独立可以跑:
| service | 必须 / 可选 | 说明 |
|---|---|---|
| Build | 可选(不需要云端 build 就不装) | Docker pipeline;跑 metro + Hermes |
| Update Service | 可选(用 App Store 直接update就不装) | manifest endpoint + bundle CDN |
| Push Service | 可选(路线图) | 包 Jiguang / Getui server API |
| (removed) | 可选(路线图,仅 web target 用得上) | 静态资源 + CDN |
| Identity / Account API | 可选 | Keel user账号(self-hosted可以走自家 SSO) |
当前self-hosted场景 = Build + Update Service。其他可以等需要再加。
最小self-hosted
前置dependency
- 一台 Linux service器(4 vCPU / 8 GB memory起,Build 需要更大)
- Docker + Docker Compose
- PostgreSQL 14+ 或 SQLite(Update manifest)
- 任意 S3 兼容对象存储(OSS / R2 / S3 / MinIO)+ CDN(Aliyun / Cloudflare / self-hosted)
- 域名 + HTTPS cert(Let’s Encrypt free)
启动 Build
# 拉 Keel 后端code
git clone https://github.com/liamxujia/appunvs.git
cd appunvs/keel/cloud/build-image
# 构建 Docker image(含 metro + Hermes + iOS / Android toolchain)
docker build -t keel/cloud/build-image:self-host .
# 启动构建器(需要 Docker-in-Docker 或 mounted /var/run/docker.sock)
docker run -d \
--name keel-cloud-build \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /var/keel/builds:/work \
-p 8080:8080 \
-e KEEL_BUILD_DIR=/work \
-e KEEL_API_KEY=$YOUR_PRIVATE_API_KEY \
keel/cloud/build-image:self-host
⚠️ 目前这个 image 还在 internal 状态——
keel/cloud/build-image/当前是给 appunvs internal AI bundle 构建用的,把它包装成对外 service 是路线图任务。本documentation先占位。
启动 Update Service
# Update service 是个 Go binary
cd keel/cloud/cmd/update-server
go build -o keel-update-server .
# 当前 backend 只支持 mem + sqlite;Postgres 在路线图上。
# production端用 SQLite(单实例够 100k 设备的 polling)。
./keel-update-server \
--db "sqlite:/var/lib/keel/update.db" \
--listen ":8081"
# S3/OSS bundle 存储 + CDN 通过 env 配(不是命令行 flag):
# KEEL_UPDATE_BLOB_STORE=s3
# KEEL_UPDATE_S3_BUCKET=keel-bundles
# KEEL_UPDATE_S3_REGION=cn-hangzhou
# KEEL_UPDATE_S3_ENDPOINT=https://oss-cn-hangzhou.aliyuncs.com
# KEEL_UPDATE_S3_ACCESS_KEY=<RAM ak>
# KEEL_UPDATE_S3_SECRET_KEY=<RAM sk>
# KEEL_UPDATE_PUBLIC_URL_BASE=https://cdn.your-domain.com
# 详见 deployment-sop.md 完整 systemd + nginx 模板。
CLI configuration指向self-hosted后端
developer本地 keel/config.yaml(在项目里):
endpoint:
cloud_build: https://your-keel-cloud-build.com
ota: https://your-keel-update-server.com
api_key: $KEEL_API_KEY
keel build ios / keel publish 自动用configuration里的 endpoint。
Aliyun推荐栈
domestic / mainland Chinaself-hosted首选Aliyun:
| service | Aliyun对位 | 备注 |
|---|---|---|
| Build container | ECI(弹性container实例)/ ACK(containerservice) | ECI 按秒计费,按需起,关掉就停;ACK 适合大流量 |
| Update / Push service | ECS + 本机 SQLite | 一台 2c4g 起步(当前 backend = SQLite,Postgres 选项在路线图上) |
| Bundle 存储 | OSS(标准存储) | 0.12 ¥/GB-月 |
| CDN | Aliyun CDN | 0.24 ¥/GB egress(domestic / mainland China) |
| 域名 + ICP ICP filing | Aliyun域名 + ICP | ICP ICP filing ~10 工作日 |
最小可用configuration(< 50 Update MAU test规模):
- 1 台 ECS 4c8g(Update + Build orchestrator + 本机 SQLite)= ~¥260/月
- OSS + CDN(按用量,~¥30/月起)
- 后续加 Postgres 选项后:另起 RDS PG mini ~¥500/月(可选,SQLite 够用就不必)
- 域名 + cert:~¥80/年
总:~¥900/月(按 RDS)or ~¥350/月(SQLite 小规模)
跟 Keel Pro ¥48/月 vs self-hosted ¥350+/月 —— self-hosted只在你有合规要求 / 想完全控制时才划算。一般user直接 Pro 更省事。
Build 基础设施对位(vs Expo EAS)
Keel GA 的 Build 选型跟 Expo EAS 做了一次完整对照。决策原则:domestic / mainland China合规 + 计费形状匹配 build 负载(每个 build 30s–3min 短任务,闲时归零)。
| 维度 | Expo / EAS | Keel GA | 选型理由 |
|---|---|---|---|
| iOS build | AWS mac1/mac2 EC2 + Xcode + fastlane | macOS runner(自管 mac mini 池 / MacStadium 租用 / 当前可选跳过) | Docker 跑不了 Xcode;macOS 必须有真机或 mac 实例。当前可documentation标注「iOS 需 self-host mac runner」,先打通 android/web |
| Android build | AWS EC2 Linux + Gradle + Android SDK | Aliyun ECI(Linux container + Gradle + Android SDK + user上传 keystore) | domestic / mainland China合规 + ECI 按秒计费,build 完关掉就停 |
| Web / JS bundle | AWS EC2 Linux + Metro | Aliyun ECI(Metro container) | 同上;JS bundle 无平台 toolchain dependency,最轻 |
| Hermes 字节码 | EAS 自动 | 跟 Metro 同container内 hermesc -emit-binary(build-bundle.sh 已支持) | 一步出 .bundle + .hbc |
| Worker 池scheduling | 自管 pool(早期 Concourse → self-built) | 当前:os/exec docker 直接起 ECI ;后续看流量再做 pool | 启动期不抢scheduling复杂度;ECI cold start ~5s 可忍 |
| Artifact 存储 | S3 + CloudFront | OSS + Aliyun CDN | domestic / mainland China egress 0.24 ¥/GB;OSS 0.12 ¥/GB-月 |
| Provisioning / signing | EAS 后端集中management | user自管(CLI 上传 keystore / cert,server 不持久化) | 当前不碰 cert escrow,安全边界清晰;后续看需求再做 EAS 同款 |
| 计费 | 按 build 次数(mac vs linux 分级) | 按 build 次数(pricing Pro 档每月配额,超出按量) | mac build 单价高(mac1 实例 ~¥3/min),价格层级后续再分 |
| Cold start | EC2 boot ~30s | ECI 启动 ~5s(已 pull image)/ ~30s(首次 pull) | 短 build 也能划算 |
为什么不选 FC(函数计算)?
Aliyun FC 也能跑 docker image,但:
- FC 计费维度多(request次数 + 执行时长 + 资源大小),跟
pricing的「builds/月」配额映射麻烦 - FC image cold start 比 ECI 慢,OCI image 灵活度也低
- ECI 价格、配额、生命周期 API 都更直白,跟 build job state machine 1:1 对应
为什么当前不上 ACK / Kubernetes?
ACK(containerservice Kubernetes)适合常驻 worker 池 + 高 QPS 场景。当前test规模 < 50 builds/天,ECI on-demand 起停就够;Kubernetes scheduling复杂度 + 维护cost现在不值。流量起来(~1000 builds/天)后再评估迁 ACK。
overseasself-hosted栈
如果你是overseasuser(Keel 暂不开放overseas,但code Apache 2.0 你可以自己跑):
| service | 推荐 |
|---|---|
| Build | AWS ECS / GCP Cloud Run / Fly.io |
| database | Neon / Supabase Postgres / RDS |
| 对象存储 | S3 / R2 / Cloudflare |
| CDN | Cloudflare / Fastly |
| 域名 + HTTPS | Let’s Encrypt free |
升级策略
self-hosted版 Keel 后端的升级:
- 关注 GitHub Releases(已规范化 release)
- 每个 minor version(0.x)都向后兼容;major version(X.0)会有 migration guide
- 升级前看
docs/roadmap的 breaking changes 列表 - 滚动升级:先升一台 Update / Build replica,验证后再升其他
CI 加自动升级 PR 的好习惯(dependabot 等价)—— 后续会出 keel-action GitHub Action 帮你做。
data迁移:托管 → self-hosted / self-hosted → 托管
托管版导出(路线图):
keel export --workspace=your-ws --to=./backup.tar.gz
导出包含:所有 Update bundle + manifests + push subscriptions + project metadata。
self-hosted版导入:
keel-update-server import --from=./backup.tar.gz
反向也支持(self-hosted → 托管)。这是 GitLab / Sentry self-hosted可迁移的同套理念。
安全
self-hosted场景下你自己负责:
- HTTPS cert + 续签
- database备份策略(建议 PG WAL + S3 异地备份)
- API key management
- 防火墙 / SG configuration
- 日志 + audit trail
- DDoS 防护(云厂商基础版够小流量;高流量需要 WAF)
参考enterprise部署清单:enterprise部署 checklist。
跟商业版的feature parity 承诺
承诺:Keel self-hosted版feature上跟商业版完全一样。商业版不阉割open source版。
商业版卖的是:
- 托管运维(不用你自己搞 DB / CDN / 监控)
- SLA(24h / 4h 工单response)
- 优先 build queue(busy 时段不用排队)
- 团队 / enterprise级账号management
- 对公开票
codefeature = 完全一致。
enterprise部署 checklist
(后续完整撰写;现在草稿)
- HA 部署(Update service ≥ 2 replicas + LB)
- Database HA(PG 主从 / 多副本)
- 对象存储跨区域复制
- CDN 多 edge configuration
- 监控告警(Prometheus + Grafana 等)
- 日志聚合(ELK / Loki / SLS 等)
- Audit log 长期归档
- database备份(≥ 每日 + 异地)
- 灾备演练
- 安全 hardening(最小permission / 网络分段 / WAF)
- 合规:ICP ICP filing / data出境申报(如适用)
- private npm image(防 npm.org 不可达)
常见问题
Q: self-hosted Keel 还能用 Keel Go tester app 吗?
可以,但需要重定向到你的self-hosted后端。Keel Go 启动时输入 endpoint URL;指向你的 Update service / Build endpoint 即可。或自己 fork Keel Go + rebuild 一个 brand 化的 tester。
Q: self-hosted版能接 Mortar 吗?
能——但 Mortar 是另一个独立产品。self-hosted Keel 跟用 Mortar Cloud(托管)/ Mortar self-hosted版(也open source)都解耦,正交不冲突。详见 Mortar deployment。
Q: License 限制?
Apache 2.0 —— 想 fork / 商业用 / 改名都可以。唯一限制:不能用 “Keel” 名字 / logo 宣传你的衍生品(按 license § 6 商标条款)。
详见 LICENSE + governance.md。
Q: self-hosted版有没有paid支持?
后续会出 Enterprise Support 合同(24h SLA + private deployment + 安全update)。详见 pricing.md Enterprise 档。
报 issue / 求助
- GitHub Issues +
keel+self-hostlabel - GitHub Discussions / Self-host 频道
- 商业支持:support@keel.appunvs.com