建置高峰時，GitHub Actions 可以發出擴容訊號，卻不會替你建立、初始化或擦除真實 Mac。
最快解法：先保留固定或預熱 Mac 池，再以 GitHub Actions Runner Scale Set Client 試點可重建的 PR 建置任務；生產簽名不要一開始就全量遷移。
最後更新於 2026 年 9 月 20 日；預覽狀態、平台支援、認證與生命週期說明已核實自 GitHub Changelog 公開預覽說明、官方 actions/scaleset 儲存庫 及相關 GitHub 文件。
這篇適合管理多倉庫 GitHub Actions Mac Runner、正在處理發佈高峰排隊的平台團隊。
如果你負責一次性 Runner 隔離、跨專案殘留風險，或正在比較固定採購、遠端 Mac 彈性容量與混合節點池的 TCO，以下指標可直接用於評審與 PoC。
SECTION 01責任邊界與選型結論
截至上述核實日期，GitHub 將 Runner Scale Set Client 標示為 Public Preview，並確認它可配合包括 macOS 在內的自訂基礎設施；但企業仍須自行負責 Mac 主機供應、初始化、清理與銷毀。這不是把真實 Mac 當成容器瞬間建立，而是把 GitHub 的工作需求訊號接到你的供應流程。
| 選項 | 適合的任務 | 你必須具備的能力 | 首輪否決條件 |
|---|---|---|---|
| 固定 Mac 池 | 低延遲建置、正式簽名、需要穩定快取的工作 | 長期維護、容量規劃、節點監控 | 峰值排隊已造成發佈延誤，且無法增加節點 |
| Scale Set 彈性池 | 可重建的 PR 驗證、非正式分支測試、短期峰值 | 自動交付、初始化、回收、清理與日誌外送 | 無法在工作結束後確認環境已擦除 |
| 混合節點池 | PR 彈性擴容，加上固定的可信簽名節點 | 任務分類、權限邊界、故障回退 | 所有工作都必須使用生產憑證，沒有隔離分層 |
因此，判斷重點不是「Client 能否擴容」，而是你能否在擴容訊號出現後，可靠地交付一台合規的 Mac，並在工作結束後證明它已被回收。
SECTION 02彈性容量的指標：排隊變短，是否真的代表值得導入？
Scale Set Client 對接 Scale Set API，處理的是工作需求與 Runner 供應之間的控制面。官方擴縮容說明涉及已分配工作、執行中工作、等待工作與可供應 Runner；你不能把每一則事件訊息直接當成一台 Mac 的建立指令。應以企業自己的佇列紀錄、任務抵達分佈與節點可用紀錄驗證收益。官方擴縮容說明 可作為欄位與行為核對基準。
| 觀察指標 | 應記錄的資料 | 對選型的意義 |
|---|---|---|
| 等待工作 | 進入佇列時間、開始執行時間 | 判斷固定池是否在尖峰不足 |
| 執行中工作 | 工作類型、平均佔用時間、失敗原因 | 避免用短 PR 任務的數量推估長時間歸檔需求 |
| 已分配工作 | 已指派但尚未接單的工作 | 分辨 Runner 供應慢與工作本身執行慢 |
| 可供應 Mac | 可用、初始化中、失聯、銷毀中的節點 | 判斷供應流程是否真正跟得上控制面 |
| 空閒容量 | 預熱節點的閒置時間與快取命中情況 | 比較按需建立與保留預熱容量的成本 |
按需建立適合尖峰短、工作可重建的情況；若 Xcode 初始化、依賴下載或模擬器準備佔去大部分等待時間，完全冷啟動可能只把排隊時間改名為交付時間。預熱少量節點通常更容易控制延遲，但會承擔閒置與維護成本。
你可以把任務分成三類：PR 驗證進入彈性池；模擬器回歸依實際啟動成本決定預熱或彈性；歸檔發布與生產簽名先留在固定、可信的 Mac 節點。這種分工也比把所有 self-hosted Mac Runner 放進同一個標籤更容易稽核。
提醒： Scale Set API、Scale Set Client、Runner 進程與 macOS 主機是不同生命週期。Client 恢復運作，不代表失聯的 Mac 已完成清理，也不代表原工作已安全重新分配。
SECTION 03JIT 隔離能否保護工作區與簽名憑證？
JIT Runner 可以縮短 Runner 註冊生命週期，但「一次性 Runner 自動註銷」不等於「乾淨的 Mac 主機」。同一台主機若被重複使用，工作區、DerivedData、套件快取、Shell 歷史、Keychain 項目與臨時憑證仍可能殘留。GitHub 的 自託管 Runner 安全使用說明 也要求你把不受信任的程式碼與敏感環境分開考慮。
| 生命週期 | 需要驗收的問題 | 不合格時的處置 |
|---|---|---|
| Runner 註冊 | 工作完成後是否自動註銷，失聯時是否可撤銷 | 撤銷註冊與相關存取權 |
| macOS 主機 | 是否重建、重設或確認磁碟與系統狀態 | 不得重新接收敏感工作 |
| 工作區 | 原始碼、建置輸出與快取是否清除 | 銷毀主機或執行可驗證的清理流程 |
| Keychain | 憑證、私鑰與臨時密碼是否只存在於可信節點 | 立即撤銷或輪替憑證 |
| 日誌 | Runner 診斷資料是否在銷毀前外送 | 從外部儲存區補足稽核證據 |
JIT Runner 能協助限制 Runner 的可用時間，但不能單獨隔離 Xcode 工作區和簽名憑證。生產簽名任務預設不應與非可信分支共用彈性執行環境；你還要透過 Runner group 和工作流程權限限制哪些 Repository 可以派送工作，具體權限可參考 Runner group 存取控制文件。
Kubernetes 是必要條件嗎？
不是。GitHub 提供與 Runner Scale Set 相關的元件與 API，但自訂 Mac 供應器可以由企業自己的主機編排、佈署腳本或外部控制面負責。Kubernetes 只有在你已有成熟的控制面、事件處理、祕密管理與節點生命週期能力時才可能合理；它不會自動解決真實 Mac 的開機、登入、Xcode 初始化或清除問題。對小型平台團隊而言，增加一層編排反而可能擴大故障範圍。官方 Runner Controller 文件 應被視為整合參考，而不是 Mac 彈性池的必要條件。
SECTION 04啟動與故障恢復：冷啟動的收益會不會被交付流程吃掉？
把啟動延遲拆成以下階段，再用企業記錄填值，而不是預先承諾某個固定秒數：
- Mac 主機可用，且供應系統已確認狀態。
- macOS 完成必要解鎖與網路連線。
- Runner 完成註冊並取得工作。
- Xcode、套件與必要工具完成初始化。
- 第一個 Job 真正開始執行。
第一步：先為每個階段加上時間戳，並將冷啟動、預熱節點、固定節點分開統計。
第二步：以 PR 驗證這類可重建任務做試點，記錄等待、失敗重試與任務總耗時。
第三步：讓診斷日誌在節點銷毀前轉存到外部儲存，不要只留在即將被回收的 Mac 上。
第四步：測試 Client 崩潰、供應失敗、Mac 失聯、註冊成功但接不到工作等異常路徑。
第五步：為每種異常定義回退順序：固定 Mac 池、備用遠端 Mac，最後才是讓工作繼續等待。
第六步：用 自託管 Runner 監控與故障排查文件 對照監控欄位，確認「Client 程式重啟」不會被誤判成「CI 已恢復」。
經驗： 真正的驗收條件不是臨時 Runner 重新上線，而是故障後工作能否回到固定池或備用遠端 Mac，且你仍能取得失敗工作、節點狀態與清理結果的證據。
認證也要獨立檢查。GitHub App、存取權杖、Runner group 與工作流程觸發權限應遵循最小權限原則；官方認證說明 與 自託管 Runner REST API 文件 可用於核對目前介面和撤銷路徑。介面仍屬預覽階段，正式上線前要再次檢查官方儲存庫與文件，不能把範例當成長期相容承諾。
SECTION 05TCO 與混合節點池的成本判斷
建立企業 Mac 基礎設施 TCO 分析時，不要只比較「固定主機價格」和「按需 Mac 服務」的單價。你需要把供應自動化、維護人力、預熱閒置、故障損失、憑證管理、日誌保存與尖峰排隊造成的延誤全部列入模型。
| 成本或風險項目 | 固定 Mac 池 | 彈性 Scale Set 池 | 混合節點池 |
|---|---|---|---|
| 主機容量 | 按預估峰值長期保留 | 按需求建立，但受供應流程限制 | 固定基礎容量加上尖峰彈性 |
| 維護工作 | 持續更新與監控 | 供應、初始化、清理與銷毀自動化 | 兩套流程並存，需清楚分工 |
| 閒置成本 | 峰值以外仍可能閒置 | 較低，但會增加冷啟動風險 | 用預熱容量換取可控延遲 |
| 安全邊界 | 容易建立專用簽名節點 | 每次重建與清理都必須可驗證 | 敏感任務固定，非敏感任務彈性 |
| 故障回退 | 路徑較直接 | 需預備固定池或備用 Mac | 可依任務類型切換 |
| 適合任務 | 發布、簽名、低延遲建置 | PR、短期回歸、非可信分支 | 多數企業的漸進方案 |
用變數計算即可避免無來源的節省比例：固定容量成本為主機、維護與閒置；彈性容量成本為按需使用、供應自動化、清理與故障損失；混合方案則加上固定基礎池與彈性峰值容量。只有當企業佇列紀錄證明峰值排隊成本高於彈性供應與驗證成本時，Scale Set 才值得擴大。
如果你需要先確認不同租期與遠端 Mac 交付選項，可參考 MACNOX 的方案與價格頁面，但不要以頁面單價取代完整 TCO；初始化、回收、監控、故障切換與工程人力仍應納入你的內部模型。若要用真實 Mac 驗證初始化、回收與故障切換，也可以把一類可重建 PR 工作交給 MACNOX 的遠端 Mac 方案 做有限度測試，先確認交付方式、節點清理證據與回退路徑，再談長期容量。這不能取代你對生產簽名邊界的設計。
SECTION 06最終決策：什麼條件下應繼續、試點或否決？
| 驗收結果 | 建議決策 | 允許接入的工作 |
|---|---|---|
| 有自動交付、任務後清理、外部日誌與固定池回退 | 建設混合節點池 | PR、可重建測試、非生產分支回歸 |
| 能供應 Mac，但冷啟動資料不足或清理不可證明 | 啟動有限試點 | 低敏感、可重跑的驗證工作 |
| 沒有主機生命週期自動化，或所有任務都需要生產簽名 | 維持固定池 | 正式歸檔、簽名與低延遲工作 |
| Client 失聯後無法撤銷權限、轉存日誌或重新分配工作 | 否決彈性方案 | 先修復控制面與故障流程 |
GitHub Actions Runner Scale Set Client 值得試點，但不值得在尚未證明主機交付、清理、日誌與故障回退前，直接替換現有固定 Mac 池。對大多數企業，最穩妥的路徑是：先用可重建的 PR 建置驗證彈性收益，再把固定 Mac 留給生產簽名與低延遲任務。
若你目前以自購 Mac mini 建立固定池，硬體採購會帶來容量預估錯誤、閒置資源與維護責任；若改用沒有清晰生命週期控制的雲端 Mac，則可能遇到環境殘留、啟動延遲和故障時缺乏實體節點證據。對需要短期擴容或測試交付流程的團隊，按需租用 MACNOX 的真實 Mac 會更適合作為受控試點；但長期穩定重負載、必須掌握實體介面或要求專用簽名邊界時，自建或固定專用節點仍可能更合理。