GitHub Actions 對單一 job 設有 6 小時執行上限，這是平台限制，不代表一般建置會跑滿這段時間；但它提醒你，Runner 選型要先看工作流程和限制，再看誰負責管理。GitHub Actions 使用限制文件列明這項規則。本週建議：先記錄每次 iOS 建置的頻率、是否需要自訂環境，以及失敗後由誰處理；低頻、環境標準就先用託管 Runner，需要長期複用工具鏈或控制執行環境，再評估自託管 Mac Runner。自託管不等於一定要買一台 Mac 放在辦公室，也可以部署於遠端 Mac；但系統維護責任仍要算進方案。
這篇適合偶爾執行 iOS 建置、希望少處理 Runner 維運的獨立開發者；也適合已使用 GitHub Actions，卻需要固定 macOS 工具鏈或更可控環境的開發者。
若你正把個人建置流程擴展成長期自動發布流程，以下指標可用來評估是否拆分工作流程，而非一次全數切換。
先按建置負載分流
託管 Runner 由平台提供並管理執行環境；自託管 Runner 則由你管理承載 Runner 的機器與環境。GitHub 的Runner 選擇說明及託管 Runner 參考文件列出可選環境與選擇方式。實際可用的 macOS Runner、標籤和平台限制可能調整，工作流程上線前要核對當前文件，不要沿用舊設定假設。
偶爾建置、可以接受任務依平台供應情況執行，適合先選託管 Runner。你少了管理主機的工作，較適合標準建置流程、個人專案或仍在驗證發布管線的團隊。
建置反覆執行、依賴自訂工具鏈，或需要管理機器上的執行環境，才評估自託管 Runner。這不是效能保證，也不代表任務必定更快。你需要一併承擔 macOS、Xcode、相依套件和 Runner 程式的維護工作。
比較建置頻率時，也要看並行需求和可接受的排隊情況。記錄一段時間內的工作流程觸發狀況、同時執行的 job 數量，以及排隊是否真的阻礙發布；不要用「偶爾感覺很慢」直接推論要自建。平台的並行額度和限制須以官方使用限制說明為準，不應套用其他方案或舊文件中的數字。
個人 iOS 專案適合自託管 Mac Runner 嗎？如果你只是間歇性打包，而且沒有特殊環境需求，託管 Runner 通常更省維運；若你已經有可管理的遠端 Mac、工作流程需持續複用特定設定，而且願意負責更新和復原，再評估自託管。不要只因為專案是個人開發，就預設某一種方案最便宜；比較時應把維護時間和服務使用成本一併納入。
再核對環境控制與工具鏈
Xcode 版本、相依套件和自訂建置設定，會直接影響工作流程能否重現。先列出建置實際需要的 macOS、Xcode、依賴項目和額外工具，再核對託管 Runner 現有映像及標籤。GitHub 的託管 Runner 參考表會說明平台提供的環境資訊；版本或映像可能變更，因此不要把某個標籤當成永久固定的工具鏈。
若每次 job 都能從 repository 中的設定重建環境，託管 Runner 往往較容易維持一致。若工作流程依賴長期保留的自訂設定，或你需要明確管理機器上的 macOS 與軟體環境，自託管可能更合適。這種控制力也會帶來責任：更新後要重新驗證建置，否則機器上的狀態可能與程式碼設定分歧。
建議把工作流程分成可重建的建置步驟和必須自訂的環境步驟，並核對 job 如何指定 Runner 標籤。工作流程語法文件說明 workflow 與 job 的設定方式。實際設定要按你採用的標籤驗證，避免只更換 Runner 類型，卻讓 job 被派送到不符合需求的環境。
把維護投入與持續可用性算進去
託管 Runner 的優點是平台管理 Runner 基礎設施；這不代表你的 workflow、依賴和發布流程都會自動維護。自託管則把更多操作責任放到你這邊。GitHub 的自託管 Runner 文件說明其管理責任；官方的監控與疑難排解指引也可用來規劃日常檢查。
GitHub Actions 自託管 Runner 需要自己維護哪些內容？至少要有負責人處理主機可用性、macOS 與工具更新、Runner 軟體狀態、磁碟空間和工作目錄清理，也要安排任務失敗後的檢查與復原。若主機離線或環境更新造成建置失敗，平台不會代替你處理自有機器上的維修與環境差異。
把成本拆開估算，比猜一個通用價格更可靠：託管方案要查你實際使用方式對應的平台用量或額度；自託管方案則加入 Mac 的取得或租用成本、管理時間、備援安排，以及更新和清理所需的人力。若建置需求低且標準，管理主機所花的時間可能抵銷自託管的價值。若建置反覆發生、環境需要持續維護，則應比較完整的週期成本，而不是只看單次建置。
逐項設好憑證與任務邊界
iOS 簽名憑證和工作流程密鑰不是選 Runner 時的附帶細節。你要檢查 workflow 能讀取哪些密鑰、Runner 能存取哪些 repository 和網路資源，以及 job 結束後會留下哪些檔案。不要讓不需要發布權限的建置工作也能讀取簽名資料。
自託管 Runner 尤其需要評估任務隔離與清理方式。不同工作流程能否共用機器、任務結束後憑證或暫存檔是否保留，都要依你的配置逐項驗證；不能只因為 Runner 位於自己管理的 Mac，就假設安全邊界已足夠。GitHub 的安全使用 pull_request_target 指引提醒你留意工作流程觸發方式與權限風險；自託管 Runner 群組存取建議則說明如何管理 Runner 群組的存取。
請把發布簽名 job 與一般測試 job 分開評估。先確認觸發來源、密鑰權限、Runner 可存取的資料，再決定它們是否應共用同一個執行環境。
若你要核對憑證和資料處理邊界，可參考MangoVM 的資料保護說明；但仍須依你實際使用的密鑰管理方式和 Runner 配置做風險評估。
用條件清單決定是否遷移
按以下條件選擇，不符合自託管條件時先回到託管 Runner：
- 若建置不頻繁、環境符合平台提供的映像，而且你不想負責管理主機，選託管 Runner。
- 若工具鏈可由 repository 設定重建，但希望控制某些 job 的執行環境，先測試拆分 workflow 或指定 Runner 標籤，不必全量遷移。
- 若需要固定複用自訂 macOS 環境，且有人能處理更新、清理、離線與復原，再評估自託管 Runner。
- 若簽名或發布工作需要更清楚的權限界線，先重新設計密鑰和 job 存取，再決定 Runner；單純換成自託管並不會自動解決安全問題。
建議按可回退的方式遷移。先整理現有 workflow，記下建置所需工具鏈、觸發方式、密鑰和產出檔案。接著挑一個不包含發布憑證的測試 job，讓它在新 Runner 上執行並核對結果。再檢查 job 標籤、工作目錄清理和失敗後的處理責任。只有在測試流程穩定、存取權限符合預期後，才安排簽名與發布 job 遷移。最後保留原流程作為回退路徑，按工作負載逐步調整，而不是一次切換所有建置。
什麼時候應把 GitHub Actions 建置遷移到遠端 Mac？當你確定託管環境無法滿足所需的工具鏈或環境控制，而且團隊能承擔自託管維護時，再考慮遷移。遠端 Mac 是自託管 Runner 的部署選項之一，不是免維護保證。遷移前要確認遠端環境符合你的 macOS、工具鏈、存取權限和持續連線需求。
如果目前使用託管 Runner，你可能會遇到環境自訂受限、建置流程需要重新準備環境，以及用量或並行限制需要納入規劃等問題；實際情況須按 GitHub 當前文件和你的使用方案核對。遠端 Mac 讓你可以評估由自己控制的建置環境，但也會增加系統更新、磁碟整理和 Runner 維護責任。若你只是短期測試 iOS 打包流程，或想先驗證自託管方式，租用 Mac 可避免為一次性需求購買實機；若需求是長期穩定的高負載建置，或必須使用本機實體介面，則應比較自購設備與其他合適方案，不必勉強採用租用。
選擇遠端環境前，先核對工作流程需要的 macOS 和工具鏈，以及你能否持續連線與管理 Runner。若這些條件符合，再查看 MangoVM 的 Mac 環境選項，確認是否適合用作測試或自託管建置環境；不要在未核實配置前預設它符合你的工作流程。
為自託管 Runner 配置專屬遠端 Mac
MangoVM 提供獨享實體 Mac 節點，讓建置環境、工具鏈與快取可持續保留，減少每次重建環境的工作。