2026 年租用裸金屬遠端 Mac 做 iOS CI／CD：
自託管 Runner、建置佇列與 1TB／2TB 快取規劃

很多團隊第一次上遠端 Mac CI，會把失敗簡單歸因到「機器不夠快」。但在 Apple Silicon 上，真正決定體驗分布的往往是資源獨占程度、快取是否可復用、以及 Runner 行程模型是否與 Xcode 的並行假設匹配。裸金屬的價值在於把「鄰居干擾」從變數裡拿掉，但你仍需要把下列痛點逐條寫進審查材料，否則預算會花在錯誤階梯上。

• 快取雪崩：多台 Runner 若各自冷啟動 DerivedData，會把編譯時間拉長到不可接受的尾延遲；沒有磁碟預算時，快取還會被系統清理策略誤傷。
• 簽章脈絡漂移：鑰匙圈、描述檔、團隊 ID 與機器綁定策略不一致時，失敗會表現為難以對照的 redacted error。
• 產物跨區：程式碼庫與套件來源、容器 registry、內網產物庫若與 Runner 不在同一地理與網路路徑上，拉取階段會吃掉大量 wall time。
• 單節點多 Job 的記憶體護欄：並行跑 UI 測與編譯時，M4 16GB 更容易觸發記憶體壓力與換頁，從而把「偶發慢」變成「每天固定時段慢」。
• 佇列策略缺失：沒有 label 與並發上限時，重型任務會插隊，導致輕量 PR 檢查失去「幾分鐘回饋」的意義。
• 維運邊界不清：自託管 Runner 需要有人對 macOS 升級、Xcode 多版本並存、磁碟水位與日誌輪替負責；否則會出現「流水線能跑但不穩定」。

補充而言，同一台伺服器在夜間跑大量 UI 的團隊，需要讓日間的輕量檢查與夜間批次在時間窗上錯開。把 label 當成車道分隔線，並把並發上限寫成數字，才能把討論從感覺拉回到契約。

此外，若簽章驗證或測試報告上傳依賴對外網路，出口頻寬也會成為尾延遲變數。裸金屬並不代表網路無限，仍應把 DNS 與頻寬觀測納入 Runner 健康訊號。

結論先行：先定快取與產物同區，再定 Runner 數量與租期組合。否則會用更高配掩蓋結構性問題。

下面矩陣用於審查會對齊：它不是替你做最終答案，而是把「並行模型」與「記憶體／磁碟」綁在一起，便於把預算拆到正確維度。若你們以 PR 檢查為主、Archive 為輔，通常會更偏向佇列化與快取復用；若以夜間大批量 UI 測為主，則更偏向高配與磁碟餘量。

當你把矩陣落到 CALMVPS 的產品結構時，重點不是「買最貴」，而是讓節點區域覆蓋與設定梯度覆蓋同一套決策鏈：亞太與美東美西都有節點時，更容易把產物與 Runner 放在同一大洲內；需要把重任務臨時並行時，再用並聯資源把佇列寬度拉開，而不是把單台機器推到極限。

實務上，同一套專案設定在不同區域量測到的 wall time 可能差很多，遷移機房時務必重新建立基線，把 TLS、企業 Proxy、內網路由一併列入變更單，避免只換機不换網路假設。

自託管 Runner 的工程化核心，是把「可復用資產」與「不可復用機密」分層管理。快取層應盡量共享且可重建；簽章層必須可稽核且最小權限；網路層則應盡量讓 Runner 到產物庫的路徑短且穩定。下面給出一條常用的目錄規劃思路：把 DerivedData 與自訂快取根放到獨立分割區或大目錄上，並在流水線裡顯式傳入 -derivedDataPath 或同等封裝，避免預設目錄在系統升級後被清理策略影響。

GitHub Actions 自託管 Runner 的概念模型與限制應以官方文件為準。發版後請再次打開連結核對標題與條款。

https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners

若你們使用其它 CI 控制器，仍建議把「Runner 行程生命週期」與「Xcode 工作階段生命週期」拆開思考：Runner 負責拉程式碼與上報；Xcode 負責編譯與測試；兩者之間的環境變數、鑰匙圈解鎖時機與並行上限必須在同一頁 runbook 裡寫清。

大型模組化專案中，索引與模組快取也會快速長大；若沒有輪替與壓縮策略，擴容只會延後爆滿時間而不會消除根因。

export RUNNER_ALLOW_RUNASROOT=0
defaults read com.apple.dt.Xcode.plist
df -h
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
xcodebuild -showsdks

這組命令的價值是值班時能快速判斷「慢來自磁碟水位」還是「來自 SDK 選擇錯誤」。在遠端裸金屬上，磁碟寫入放大往往來自日誌、測試產物與索引檔；因此把水位閾值寫進告警比單純擴容更重要，否則 2TB 也會被無輪替日誌吃光。

產物同區還意味著：如果你的程式碼託管在某一雲廠商的 Git 服務，而內網產物庫在另一區域，Runner 應優先選能把兩段延遲同時壓低的落點。CALMVPS 提供多區域節點時，你可以用「同一大洲優先」作為第一性原則，再用 遠端桌面與除錯頁面 裡的接入方式完成人工驗收與 UI 覆核，而不是把遠端桌面只當成臨時救急通道。

