自托管 Gitea/Forgejo | 轻量 VPS 控制面与按天云 Mac iOS 构建、Webhook 与令牌 FAQ

2026 年不少团队用自托管 Gitea/Forgejo 管代码，把可签名的 iOS Archive 放到按天云 Mac：轻量 VPS 只做 Webhook、队列与状态回写，执行面留在 Apple 硬件。拆分的目的是收敛暴露面、令牌权限与突发成本，下文用矩阵汇总常见分叉。

2 面

控制面（VPS）与执行面（云 Mac）

最小

仓库级只读 + CI 专用令牌

幂等

delivery 与 commit 指纹去重

为什么要把 Git 服务和构建触发拆开？

Git 与数据库同机小 VPS 时，CPU 与盘主要服务 MR 与浏览；若把重编译压在同一台 Linux，既没有合法签名链，也会拖垮 Webhook 与页面。更稳的是事件进 TLS 网关，由队列验签限流，再唤醒带钥匙串的云 Mac 跑 xcodebuild。对照 2026年Jenkins混合拓扑：Controller驻轻量VPS与云Mac Agent的JNLP回连及企业资源池落地清单里 Controller 与 Agent 的切分，把「谁触发」与「谁持证书」拆成两张 RBAC。

Webhook：签名、重放与队列

仓库侧开启 HMAC 并轮换；入口只认正确摘要，挡掉扫描流量。delivery 常重复，消费者用「仓 ID + commit SHA + 分支」作幂等键并短时去重，避免一 push 三套 Archive。跨区时把 Webhook RTT 单独打点，勿与编译阶段混计，以免把 TLS/DNS 慢误判成云 Mac 慢。

入口伪代码（校验思路）

# 1. 校验 X-Gitea-Signature / X-Forgejo-Signature（与文档一致）
# 2. 解析 ref / head_commit.id，写入幂等键
# 3. 仅 enqueue；真正 git fetch 在云 Mac 上用 deploy key 完成

别把管理员 PAT 写进 Runner

组织级个人访问令牌一旦泄露等于整站搬家。CI 只发「单仓库 read_package / repo」范围的机器用户或 deploy key；状态回写可用 scoped token 或只写 commit status 的集成账号。

最小权限令牌怎么选？

只读构建优先 deploy key，勿把员工 PAT 塞进 Runner。子模块或基线镜像用机器账号 + 仓级令牌，云 Mac 侧钥匙串或一次性环境注入，job 结束即废。要写 Release，另发短寿写令牌，与日常读令牌隔离。

企业资源池隔离：一页决策矩阵

多产品共池时先按证书与 Bundle ID 划界，再按并发预算划队列；勿把外包只读仓与含 App Store Connect API Key 的主干仓混池。

场景	推荐隔离	令牌与触发
单一产品线、内网 Git	单池云 Mac + 共享 DerivedData 基线	每仓 deploy key；Webhook 经 VPS 队列
多团队同 Org	按团队划 Runner 标签与钥匙串分区	机器用户分团队；禁止共用 org 管理员 PAT
外包 / 供应商只读接入	独立只读镜像仓 + 独立构建池	只读 key；禁止写 status 到主干（用评论机器人中转）
与 GitHub 商业仓混用	镜像或只同步 release tag	双远端分密钥；避免同一 ssh-agent 混挂两域凭证

缓存与执行面：两个高频 FAQ

FAQ：云 Mac 上还要不要再挂一层远程缓存？

短周期更怕冷拉依赖而非 CPU；DerivedData/Pods 放本机还是对象存储，看出口与锁文件世代，对照 2026 短周期云 Mac CI：远程构建缓存对比节点本地盘（DerivedData、Pods、sccache）再定，勿默认远程更快。

FAQ：按天云 Mac 适合常驻监听 Webhook 吗？

不适合。监听与鉴权应常驻 VPS；云 Mac 出队再拉代码、构建、回写后释放，才能把按天费用压在真编译时段。

落地顺序建议

先打通「签名 Webhook → 幂等队列入队 → 云 Mac 单次成功回写」再谈并行度；否则资源池一扩，重复构建与令牌泄露面会同步放大。