GitHub Actions macOS-14 退役前，企業 CI 預算怎麼算？2026
GitHub 已確認 macOS-14 Runner 鏡像將於指定日期退役，但 Runner 分鐘單價不足以決定替代方案。本文依企業 IT、CI、FinOps 與資安責任拆解工作負載、預算變數和承載方式，協助你用真實帳單與運維資料制定試點及擴容條件。
目錄
退役時程已明確，本週先盤點工作負載，不要只比分鐘單價
截至 2026 年 10 月 27 日，GitHub 已公告 macOS 14 Runner 鏡像預定於 2026 年 11 月 2 日退役，受影響標籤包括 macos-14、macos-14-large 與 macos-14-xlarge；官方亦提醒，退役前可能出現容量減少及排隊時間延長。GitHub 退役公告
這代表 GitHub Actions macOS-14 退役企業 CI 預算，不能單靠 Runner 分鐘單價推算。本週先按工作流程記錄拆分必須在 macOS 執行的工作，再以實際計費時長、組織配額、運維投入與交付資料比較承載方式；多數團隊應先分流或採用混合承載，只有數據證明適配時才擴大自建或租用。
企業 IT 或平台負責人：需要在退役前確認替代承載方式與預算邊界。
FinOps 或採購負責人：需要把托管分鐘、設備持有、運維與擴縮容放進同一模型。
CI/CD 負責人：需要判斷哪些 iOS/macOS 工作流必須使用 Mac，哪些可留在其他環境。
最後更新於 2026 年 10 月 27 日；退役時程、標籤與計費規則核對自 GitHub 官方公告、Actions 計費文件及 Runner 定價文件。下文只使用官方公告已確認的時程資訊；實際計費仍須依你的方案與帳單核實。
CI 負責人先把工作流分成「必須用 Mac」與「可分流」
預算盤點的單位應是工作流任務，而不是整個專案或 Runner 標籤。先從流水線記錄提取執行環境、觸發次數、執行時長、排隊情況與發布重要性；沒有記錄的任務比例不要自行推估。GitHub 的 Runner 選擇文件可用來核對工作要分配到哪一類 Runner。
| 工作流任務 | 可能的承載判斷 | 預算盤點時要記錄 |
|---|---|---|
| Xcode 編譯、iOS/macOS 專案建置 | 通常需要 macOS 與 Apple 工具鏈 | 工作流次數、實際執行時長、建置結果 |
| iOS 模擬器測試 | 需按測試所依賴的模擬器及工具鏈核實 | 執行環境、測試時長、失敗及重跑記錄 |
| 程式碼簽署與發布 | 按憑證使用、發布權限及隔離要求決定承載 | 簽署任務、憑證存取範圍、發布關鍵性 |
| 靜態檢查、文件處理、通用腳本 | 若不依賴 Apple 工具鏈，可評估分流 | 執行環境需求、相依套件、分流後驗收結果 |
因此，GitHub Actions macOS Runner 的退役影響不等於所有 iOS 流程都要搬到另一台 Mac。若某個工作只做通用檔案處理或語言層級檢查，先驗證它能否移至團隊已使用的其他環境；若建置、模擬器或簽署確實依賴 macOS，才把它納入 Mac 承載成本。
哪些 iOS CI 工作必須用 Mac Runner，哪些可以分流？
判斷依據不是任務名稱，而是工具鏈、作業系統相依性及驗收結果。把不依賴 Apple 工具鏈的步驟分流前，須確認產物、環境變數和相依套件可在目標環境重現；編譯、模擬器測試或簽署任務則逐項核實實際執行環境。不能只看標籤就推斷任務已隔離，也不能把未記錄的執行時長當成零成本。
FinOps 用真實帳單建立可複算模型
預算模型要能由另一位負責人按同一份帳單及流水線資料重算。先分開記錄工作流執行次數與實際計費時長，再核對所屬方案的配額、適用 Runner 計費規則及額外儲存等費用。計費口徑可能受 Runner 類型、方案及組織設定影響，請以官方計費說明和Runner 定價文件對照帳戶中的實際帳單，不要把文件中的某一種費率直接套用到所有工作流。
一個可供團隊複核的模型可以寫成：
- 月度托管成本估算＝各工作流的執行次數 × 實際計費時長 × 適用計費規則，再依帳單核對配額、超額或其他費用。
- 月度自建或租用成本估算＝設備或租用支出＋空閒資源成本＋運維工時估值＋儲存及網路等相關支出＋安全控制成本。
- 年度預算估算＝以組織實際採用的月度計算方式，代入各月用量與支出；不要假設每月負載相同。
| 預算變數 | 資料來源 | 怎樣放入模型 |
|---|---|---|
| 工作流次數與計費時長 | 流水線執行記錄、組織帳單 | 按工作流類型拆開，保留失敗與重跑記錄 |
| 配額與適用計費規則 | 組織方案、GitHub 計費文件、帳單 | 核對實際 Runner 類型、計費方式及超額情況 |
| 設備持有或租用支出 | 採購資料或供應商當前公開條款 | 與空閒時間及預計使用期一併評估 |
| 運維與故障恢復 | 團隊工時記錄、值班及事故記錄 | 由團隊估值，不把維護工時當成免費 |
| 儲存、網路及安全控制 | 組織帳單與內部安全要求 | 分開列項，避免只比較 Runner 執行費 |
Mac CI 預算要不要計入空閒時間和運維工時？
要。自建 Mac 即使沒有執行工作流，也可能佔用已購設備與團隊維護能力；遠端 Mac 方案則要按實際租賃週期、資源安排及合約條件核算。故障重啟、系統更新、Xcode 環境維護、憑證管理與使用者權限處理，都可能產生團隊工時。請以內部紀錄估算，沒有工時資料時應標為待驗證，不應虛構固定成本。
企業 IT 與採購把直接支出和責任成本分開比較
以下是方向性評估，不是通用價格評分。適配度標記只表示常見責任分布：◎代表在該維度通常較有彈性，○代表要看配置，△代表需要團隊承擔較多責任。你應以本組織的帳單、採購報價、運維工時和安全條件替換判斷。
| 承載方式 | 彈性與空閒資源 | 維護、故障恢復責任 | 適配度評分及主要核實項目 |
|---|---|---|---|
| 托管 macOS Runner | ◎ 按實際工作流使用；排隊與可用性按官方文件及實際記錄核實 | ○ 需關注平台供應與工作流設定 | 適合希望少承擔主機維護的任務；確認計費、配額與排隊是否符合發布需求 |
| 自建 Mac Runner | ○ 可自行安排並行與使用方式，但閒置設備仍有持有成本 | △ 團隊需管理主機、更新、監控、復原及權限 | 適合能自行維運且有穩定需求的團隊；核算設備、維護與故障處理投入 |
| 遠端 Mac 租用 | ○ 可按可取得的租期及配置評估，實際條件須查核 | ○ 主機責任與環境管理須依服務條款確認 | 適合需要真實 Mac、但不希望先購置設備的試點或彈性容量；核對交付、存取、安全與退租條款 |
自托管 Mac Runner 並非「買好設備便不再付費」：GitHub 的自托管 Runner 文件說明了相關 Runner 的管理責任；若考慮 GitHub 提供的大型 Runner，則應另外核對其大型 Runner 文件與帳單口徑。比較時，把可直接計量的費用與需要團隊估算的工時分列，不能將硬體購置價直接當成完整 TCO。
資安負責人先確認硬性條件，再決定可比較的方案
方案比較前，先列出會直接排除某種承載方式的要求。私有網路存取、簽名憑證保管、主機管理權限、工作間隔離及產物留存方式，都需要對照團隊政策逐項驗收。Runner 標籤只能協助選擇執行環境，不代表工作流之間已完成安全隔離；遠端連線方式也不能單獨證明憑證管理或主機存取符合要求。
若安全要求必須由團隊直接控制主機與網路，自建方案可能較容易配合，但責任和維護投入也由團隊承擔；若採遠端 Mac，採購前應確認實際存取方式、交付條件與服務條款。你可參考 VPSMAC 的服務條款核對需確認的項目，並把尚未核實的控制措施列為試點驗收條件，不要將其視為已具備。
採購按證據決定分流、試點或擴容
以下條件分支可直接用於預算審查。任何缺少流水線記錄、內部工時或可核實價格的項目，都先列為待補資料，而不是填入推測值。
- 若任務不依賴 Apple 工具鏈，且分流後通過產物與流程驗收，就先留在可用的非 Mac 環境；否則保留於 Mac 任務池。
- 若托管 Runner 的實際帳單、配額及排隊記錄符合發布要求，就保留適合的托管工作流；否則評估瓶頸屬於計費、容量還是工作流並行方式，再比較其他承載。
- 若團隊能承擔主機維護、監控與故障復原，且記錄顯示需求足以支撐自有設備使用，才把自建 Mac 納入擴容評估；否則避免僅憑採購價格判定較省。
- 若遠端 Mac 的配置、交付、存取方式及服務條款均能滿足試點要求，就先以限定工作流驗收；若關鍵條款或安全條件未確認，暫不把租用方案計入已核准容量。
- 若各類工作流的峰值、發布重要性及成本表現不同，就採混合承載，將可分流任務、一般建置和敏感簽署任務分別安排；若試點未達內部定義的成功條件，停止擴大並回到原有可行承載。
實施時，先匯出組織帳單與工作流執行記錄；接著按工具鏈需求分類任務，標出執行時間、重跑和發布關鍵性；再用當前官方文件核對 Runner 配額與計費方式；之後分別填入自建設備、租用週期、運維工時及安全控制的真實資料；最後選擇少量有代表性的工作流試點，記錄成本、排隊、失敗復原與安全驗收結果，再由 IT、CI、FinOps 及資安共同決定是否擴容。試點復核週期和停止條件應由你的發布節奏與風險政策設定，不需要套用未經驗證的固定天數或用量門檻。
遠端 Mac 情境不可預填本站價格、配置或可用性。開始試算前，請以 VPSMAC 的公開服務資訊及當前價格頁核對實際可用配置、週／月／季租賃週期、定價、交付與存取方式，再把可確認的項目填入模型；未能確認的項目應留白並向供應方核實，而非當成已提供的能力。
若你目前完全依賴托管 Runner，主要風險是費用及容量受適用規則和可用性影響；若改成全自建，則要承擔閒置設備、日常維護和故障復原；若選遠端 Mac，仍須先驗證交付、存取及安全條款是否符合內部要求。對需要真實 Mac、但尚未證明長期固定負載足以支持自購的團隊，可先用有限工作流比較租用情境與現行方案；若需求長期穩定且重負載，或必須直接接觸特定實體介面，自購或自建仍可能更合適。
當你的預算模型已填入真實用量與內部工時，再核對 VPSMAC 目前公開的配置、租期與價格，確認適合的遠端 Mac CI 試點範圍；不要在服務條款與交付方式未核實前，先假設租用一定比托管或自建便宜。