下面清單假設你已獲得 SSH 管理入口，並且目標是在裸金屬上長期執行自託管 Runner。每一步都應留下可稽核輸出，便於後續把環境從 A 區域遷移到 B 區域時復用。

1. 凍結基線：記錄 macOS 版本、Xcode 版本、Swift 工具鏈版本與 Runner 版本，形成變更單的「前後對照欄位」。
2. 建立專用帳號：Runner 與人工除錯帳號分離，降低鑰匙圈與權杖外洩面；同時把 sudo 邊界寫清。
3. 磁碟分割策略：為 DerivedData、測試產物與日誌分配獨立目錄或大容量掛載點；把清理策略寫成排程或流水線步驟。
4. 安裝與註冊 Runner：依平台官方流程註冊到對應儲存庫或組織；為不同佇列設定 label，避免重任務插隊。
5. 簽章與描述檔注入：把「哪些金鑰允許在 CI 使用」與「哪些必須禁止匯出」寫成表格，避免用同一台機器同時承擔開發與發行。
6. 最小流水線驗證：先跑編譯與單元測試，再逐步開啟 UI 測與 Archive；每一步記錄 p95 與 p99 耗時。
7. 上線告警：磁碟水位、Runner offline、佇列堆積與失敗率突增要進同一套值班入口；並把擴容觸發條件對齊到 定價頁 可採購的階梯與租期。

第七步的關鍵是把擴容變成可採購動作：當佇列堆積持續超過閾值時，優先增加並行節點或短租並聯資源，而不是無限提高單節點並發，否則會把不穩定寫進尾延遲分布。

同時要把 Runner 升級與 macOS 升級放在同一變更火車上協調，否則會出現「Runner 已更新但系統工具鏈未跟上」的半套狀態，最難除錯。

• 自託管 Runner 的軟體邊界：GitHub 文件說明自託管 Runner 可用於私人儲存庫自動化，但對機器管理與安全修補責任在組織側；這代表你必須把 macOS 升級與 Xcode 升級納入同一套變更視窗。
• Xcode 快取路徑的工程語意：Apple 開發者文件對 DerivedData 與相關資料位置有說明；把它寫進 runbook 能減少「換機後快取遺失」導致的不可解釋變慢。
• Apple Silicon 統一記憶體模型的限制：Apple 平台文件將 Apple Silicon 描述為統一記憶體架構；在 CI 情境裡，它更直接地轉化為「並行峰值記憶體壓力會同時影響編譯與 UI 測」的耦合關係，因此階梯選擇必須與並行模型綁定審查。

Apple 平台技術說明請以 Apple 開發者網站為準。

https://developer.apple.com/documentation/

把三條門檻寫進變更單的意義在於：它們能把討論從「感覺慢」拉回到「可驗證資源邊界」。

另外建議把「同時開啟模擬器數量上限」「大型測試錄影是否啟用」等運維參數也寫進同一頁，避免個人習慣差異造成尾延遲漂移。

脈衝型建置團隊常見結構是：平時用較低並行完成 PR 檢查，發版週把夜間批量測與 Archive 並行化。此時成本護欄應同時包含「佇列寬度」和「磁碟保留週期」：短租並聯資源負責擴寬度，月租或季租負責穩定 Hub 與快取熱集合；1TB 與 2TB 擴容則決定你能保留多少歷史 Xcode 版本與多少套 DerivedData 以便回滾對照。

FAQ：M4 16GB 能不能跑 UI 測？ 可以，但建議把 UI 測與重編譯錯峰，或拆佇列到不同節點；否則尾延遲會被記憶體壓力放大。

FAQ：為什麼裸金屬比「看起來便宜的共享環境」更適合生產 CI？ 生產 CI 的關鍵是尾延遲與可重複性；獨占 CPU 與穩定磁碟更容易把失敗歸因到程式碼與設定，而不是平台鄰居干擾。

FAQ：日租／週租適合解決什麼問題？ 適合驗證新 Xcode 版本、臨時擴容峰值、以及跨區域對比建置耗時；驗證結束後再決定是否轉入月租或季租鎖住環境。

分時虛擬化與超賣環境的主要風險是尾延遲與資源爭搶，且更難把問題定位到單一變數；家庭寬頻與非專業機房則常見上行抖動與睡眠策略導致的離線。需要把 iOS CI 當成穩定生產面時，CALMVPS 的 Mac Mini 雲端裸金屬租賃更容易把「節點區域、設定梯度、並聯資源價格」對齊到同一套採購與擴容語言裡：獨占 Apple Silicon、7×24 在線、按月彈性下單，120 秒交付。請打開 CALMVPS 定價頁 對照目標區域與階梯，並把佇列與快取策略一併寫進審查附件。

對財務與資安利害關係人，建議把「再執行率」「磁碟清理工單頻率」「金鑰輪替週期」與租期決策放在同一簡報，才能把隱性營運成本講清楚。