在 Windows 或 Linux 辦公、卻要把 iOS / macOS 流水線跑穩的團隊,2026 年最常見的分叉是:繼續用 GitHub 託管 macOS Runner(按分鐘計費、環境 ephemeral),還是在 遠端獨享 Mac mini 上註冊 self-hosted Runner(持久磁碟、可預測月費)。本文主場景是後者——GitHub Actions 自建 macOS Runner,不寫 OpenClaw 或 Agent 運維。下文按「託管 vs 自建 → 六地節點 → M4 記憶體與併發槽位 → DerivedData 與磁碟 → 並聯 label → 註冊 HowTo → 日租—月租 TCO → FAQ」展開;套餐與地區結帳見 定價方案,Runner/SSH 說明見 幫助中心。若你也在評估常駐自動化,可與站內 OpenClaw 遠端 Mac 實操指南 對照閱讀,但本文敘事以 CI/CD 為主。
一、2026 託管 macOS Runner vs 遠端 Mac 自建:分鐘費、佇列與何時該租裸金屬
GitHub 對 macOS 託管 Runner 按倉庫/組織的 Actions 用量計費,單價與免費額度以 GitHub 官方計費文件 為準(2026 年起託管 Runner 價格有過調整,上線前請核對當前分鐘單價)。託管環境的優勢是零運維:每次 job 在乾淨映象上起跑,適合低頻 PR、偶發 Archive。劣勢也明確:DerivedData / SPM 快取難以跨 job 長期保留,高峰時段可能排隊;分鐘數一多,帳單波動大。
在 Nuvcloud 等獨享 M4 Mac mini 上自建 Runner,本質是買「固定席位 + 持久 SSD」:同一臺機器上 actions-runner 由 launchd 守護,~/Library/Developer/Xcode/DerivedData 可跨 PR 複用,增量編譯往往比冷啟動託管 Runner 快一截(具體幅度取決於工程規模,下文用算例模板而非承諾 SLA)。
| 路徑 | 更適合 | 主要代價 |
|---|---|---|
| GitHub 託管 macOS | 每月 macOS 分鐘 < 數百、無持久快取訴求、不想碰機器。 | 分鐘費 + 佇列;DerivedData 難沉澱。 |
| 遠端 Mac 自建 Runner | 日更 main、多 scheme 並行、要快 Archive/TestFlight。 | 需管 Runner 升級、磁碟與簽名互斥;月租可預測。 |
| 自購 Mac mini 放辦公室 | 單機、無多地域訴求、能接受斷電與公網暴露治理。 | 採購 + 電費 + 運維人力;擴容要再買硬體。 |
12 個月 TCO 算例模板(範例假設,請代入自家數字):設託管 macOS 單價為 P 元/分鐘,月消耗 M 分鐘,則年託管成本 ≈ 12 × M × P。設遠端 Mac 月租為 R 元(含機位與頻寬),年租成本 ≈ 12 × R。當 M × P 持續高於 R 且你需要持久 DerivedData 時,自建通常更划算;若 M 很小且波動大,可先託管或日租遠端機驗證一輪流水線再轉月租。
二、新加坡/日本/韓國/香港/美東/美西:按 Git、Registry、製品庫就近選節點
Nuvcloud 在亞太提供新加坡、日本、韓國、香港節點,在北美提供美東、美西方向(具體可用區以 結帳向導 為準)。選型時不要問「離我家近不近」,而要問:Git 遠端、Container Registry、TestFlight/簽名服務、以及團隊主要值班時區落在哪。已確定配置可直接進入地區頁:新加坡、日本、韓國、香港、美東、美西。
建議在候選節點各跑同一套基準:git clone --depth=1、拉取 1GB 級製品、一次 xcodebuild -showBuildSettings 冷啟動與熱啟動對比。SSH 管理員的 RTT 隻影響體感,不決定 CI 總時長。
| 節點 | 典型優先場景 | 協作分工提示 |
|---|---|---|
| 新加坡 | 東南亞使用者製品、GitHub 亞太映象、面向 SG/MY 團隊的 Runner。 | 與香港二選一時,看誰的主倉在亞太中南部。 |
| 日本 | 日本法人合規、東京周邊協作者、日區夜間釋出視窗。 | 適合「亞太研發 + 日本 QA」雙時區。 |
| 韓國 | 韓國市場 App、本地 CDN 源站、首爾團隊 SSH 排障。 | 與東京類似,以業務資料面而非 ping 決策。 |
| 香港 | 大陸/港澳團隊混合、亞太主倉在華南。 | 大陸辦公室 SSH 體感常優於直連美西。 |
| 美東 | GitHub 生態預設美東、東海岸 SaaS、npm/Actions 快取命中美東。 | 以 CI 製品路徑為準,勿只看地圖距離。 |
| 美西 | 西海岸協作、部分映象託管美西、面向美西使用者的夜間構建。 | 亞太 SSH 可能略慢,但 job 拉依賴仍可能更快。 |
三、M4 16GB/256GB 與 24GB/512GB、M4 Pro:併發 Runner 槽位與模擬器上限
在 Apple Silicon 上,一個物理 Runner 程序對應 GitHub 的 runs-on: self-hosted;單機能否同時跑幾個 job 取決於 Runner 併發設定與 Xcode/Simulator 記憶體峰值。M4 16GB 適合 1 個重編譯或 2 個輕量 job;24GB 適合 1 個 Archive + 1 個單模擬器 UI 測試;M4 Pro 高配 留給多模擬器矩陣或超大 monorepo。
| 配置 | 建議併發 Runner / worker 上限(經驗值) | OOM / 卡頓訊號 |
|---|---|---|
| M4 16GB / 256GB | 1× 全量 xcodebuild,或 2× 僅 lint/單測。 |
memory_pressure 頻繁 Yellow;Simulator 啟動失敗。 |
| M4 24GB / 512GB | 1× Archive + 1× UI 測試;或 2× 中等編譯 job(不同 DerivedData 字首)。 | 並行 UI 測試時 WindowServer 飆升;swap 導致尾延遲變差。 |
| M4 Pro 更高配 | 多模擬器 OS 版本矩陣;同時保留 2 套 Xcode 次要版本。 | 磁碟 IOPS 先於 CPU 成為瓶頸(見下一節)。 |
Workflow 裡用 runs-on: [self-hosted, macOS, compile] 與 runs-on: [self-hosted, macOS, ui-test] 把重活拆開,比在單機上把 Runner 併發拉滿更安全。
四、1TB/2TB 擴容與 DerivedData:並行 worktree 磁碟規劃與清理清單
託管 Runner 每次 job 往往從乾淨環境起跑,DerivedData 無法沉澱;自建 Runner 的最大收益之一就是讓 ~/Library/Developer/Xcode/DerivedData 跨 PR 存活。並行 job 時禁止多 workflow 寫同一 DerivedData 目錄——須為每個 job 設定獨立 DERIVED_DATA_PATH(或 -derivedDataPath),必要時配合 Git worktree。
- 可本地持久:DerivedData、SwiftPM 快取、CocoaPods(若版本鎖定)。
- 更適合 Actions cache:可再生的工具鏈 zip、Lint 快取、體積大但可下載的依賴包。
- 磁碟告警:可用空間 <20% 觸發 DerivedData LRU 清理最舊 30%;<10% 應 drain 該 Runner 不再接新 job。
| 磁碟 | 典型 CI 用法 | 何時值得升級 |
|---|---|---|
| 256GB–512GB 基線 | 單 Xcode 版本 + 單倉庫 DerivedData;定期清理 Archives。 | 單倉 DerivedData 已 >40GB 或需並存 2 個 Xcode。 |
| 1TB | 2–3 個活躍分支快取 + 模擬器執行時;並行 worktree 2 路。 | monorepo 多 scheme nightly 全量編譯。 |
| 2TB | 多 Xcode 次要版本、歷史符號、大體積 SPM 二進位制快取。 | 不想在 job 間頻繁 rm -rf DerivedData 的團隊。 |
五、並聯資源拆分:多機 label、shard 與「輕量驗證→連續開發」升級路徑
當單機併發已頂到記憶體天花板,下一步是並聯多臺遠端 Mac,用 label 做職能切分:
mac-ci-compile:只做xcodebuild build,保留 DerivedData。mac-ci-archive:獨佔簽名與上傳,workflow 裡用concurrency互斥,避免雙 job 搶鑰匙串。mac-ci-ui:掛模擬器測試,記憶體更大的一臺(24GB 或 Pro)。
升級路徑:日租單機驗證 workflow → 週租跑通快取策略 → 月租固定 IP 與 Runner 指紋 → 按需加第二臺做 shard。多臺機器時,GitHub actions/cache 仍可共享「可再生產物」,但 DerivedData 仍以各機本地 SSD 為準。
六、HowTo:在遠端 Mac 註冊 self-hosted Runner
流程以 GitHub 官方文件:新增自託管執行器 為準(介面與令牌欄位可能隨版本變化)。在 Nuvcloud 機器上建議順序:
- SSH 登入,安裝 Xcode Command Line Tools / 目標 Xcode,接受許可協議。
- 建立專用 Unix 使用者或在現有使用者下建
actions-runner目錄,勿用個人 Apple ID 直接簽名生產包。 - 從倉庫 Settings → Actions → Runners 獲取註冊命令,執行
config.sh,為 Runner 打上macos、m4、地區等 label。 - 用
launchd安裝為服務(svc.sh install),確保 SSH 斷開後程序仍存活。 - 在 workflow 中設定
DERIVED_DATA_PATH,並對簽名 job 加concurrency: { group: codesign, cancel-in-progress: false }。
env:
DERIVED_DATA_PATH: ${{ github.workspace }}/DerivedData/${{ github.run_id }}
RUNNER_TOOL_CACHE: /Users/runner/actions-toolcache
xcodebuild \
-scheme "YourApp" \
-derivedDataPath "$DERIVED_DATA_PATH" \
build
七、日租/週租/月租 TCO 對照與升級配置
把「試執行」和「生產 Runner」分開算帳,能避免用日租價格去類比月租產能:
| 週期 | 適合階段 | CI 側注意點 |
|---|---|---|
| 日租 | 六地節點 A/B、驗證 DerivedData 是否真提速、試註冊 Runner。 | 結束日匯出簽名證書說明與快取目錄清單;勿把生產金鑰留在日租機。 |
| 週租 | 釋出衝刺、遷移託管 Runner 工作流、並聯第二臺前的壓測。 | 凍結 Xcode 小版本;記錄 workflow 變更與分鐘節省量。 |
| 月租 | main 分支日構建、固定 Runner 名、IP 白名單與快取策略固化。 | 預留升級路徑:16GB→24GB、加盤、加第二臺 label 分片。 |
36 個月粗算(範例假設):自購 Mac mini + 電費 + 運維人力 = C_cap;遠端月租 = 36 × R。若團隊無專職 Mac 運維,C_cap 常被低估。對比託管分鐘費時,記得把「排隊導致的交付延遲」折進機會成本,而不只比單價。
機型與週期請在 定價方案 對照;已購使用者透過 控制中心 續費與擴容。更多實踐可瀏覽 技術部落格 索引。
八、常見問題(FAQ)
Q1:自建 Runner 是否違反 GitHub 條款?
在自有或租用的 Mac 硬體上註冊 self-hosted Runner 屬於官方支援路徑;請勿將 Runner 出售給無關第三方或用於違規用途(以 GitHub Terms 為準)。
Q2:能否與託管 macOS Runner 混用?
可以。例如 PR 用託管、main 用自建;注意 secrets 與簽名證書只在自建機可用時的 workflow 分支條件。
Q3:DerivedData 快取何時該清?
Xcode 升級、切換 major 分支、或磁碟低於 20% 時做 LRU;勿在並行 job 執行時整目錄 rm -rf。
Q4:SSH 斷線後 job 會停嗎?
不會——job 由 Runner 服務程序執行。SSH 隻影響你手工排障;請用 launchd 託管 Runner。
Q5:遷移節點後快取怎麼辦?
DerivedData 與本地路徑強繫結,遷移地區通常需重新預熱;可先用 Actions cache 搬運 SPM/工具鏈,再跑一輪全量編譯生成新 DerivedData。
Q6:16GB 上能開幾個模擬器並行?
不建議在 16GB 上並行多個重型 UI 測試;拆到第二臺 mac-ci-ui label 更穩。
Q7:簽名 job 為什麼要互斥?
兩把鑰匙串同時解鎖、雙 Archive 上傳可能觸發證書鎖或覆蓋同名 ipa;用 concurrency 序列化簽名階段。
Q8:日租結束如何防止令牌洩露?
在 GitHub 移除 Runner、輪換 PAT/註冊 token、清理鑰匙串與 ~/.ssh 中臨時金鑰(確認無其他服務依賴後)。
在雲端 Mac mini 上,CI 編譯更穩、更省分鐘
自建 GitHub Actions macOS Runner 的核心,是把持久 DerivedData、可預測月費和多地區獨享算力握在自己手裡。Nuvcloud 的裸金屬 M4 Mac mini 提供原生 Unix 工具鏈、Gatekeeper/SIP/FileVault 安全基線,以及適合 7×24 無人值守的功耗與穩定性;從日租驗證節點到月租固化 Runner,還可按需升級 24GB、擴容 SSD 或並聯第二臺做 label 分片。
若你正從託管 macOS 分鐘費遷到自建流水線,Nuvcloud 雲端 Mac mini M4 是價效比很高的起點——立即瞭解套餐方案,讓節點、記憶體與快取策略一次配對、少返工。