截至 2026-08-21，Runner Scale Set Client 仍屬 GitHub 官方標示的 Public Preview，可用來協助建立支援 macOS 的自訂 Runner 自動擴容方案，但不會替你採購、啟動、初始化或銷毀 Mac 主機。官方儲存庫的狀態與職責說明決定了最重要的部署結論：
症狀：發布佇列持續增加，但長期在線的共享 Runner 仍無法及時接單。
最快解法：不要單純堆疊常駐 Mac；採用「基礎溫池＋按佇列擴容」雙層架構，並以 JIT 或 ephemeral runner、任務後清理及外部日誌作為生產基線。
這篇文章適合三類讀者：負責處理 iOS 建置排隊、發布高峰與 Mac 節點利用率的研發效能負責人；制定 Runner 權限、憑證隔離與審計策略的企業 IT 及安全負責人；以及正在比較固定採購、雲端 Mac 租賃或混合容量的技術總監與基礎設施採購負責人。
最後更新於 2026-08-21；Runner 功能狀態、JIT 註冊、安全要求與監控方式核實自 GitHub self-hosted runner 文件、Runner Scale Set Client 官方儲存庫及 GitHub API 文件。
上線前的擴容邊界
先定義三層資源
在配置任何自動化之前，先把 Mac 資源分成三種職責：
- 基礎溫池：保留少量已完成初始化的節點，處理短時間內的建置需求，避免每次都等待主機交付。
- 彈性節點：當佇列、峰值任務或發布 SLA 超出溫池承載能力時才建立，任務完成後回收。
- 固定簽名節點：只處理確實需要穩定 Keychain、硬體介面或固定發布流程的工作，不應與一般 Pull Request 建置混用。
Runner Scale Set Client 是控制面元件，不是 Mac 主機供應工具。它不能取代你的資源調度器，也不能保證遠端節點已經完成 macOS、Xcode、SDK、依賴套件和網路設定。Apple 的 Xcode 系統要求應成為映像檔或基線檢查的一部分。
用負載而不是人數決定容量
你應收集以下訊號，再決定溫池下限與擴容門檻：
- 佇列等待時間是否在發布窗口前持續上升；
- 建置任務是短時間單元測試，還是需要大量編譯與封裝的完整工作；
- Mac 主機從請求到可接單的交付時間；
- Xcode、SDK、依賴快取和簽名流程是否需要不同環境；
- 任務失敗後重新排程，是否會超出發布 SLA。
沒有真實佇列和交付記錄時，不要宣稱某個固定數量就是最佳溫池。先保留可調參數，例如最小節點數、最大節點數、佇列觸發閾值和縮容冷卻時間，第一週再用實際資料校準。
首次接入的信任邊界
組織級路由
第一個小時不要急著把所有工作流導入新節點。先建立 runner group，限制哪些組織、儲存庫或工作流可以看見該資源池；GitHub 對 Runner Group 存取控制有明確的管理方式。
接著依照下列條件設計標籤：
- Xcode 或 SDK 基線；
- Apple Silicon 與其他芯片架構；
- 一般測試、受信任建置與發布任務；
- 是否允許接觸簽名憑證或生產密鑰。
工作流中的路由只保留最小必要條件，例如：
runs-on: [self-hosted, macOS, Apple-Silicon, xcode-release]標籤不是安全邊界。真正的隔離仍要靠 Runner group、儲存庫權限、節點生命週期及憑證政策共同完成。公開儲存庫，或能執行不可信 Pull Request 的工作流，不應進入持有生產憑證的 Mac 節點。GitHub 自託管 Runner 安全指南也要求你把不受信任程式碼視為高風險輸入。
註冊責任與密鑰輪換
註冊流程應使用權限受限的 GitHub App 或符合官方要求的存取權杖，並明確記錄：
- 誰負責建立與撤銷註冊權限；
- 誰可以修改 runner group 和標籤；
- 何時輪換權杖，以及失效後如何阻止新節點註冊；
- 如何保存註冊、撤銷、輪換和節點回收的審計紀錄。
不要把長期有效的管理權杖寫進 Mac 映像檔、Git 儲存庫或工作區。對一次性節點，註冊資訊應只存在於該次生命週期中。
首日的佇列控制面
六個狀態的生命週期
把擴容鏈路明確建模為以下六個狀態，能避免「節點已建立但 Runner 永遠離線」這類半完成狀態：
- 需求出現：佇列事件或
workflow_jobWebhook 表示需要額外容量。 - 請求節點：調度器向企業既有自動化或遠端 Mac 資源介面提出請求。
- 主機就緒：完成開機、網路、macOS、Xcode、依賴套件與監控初始化。
- 註冊 Runner：取得 JIT 設定，將節點加入正確的 scale set、group 和標籤。
- 領取任務：確認工作流實際路由到預期芯片和 Xcode 基線。
- 退出清理：刪除工作區、清除暫存憑證、撤銷 Runner 並回收主機。
Runner Scale Set Client 適合處理控制面協作；GitHub Actions Runner REST API則可用於查詢與管理 Runner 狀態。JIT 註冊資訊應在節點啟動時取得，不要預先寫死在通用映像檔中。
最小化的註冊與路由骨架
以下只展示理解流程所需的最小骨架，不代表完整的生產部署：
name: macos-build
on:
workflow_dispatch:
jobs:
build:
runs-on: [self-hosted, macOS, Apple-Silicon]
steps:
- uses: actions/checkout@v4
- name: Build
run: xcodebuild -scheme App -configuration Release實際使用時，你還要在調度器中處理重複事件、主機啟動失敗、註冊逾時和任務已取消等情況。每一個事件都要有唯一識別碼或冪等鍵，否則同一個佇列事件可能建立多台無人使用的 Mac。
首條流水線的隔離驗證
先測試一次性 Runner
第一條驗證流水線應使用受控測試儲存庫，不要直接連接生產簽名流程。你需要逐項確認：
- [ ] 工作流只會路由到預期的 runner group 和標籤。
- [ ] 節點以 JIT 或 ephemeral runner 註冊，任務完成後自動退出。
- [ ] 工作區、DerivedData、暫存檔和依賴快取的保留政策已分開定義。
- [ ] Keychain、簽名憑證與令牌不會進入可重用快取。
- [ ] 節點註冊、任務執行和註銷事件均送到外部儲存。
- [ ] 主機生命週期日誌在節點銷毀後仍可查詢。
- [ ] Runner 離線、註冊失敗和任務取消時都有回收路徑。
可重用快取應只包含經過完整性驗證、且不含秘密的依賴資料。簽名憑證、Keychain 狀態和臨時存取權限則應隨任務銷毀。若你需要先整理企業級憑證邊界，可參考 KVMFLUX 的隱私與資料處理說明，再把內部政策映射到節點生命週期。
首週的容量校準與故障回收
用記錄調整溫池
第一週不要以「Runner 在線」作為成功標準，而要把以下記錄放在同一條時間線上：
- 佇列事件發生時間；
- 主機請求與主機就緒時間；
- Runner 註冊成功與首次接單時間；
- 任務開始、結束及清理完成時間；
- 任務取消、節點失聯和重試時間。
這些資料能區分真正的容量不足與主機交付過慢。若佇列很短但交付時間很長，增加溫池可能比一味提高最大擴容數更有效；若溫池長期閒置，則應降低下限或縮短固定持有週期。
故障演練清單
- [ ] 暫停控制面，確認既有任務有明確逾時與重試策略。
- [ ] 讓 Mac 節點在建置中失聯，確認工作流不會永久佔用佇列。
- [ ] 模擬 Runner 更新失敗，確認節點不會以未驗證版本接單。
- [ ] 故意造成標籤錯配，確認不會把發布任務送到一般測試池。
- [ ] 在任務結束後檢查工作區、Keychain 和暫存令牌是否清除。
- [ ] 驗證主機回收失敗時的告警、人工介入與再次交付流程。
- [ ] 將外部日誌與 GitHub Runner 狀態交叉比對，保留完整排障證據。
GitHub 的 Runner 監控與故障排查文件可作為狀態檢查基礎，但企業仍須補上 Mac 主機、網路和資源調度器的記錄。
生產准入與分階段放量
生產驗收至少要同時檢查路由、單任務隔離、憑證邊界、日誌完整性、失敗回收和容量上限。只看到 Runner 顯示在線，不能證明擴容鏈路已可承受發布高峰。
建議按以下順序放量：
- 先放行不含簽名的測試與單元測試；
- 再放行可信來源的 iOS 建置與封裝；
- 最後才評估生產發布是否需要獨立的固定簽名節點。
若固定溫池能穩定承擔日常建置，而高峰才造成佇列，保留雙層架構；若 Mac 交付時間始終影響 SLA，則擴大彈性遠端 Mac 容量；若簽名政策或實體介面要求不可移動，則保留固定節點，避免為了自動擴容而破壞信任邊界。
完成驗收後，你可以把節點數量、交付時限與租賃週期整理成採購清單，再查看 KVMFLUX 的 Mac 使用情境與方案週期資訊，判斷雲端 Mac 租賃是否適合承擔彈性池，而不是預先承諾固定節省比例。
常見部署疑問
FAQ 已放在元資料中，以下只保留生產准入前的判斷重點：Runner Scale Set Client 應被視為控制面，而不是 Mac 供應平台；ephemeral runner 適合高風險、一次性任務；溫池容量必須由佇列與交付記錄校準。任何 Public Preview 功能都應在正式放量前重新核對官方狀態，不能把未公布的 GA 日期或未確認的介面穩定性當成採購承諾。
目前若你依賴長期在線的共享 Mac，常見缺點是工作區和憑證殘留難以證明已清除、單一節點故障會拖慢整批發布，以及閒置容量仍持續產生硬體、維護與電力成本。直接採購固定 Mac 也會把峰值需求轉化為長期折舊和管理工作。當你已完成溫池與峰值容量計算，KVMFLUX 的遠端 Mac 租賃可作為彈性節點候選，讓你按實際週期補充建置容量；但固定重負載、需要實體介面或必須長期持有專用簽名環境的任務，仍應保留自有固定節點，採用混合架構會更穩妥。