短週期發版時，把 Gitea 或 Forgejo 放在輕量 VPS 當「真相來源」很常見；昂貴的是 Apple 硬體上的原生 Xcode 建置。務實做法是：控制面留在自託管 Git（審核、Webhook 出口），執行面用按天雲端 Mac 專跑 xcodebuild、簽章與產物上傳，把暴露面壓在小型 Linux，同時讓 macOS 工時只在有推送時才醒來。
為何要把「管理面」與「建置面」拆開？
Forgejo／Gitea 的 Web 與 SSH 若直接暴露在公網，攻擊面含帳密爆破、CVE 與外掛。把 Webhook 接收器放在小 VPS、只開 443 與管理隧道，雲端 Mac 只接受資產清單內來源（固定 IP、WireGuard 或反向 SSH），可把「可被掃描的服務」與「放憑證的機器」分開；執行面只需唯讀 HTTPS 或 Deploy Key 拉程式碼。
Webhook：觸發節奏、重放與佇列
建議在 VPS 上放一層極薄的接收程式：驗證 X-Gitea-Signature（或 Forgejo 相容標頭）、比對事件類型與分支、做幂等鍵（delivery id）去重，再把工作丟進本機佇列或 Redis，最後由常駐程序對雲端 Mac 下發 SSH／runner 觸發。不要把密鑰寫進倉庫的 .gitea/workflows 再回傳到公網日誌；改由接收器注入短期令牌。關於雲 Mac 開通後 Runner 註冊與最小權限落地，可延伸閱讀：2026年短週期突發建置併網：雲 Mac 開通後 Runner 註冊、網路自檢與最小權限令牌的 30–60 分鐘落地清單與 FAQ。
# VPS 上僅暴露 HTTPS，由反代轉發到本機埠 POST /hooks/ios-build # 驗簽 → 入佇列 → 觸發雲端 Mac job
最小權限令牌：該發哪一種？
企業資源池裡常混著多個 AppId。原則是「能唯讀就不讀寫」「能單一儲存庫就不給組織級」「能短期就不長期」。下表用於與資安／法遵對齊時的快速溝通。
| 用途 | 建議令牌類型 | 權限邊界 |
|---|---|---|
| 雲端 Mac 只拉程式碼 | Deploy Key（唯讀）或 CI 專用機器人帳號＋細粒度 token | 禁止 merge、禁止管理 webhook |
| Webhook 接收器回寫狀態 | 僅含 statuses／commit_statuses 範圍的 token |
與建置憑證分開儲存 |
| 發版產物上傳內部制品庫 | OIDC／短期 STS，或單次簽發的上傳 URL | 與 Git 主機密鑰物理隔離 |
企業資源池：隔離決策矩陣
若多部產品共用一池雲端 Mac，請在「資料面」與「身分面」同時切開：每條流水線獨立 keychain 分區或獨立使用者、DerivedData 目錄帶專案雜湊尾碼、同一時段禁止跨專案重用未清空的簽章快取。需要類比 Jenkins Controller／Agent 拆分的讀者，可對照：2026年Jenkins混合拓撲：Controller駐輕量VPS與雲Mac Agent的JNLP回連及企業資源池落地清單，其中「輕量控制面＋重執行面」的邏輯與本文一致。
| 情境 | 建議 | 取捨 |
|---|---|---|
| 多團隊共用一臺雲 Mac | 排程互斥鎖＋建置前清理腳本 | 吞吐下降，換取憑證不串味 |
| 高敏原始碼 | 專用節點池，Git 僅內網鏡像 | 成本上升，稽核最簡單 |
| 按天計費壓力大 | Webhook 合併（push debounce）與矩陣縮減 | 回饋較慢，適合夜間批次 |
在雲端 Mac mini 上，控制面與執行面更好銜接
自託管 Git 觸發的 iOS 原生建置，最終仍要落在 Apple Silicon 與官方工具鏈上。雲端 Mac mini（M 系列）提供與本機一致的 Xcode、Unix shell 與常用二進位介面，不必在 Linux 上維護脆弱的交叉編譯腳本；統一記憶體架構讓大型 Swift 專案在連結階段較不易因記憶體頻寬成為隱性瓶頸。
從運維角度看，macOS 長時間無人值守的穩定度與 Gatekeeper、SIP 等內建防線，可降低公開 Webhook 與簽章機並存時的整體風險；而約 4W 量級的待機功耗，讓「常駐等待觸發」不會變成電費與散熱負擔。把 VPS 當閘道、把雲端 Mac mini 當執行沙盒，是短週期團隊常見的總體成本最優解之一。
若你正在把 Gitea／Forgejo 流水線接到可預測的硬體上，VPSSpark 雲端 Mac mini M4 是容易試算產能與成本的切入點——立即了解套餐方案，讓 Webhook 觸發後的每一分鐘都花在真正的編譯與簽章上。