GitHub Actions macOS Runner 怎麼選？2026 託管與自建成本

建置分鐘數突然上升、合併請求卡在佇列，團隊卻只看到 Runner 的單次執行費用。

最快的判斷方式是：低頻、波動大而且不需要固定環境，優先使用 GitHub-hosted runner；利用率穩定、建置時間長，或必須鎖定 Xcode 與內部依賴，則選 self-hosted runner。需求仍未穩定時，先租用獨立 Mac Runner 量測真實負載，再決定是否購買設備。

最後更新於 2026 年 8 月 21 日；計費、映像檔、標籤與 Runner 要求已核對自 GitHub Actions 官方 Runner 計費表、官方 Runner Images 清單 及相關自托管文件。

這篇適合以下讀者：

• GitHub Actions macOS 建置分鐘數增長較快的 iOS 團隊；
• 需要固定 Xcode、憑證或內部依賴環境的持續整合負責人；
• 正在比較購買實體 Mac 與租用雲端 Mac 節點的技術管理者。

先拆開 GitHub Actions macOS Runner 的成本

GitHub Actions macOS Runner 怎樣計算成本，不能只把「每分鐘價格」乘以工作流程次數。完整估算至少要分成執行、排隊、維護、閒置與故障恢復五個資料欄位。

第一步是從近期工作流程匯出下列資料：

• 每月工作流程執行次數；
• 每次任務的實際執行時間；
• 依賴下載、編譯、測試與封裝各自所占時間；
• 高峰時同時等待的工作數；
• 失敗後重試、人工介入與重新部署所花的時間。

GitHub-hosted runner 的費用，應直接依照官方計費表與團隊目前的方案、作業系統及 Runner 類型核算，不能把某篇舊文章的單價當作 2026 年固定價格。官方文件同時列出標準託管 Runner 與較大 Runner 的計費規則，實際金額仍須以帳戶所在方案的最新頁面為準。GitHub Actions 官方計費規則

自建方案則應建立「設備或租用費、維護工時、閒置資源、故障備援」四個成本池。購買 Mac 不是一次付款後就沒有成本；macOS 更新、Xcode 安裝、硬碟清理、憑證輪換與主機故障，都會轉化為團隊的時間成本。若設備長時間沒有任務，閒置成本也必須保留在試算中。

把排隊與建置時間分開量度

GitHub Actions macOS 任務排隊怎麼解決？

先區分「沒有可用 Runner」與「工作流程本身太慢」兩種問題。前者通常與並發需求、Runner 數量、標籤匹配或高峰流量有關；後者則可能是依賴下載、編譯、測試或封裝步驟耗時。只增加 Runner，未必能改善單一工作流程的回饋時間。

建議依照以下步驟建立可比較的基線：

1. 在每個主要工作流程記錄開始等待、取得 Runner、完成建置及產出封裝檔的時間。
2. 將依賴安裝、Xcode 編譯、單元測試、UI 測試與歸檔拆成獨立工作。
3. 檢查工作流程是否因不同架構或不同 Xcode 版本而被迫重新下載依賴。
4. 使用官方依賴快取機制，並設計能隨 lockfile、作業系統與工具鏈變更的快取鍵；GitHub 依賴快取文件 說明了快取的適用方式與限制。
5. 在高峰時段再次量度佇列時間，將「節省的等待時間」與增加 Runner 的費用放在同一張表內。

如果任務在白天集中湧入，GitHub-hosted runner 的彈性通常比固定設備更容易處理峰值；如果建置在全天穩定執行，並且每個任務都需要相同的快取與工具鏈，self-hosted runner 才有機會透過高利用率攤薄設備成本。

提醒： 快取不是永久不變的資產。Xcode、Swift 套件、Pod 或系統映像檔更新後，舊快取可能造成難以重現的建置結果，因此自建主機必須把快取失效與定期清理納入維護流程。

固定工具鏈與環境控制

GitHub 託管 Runner 適合標準化程度高、每次任務完成後不需要保留主機狀態的團隊。官方 Runner Images 清單可用來核對作業系統、Xcode 版本與可用標籤；截至本文更新日，清單已列出 xcode-27 公開預覽標籤，但預覽狀態及可用映像檔仍應以官方頁面為準。官方 Runner Images 清單

對需要 Apple silicon 的建置工作，不能只看標籤名稱，還要確認工作流程、第三方套件與測試工具是否支援 Arm64。官方的 Xcode 27 macOS Arm64 映像檔說明 可作為核對架構、工具版本與預裝內容的依據。

自托管環境的優點是可以固定 Xcode、憑證、私有套件來源、內部網路與專用快取；代價是每個變更都由團隊負責。至少要完成以下操作：

1. 建立專用 macOS 使用者，不要使用日常管理員帳戶執行工作流程。
2. 只安裝工作流程真正需要的 Xcode、套件管理器與建置工具。
3. 將簽署憑證、App Store Connect 金鑰及環境變數分開管理，避免直接寫入儲存庫。
4. 設定主機磁碟、快取、DerivedData 與暫存目錄的清理規則。
5. 在 Xcode 或 macOS 更新前，以獨立分支驗證建置、測試與簽署流程。
6. 為 Runner 應用程式、作業系統、憑證及內部依賴建立負責人與更新紀錄。

iOS CI 何時適合使用自托管 Runner？

當工作流程需要固定 Xcode 版本、連入內部服務、保留大型快取，或每天都有穩定且較長的建置任務時，自托管 Mac Runner 較值得評估。相反地，若只是偶爾發佈版本、工作量有明顯峰谷，或團隊沒有能處理 macOS 維護的人員，託管 Runner 通常更穩妥。

先處理憑證、工作目錄與權限風險

