GitHub Actions macOS Runner：2026 成本判斷

GitHub Actions macOS Runner 的第一個誤區，是把 GitHub 的分鐘帳單直接當成 CI 成本。對託管 Runner，你要計算：

託管總成本 = 可計費執行分鐘 × Runner 費率 + 儲存與快取費用 + 超額或並發相關費用

GitHub 目前文件列出的標準 macOS Runner 費率為每分鐘 0.062 美元，而且每個工作流程工作所使用的零碎分鐘會進位到整分鐘；私有倉庫還要按照方案的免費分鐘額度與超額用量計算。這個數字只代表平台執行費，不代表一次構建的完整成本。請以官方 Actions Runner pricing為準。

自託管則不能把「沒有 GitHub 執行分鐘帳單」理解成零成本。你需要把下列項目加總：

• 遠端 Mac 的週期租用費，以及未執行任務時的閒置時段。
• macOS、Xcode、Homebrew、Runner 軟體與依賴套件的更新工時。
• 快取與 DerivedData 造成的硬碟佔用、清理及狀態污染。
• 斷線、重啟、磁碟滿載、工作中斷後的人工恢復。
• 節點無法服務時，排隊、延遲發布或臨時切回託管 Runner 的損失。

因此，正確的輸入不是假設「每月使用率很高」，而是你最近一個完整帳期的工作流資料：實際執行分鐘、工作數、平均排隊時間、失敗重跑次數、快取命中率與人工維護時間。

先從 GitHub Actions 的工作流歷史中取數，不要先設定一個理想使用率。至少記錄以下欄位：

• 每個工作在 macOS Runner 上的實際執行時間。
• 每天或每週的構建次數，以及同時啟動的工作數。
• 工作從 queued 到開始執行的等待時間。
• 失敗後重跑的比例，並區分程式錯誤與環境錯誤。
• 每月產生的 artifact、快取與測試報告保留量。

若你的工作流只是偶爾發布、低頻打包，託管 Runner 的彈性通常更重要。你只在工作開始時付費，不需要為整月在線的節點買單。公開倉庫使用標準 GitHub-hosted Runner 時，官方文件說明執行分鐘可免費使用；私有倉庫則受方案額度與超額計費影響。相關規則可在GitHub Actions 計費文件核對。

若多個分支每天持續構建，固定的自託管節點可能降低等待與環境準備成本。但你必須確認節點是否真的被持續使用。低並發團隊常見的浪費，是租了一台全天在線的遠端 Mac，實際只在少數時段執行 Xcode CI。

不要用「每月超過多少分鐘就一定值得自託管」這種通用答案。成本拐點取決於你的租用週期、工作流是否並發、每次構建是否需要簽名，以及工程師每月願意投入多少維護時間。

GitHub-hosted Runner 的特徵是每個工作通常在新的 Runner 實例中執行；自託管 Runner 則可以保留工具鏈、依賴與部分快取。這會直接影響 Xcode CI 的有效構建時間，但不能把所有速度差異都歸因於快取。

GitHub-hosted Runner 的標準 macOS 配置目前包含 Intel 與 arm64 類型；例如文件列出的標準映像包含 4 核心、14 GB 記憶體、14 GB SSD 的 Intel 類型，以及 3 核心、7 GB 記憶體、14 GB SSD 的 M1 類型。實際可用映像、標籤與規格會更新，應以GitHub-hosted Runner 參考頁為準。

要比較快取是否帶來真實收益，請用同一個提交、同一個 Xcode 版本、同一組測試目標做至少兩輪對照：

1. 在乾淨環境執行一次，記錄依賴下載、編譯與測試時間。
2. 在相同環境執行第二次，記錄 Swift Package、CocoaPods 或其他依賴的快取命中。
3. 在自託管節點執行同一提交，分別測試暖快取與清理後的冷快取。
4. 比較總耗時，而不是只看 xcodebuild 的編譯時間。
5. 檢查快取命中後是否仍會因舊版 DerivedData、錯誤的 SDK 或殘留設定產生非確定結果。

自託管的長期環境確實能減少重複安裝與下載，但也更容易累積狀態。若測試只有在某台節點成功，換到乾淨 Runner 就失敗，這不是效率提升，而是可重現性下降。

驗證提醒：快取鍵至少要包含作業系統、Xcode 版本、Swift 工具鏈與依賴鎖定檔雜湊。否則你可能把舊環境誤判成「構建更快」。

如果團隊需要固定版本的 Xcode，節點控制權會比單純分鐘價格更重要。Apple 的系統要求頁顯示，Xcode 版本與可支援的 macOS 版本存在明確對應；你可用Apple Xcode 系統要求核對目前版本與 macOS 的兼容邊界。

你應逐項判斷以下條件：

• 是否需要同時保留兩個或以上 Xcode 版本。
• 是否要在固定鑰匙串中使用簽名憑證與 provisioning profile。
• 是否依賴私有 Swift Package、內部 API 或公司 VPN。
• 是否需要長期保留大型編譯快取。
• 是否有硬體、設備識別或特殊防火牆規則。

GitHub-hosted Runner 並非一概無法存取私有網路。官方文件提到，託管 Runner 可依工作流需要連線到額外網路，但其 IP 位址範圍不適合作為內部資源的固定 allowlist；需要固定網路政策時，可能要使用具靜態 IP 的較大型 Runner，或改用自託管節點。具體能力應按你的網路架構逐項核實，不能直接把「託管」等同於「無法進入內網」。

簽名材料則要反向評估。託管環境的短生命週期有助於降低長期金鑰駐留；自託管遠端 Mac 則便於維持固定鑰匙串，但一旦節點被不受信任的工作流污染，影響可能持續存在。自託管 Runner 不等同於每次工作都有乾淨的虛擬機，相關風險可參考GitHub Actions 安全使用文件。

自託管 Runner 必須在主機上運行 Runner 應用程式，並持續與 GitHub Actions 通訊。官方要求包含可連線到 GitHub、具備足夠硬體資源，以及至少 70 Kbit/s 的上下行網路能力；工作流開始時還要能連出 HTTPS 443。Self-hosted runners reference列出了這些要求。

但「Online」只表示 Runner 可被找到，不代表它已經通過生產驗收。你至少要測試：

• macOS 重啟後，Runner 是否能自動恢復並重新接收工作。
• 網路中斷後，工作是否能明確失敗、重試或轉移，而不是長時間卡住。
• Xcode 構建中斷後，簽名狀態、快取與工作目錄是否會留下污染。
• 磁碟空間不足時，是否有告警、清理與節點隔離機制。

GitHub 文件指出，若沒有符合標籤的 Online 且閒置 Runner，工作會留在佇列；若超過 24 小時仍未執行，工作會失敗。Self-hosted runners reference中的這項規則，應納入你的故障演練，而不是只看平日成功率。

不要一次把所有工作流遷移到自託管。選一組有代表性的工作：

• 一條 lint 或單元測試工作。
• 一條不含簽名的 Xcode 構建。
• 一條需要簽名與 archive 的發布工作。
• 一條需要私有套件或內網 API 的工作。

接著在相同提交上分別執行，記錄五個結果：帳單成本、排隊時間、執行時間、失敗率、人工維護分鐘。對自託管遠端 Mac，還要記錄節點租用週期內的閒置時間與恢復事件。

可使用以下決策條件：

• 若工作低頻、倉庫公開，或團隊沒有值班人員，則選託管 Runner。
• 若工作需要固定 Xcode、長期快取或私有網路，則把該工作放到自託管遠端 Mac。
• 若主要成本來自並發排隊，則先增加可用節點或改用合適的託管配置，不要只延長單台節點租期。
• 若自託管節點的維護工時已高於節省的帳單，則回退到託管 Runner。
• 若通用測試與簽名工作具有不同安全要求，則維持雙軌，而不是強行統一環境。

你可以先查看 CALMVPS 的 Mac 方案與租用週期，再以一個完整租用週期試跑簽名或 archive 流水線；不要先用未驗證的理想利用率估算節省金額。若需要直接安排節點，也可從 CALMVPS 的遠端 Mac 方案頁核對可用選項。

GitHub-hosted Runner 的優點是按工作供給資源、環境重置較清楚，適合低頻任務與通用測試；缺點是每次環境準備、快取限制、固定網路政策與特定 Xcode 控制可能增加不確定性。

自託管遠端 Mac 的優點是 Xcode、快取、鑰匙串、內網與工作目錄都更容易固定；缺點是節點會產生閒置成本，並需要處理更新、監控、重啟、權限隔離與故障恢復。若你的現行方案是只靠託管 Runner，它可能在高頻 Xcode CI 上累積分鐘費用與排隊時間；若現行方案是自建實體 Mac，則會面對硬體前期支出、設備故障、位置網路與維護人力。

因此，CALMVPS 的遠端 Mac 更適合拿來驗證一條高價值、環境敏感的簽名或歸檔流水線，而不是讓你盲目遷移全部工作。先用一個租用週期比較真實成本、排隊時間與恢復紀錄；若結果證明控制權確實抵銷了租用與維護成本，再逐步增加自託管比例。

FAQ 已按獨立問題整理，重點是把成本、構建量、隱性支出與混用方式放回你的實際工作流，而不是給出一個脫離團隊規模的固定答案。

若你要進一步規劃節點數量，可先整理每個倉庫的並發工作數、平均構建時長與高峰時段，再決定是一台長期在線的 Mac，還是託管 Runner 加自託管遠端 Mac 的雙軌架構。