臨時託管環境的優勢是工作完成後不必長期保留主機狀態；持續重用的自建主機則可能殘留工作目錄、套件、登入資訊或簽署相關檔案。公開儲存庫尤其需要謹慎，因為不可信的工作流程若能在自托管主機執行，便可能接觸該主機上的其他資料。

GitHub 官方建議不要把自托管 Runner 不加區分地提供給公開儲存庫，並要求管理者審慎處理工作流程來源與主機權限。自托管 Runner 的安全存取建議

可採用以下隔離原則：

• 公開儲存庫、內部儲存庫與高敏感簽署工作分開使用 Runner；
• 用 Runner groups 限定哪些儲存庫可以使用特定主機，而不是讓所有儲存庫共用；
• 將建置、測試、簽署拆成不同權限範圍；
• 不讓一般建置主機同時存放長期有效的生產金鑰；
• 對工作目錄、SSH 金鑰、快取與系統日誌設定清理及存取規則。

Runner groups 的官方權限說明 可用來核對組織、儲存庫與 Runner 之間的授權關係。若團隊希望先整理權限與工作流程，也可參考 nuvcloud 的 控制中心操作說明 和 支援文件。

用條件分支選擇方案

先完成資料收集，再依照以下條件作決定，不要因為單次帳單較低便直接購買設備：

• 若任務次數低、峰谷差異大，且不需要固定 Xcode 或內部網路，選 GitHub-hosted runner； 否則回到下一項。
• 若佇列主要出現在短時間高峰，選可彈性增加的託管 Runner； 若佇列全天存在，則檢查是否需要增加自建節點或拆分工作流程。
• 若建置時間長、每天使用穩定，並且快取能持續被重用，評估 self-hosted runner； 否則回到託管方案。
• 若必須控制憑證、私有套件來源或固定 Xcode，選隔離的自托管 Mac； 若團隊沒有維護負責人，改用託管或專業租用節點。
• 若利用率尚未有可靠紀錄，先租用按週期交付的獨立 Mac Runner； 取得真實執行、排隊及閒置資料後，再決定購買設備。
• 若工作流程包含公開儲存庫的非可信程式碼，避免直接使用持續重用的自托管主機； 改用臨時環境或更嚴格隔離的 Runner group。

租用 Mac Runner 和購買設備怎麼選，關鍵不是誰的標價較低，而是團隊是否需要把硬體折舊、故障、更新與閒置風險自行承擔。短期專案、Xcode 版本遷移或利用率未知時，租用更適合作為驗證階段；長期穩定重負載且已有維護能力時，購買設備才有機會形成合理的總成本。

三種方案的成本對照

評估項目	GitHub-hosted runner	自建 Mac Runner	租用獨立 Mac Runner
付款方式	依官方計費規則與使用量核算	設備、電力、維護與閒置成本	依租用週期與方案條件核算
高峰併發	較容易按需求調整	受設備數量限制	取決於可交付節點數量
Xcode 控制	受官方映像檔與標籤限制	可自行固定與驗證	取決於交付配置與管理方式
私有網路依賴	需確認連線方案	可直接整合內部網路	需事前確認連線與權限
維護責任	主要由平台處理	團隊自行承擔	由租用服務與團隊分工
適合情境	低頻、波動、標準化工作	穩定高利用率、強控制需求	短期驗證、遷移與未知負載

建立可審計的成本試算

將資料填入下表時，執行費用應取自 GitHub 最新帳單或租用合約；自建欄位則填入設備折舊、維護工時與備援成本。不要用估計值掩蓋尚未量度的排隊時間。

成本欄位	要記錄的資料	判讀方式
執行	工作流程次數、Runner 執行時間、重試次數	對照官方計費或租用合約
排隊	任務進入佇列至取得 Runner 的時間	判斷是否需要併發或額外節點
建置	依賴、編譯、測試、歸檔各階段時間	找出快取與工具鏈瓶頸
環境	Xcode、Apple silicon、私有套件與憑證需求	判斷託管標籤是否足夠
維護	更新、清理、監控、憑證輪換工時	加入自建方案的總成本
閒置	沒有任務時的設備或租用週期	避免低估固定資源成本
故障恢復	備用節點、重建主機與人工處理時間	判斷低價方案是否值得承擔

落地時可依序執行：先匯出近期工作流程資料，再按階段標記時間；接著核對 Xcode 與架構標籤，然後將託管帳單、自建成本類別及租用條件分開填寫；最後以高峰與平日兩種負載重算，並由負責人檢查安全隔離及故障恢復方案。若需先確認可用的 Mac 節點與交付方式，可從 nuvcloud 的 雲端 Mac 建置節點資訊 開始核對，不應把網站方案資料誤當成 GitHub 官方計費。

對多數正在擴大 iOS CI 的團隊，GitHub-hosted runner 的缺點是長時間建置或高峰併發時帳單較難預測，標準映像檔也未必完全符合固定 Xcode 與內部依賴要求；自建 Mac 的缺點則是需要承擔硬體閒置、macOS 更新、憑證管理、磁碟清理和故障備援。若目前方案是單一共用主機，還會額外面對工作目錄殘留與權限隔離不足的問題。

因此，當團隊還沒有足夠利用率資料，直接購買 Mac 往往會把未知風險變成長期固定成本。先租用 nuvcloud 的 Mac Runner，按實際週期觀察建置時間、排隊、快取命中與維護介入次數，再決定回到 GitHub 託管、持續租用或採購設備，通常比憑感覺作出長期承諾更容易驗證。若團隊只需要臨時算力、版本遷移或測試環境，這種方式尤其適合；若是全年穩定重負載，或必須直接連接特定實體介面，則仍應如實評估自購 Mac 的必要性。