你的 iOS 建置在 PR 合併前就要跑，但常駐 Mac 上又留著簽名憑據？

最快判斷：只跑受信任的私有倉庫工作、存取範圍受控且能核驗工作目錄狀態，可用受控常駐 Mac；外部程式碼或高權限憑據應移到隔離、一次性執行的環境。清空工作目錄不等於隔離，租用遠端 Mac 也不會自動替 Runner 建立隔離。

獨立開發者：你用 GitHub Actions 建置 iOS App，正在衡量維護成本與環境重用。
小型團隊：你要分開日常建置與簽名發布，並限制不同工作流程能接觸的權限。
發布自動化維護者：你需要評估常駐 Runner 上的憑據與任務殘留風險。

01

GitHub Actions macOS Runner 常駐還是臨時機：先按信任程度分流

常駐和臨時不是單純的主機選擇，而是程式碼來源、憑據權限及任務結束後狀態的組合判斷。GitHub 文件指出，一個自託管 Runner 同一時間只執行一個工作；這不代表下一個工作會接手一台乾淨的 Mac。自託管 Runner 參考文件

執行情境 常駐 Mac 隔離或一次性環境 決策重點
只建置受信任私有倉庫的主分支 可行，前提是限制 Runner 存取並檢查任務後狀態 可用，但可能增加環境重建與診斷責任 Runner 持續在線，不表示工作目錄必須保留
同倉庫可信分支 PR 可按分支與工作流程權限設定 適合需要縮小殘留風險的團隊 審查觸發條件、Runner 組與 Job 可用憑據
外部貢獻者或不受信任程式碼 不建議與敏感任務共用主機 優先選擇隔離執行；無法隔離時不要送上該主機 清理目錄不能消除程式碼對主機狀態的影響
簽名、發布或上傳 僅限發布專用流程及嚴格受控主機 把高權限任務放入單獨、受控的執行環境 證書私鑰、Keychain 與 API 憑據不可供一般 Job 使用

主分支持續建置適合沿用常駐 Runner 嗎？

如果工作流程只執行你信任的私有倉庫程式碼，且能限制哪些倉庫及工作流程使用這台 Mac，常駐 Runner 可以減少重複準備環境的維護負擔。但這個選擇只適用於權限邊界明確的情境，不應推廣到所有 PR。

要分清兩種「持續」：Runner 服務常駐在線，與工作區、暫存檔、Keychain 狀態持續留存。前者方便派送工作，後者可能讓後續任務接觸前一個工作的殘留。每次檢查時，對照倉庫與 Runner 組的存取設定、工作目錄狀態及 Runner 記錄；不要只看工作流程顯示完成。

GitHub 的安全文件提醒，自託管 Runner 可能受工作流程執行的程式碼影響。常駐主機因而需要限定可執行的程式碼來源，不能把 Runner 標籤當作信任審核。GitHub Actions 自託管 Runner 安全指引

GitHub Actions 自託管 Runner 可以重複接收工作嗎？

可以重複執行不同 Job，但重用的是 Runner 主機，不代表每個 Job 都在全新環境中執行。官方文件說明，自託管 Runner 一次只處理一個工作；完成後若 Runner 繼續在線，仍須確認工作區、暫存資料、工具設定與憑據如何處理。

這裡的實際風險不是「兩個 Job 同時搶同一個工作目錄」，而是前一個 Job 是否留下可被後續程式碼讀取或影響的狀態。清理工作區有助降低意外殘留，但不能當成主機隔離或可信程式碼的替代品。

02

同一倉庫的 PR：把觸發來源和權限一起審查

同一個倉庫也可能有不同信任等級的分支。保護分支的程式碼、已審查的內部分支，與尚未審查的變更，不應只因為它們屬於同一倉庫就視為等同。

先查看工作流程由哪些事件觸發，再檢查 Runner 組和標籤的可存取範圍，以及 Job 能讀取的 Token 權限與 Secrets。GitHub 的事件文件說明，不同事件會以不同上下文觸發工作流程；需要逐項對照實際設定，而不是假設「PR 工作流程」只有一種權限行為。工作流程觸發事件參考

使用 Runner 組可以限制哪些倉庫能使用一組 Runner，但這只設定存取邊界，不會讓同一台 Mac 上的任務彼此隔離。請核對組別允許的倉庫、Runner 標籤與工作流程條件；若不同信任等級仍會落到同一台主機，須進一步拆分執行環境。Runner 組存取管理文件與Runner 組的存取邊界說明

03

外部貢獻者的程式碼不要進入含敏感狀態的主機

外部 Pull Request 怎樣避免進入自託管 Mac？

先確認 PR 事件與實際工作流程如何取得程式碼，再判斷該工作是否會派送到自託管 Runner。外部貢獻者提交的內容尚未經你信任；讓它在持有其他任務殘留狀態的主機上執行，可能使主機環境或可讀取的憑據暴露於風險。

特別留意 pull_request_target。該事件可在基礎分支的上下文執行，若再以具權限的上下文檢出並執行不受信任的 PR 程式碼，就可能造成嚴重安全問題。不要只因為工作流程檔案放在受保護的分支，就認定執行的程式碼可信；對照官方安全說明檢查事件、程式碼檢出方式及憑據使用。安全使用 pull_request_target 的官方說明

較穩妥的界線是：不受信任的貢獻程式碼使用隔離執行環境；若你沒有可驗證的隔離方式，就不要將它派送到持有敏感狀態的自託管主機。工作流程的 permissions 應明確收窄 Token 權限，並逐項確認哪些 Job 必須使用 Secrets。工作流程權限語法

注意：Job 結束後刪除工作目錄，不能證明程式碼未改動主機設定、工具或其他仍可存取的狀態。隔離要靠執行環境邊界，而不是靠清理命令的名稱。

04

簽名發布和一般建置應分開授權

日常建置通常不需要存取發行憑據。若把證書私鑰、API 憑據或解鎖後的 Keychain 放在一般 Runner 可用的環境，任何可在該環境執行的工作流程都可能擴大憑據暴露面。

把工作流程拆成一般建置與簽名發布兩段。一般建置不提供簽名所需的 Secrets；只有經授權的發布工作流程才取得必要憑據，並將觸發來源與目標分支納入審查。對常駐 Mac，另確認哪些倉庫能使用 Runner、哪些工作流程可進入發布 Job，以及憑據何時匯入、何時移除。

驗收證據應包括脫敏後的工作流程設定、Runner 組授權紀錄，以及發布 Job 的憑據範圍。不要把憑據值、私鑰或 Token 寫進 Runner 日誌；也不要以「建置成功」推論權限隔離已經完成。

05

依序核對工作流程、主機狀態與故障紀錄

第一步：標記每個工作流程的程式碼來源

列出主分支、內部 PR、外部 PR，以及手動或發布觸發的工作流程。逐項確認會檢出哪份程式碼、由什麼事件觸發，以及哪些變更需要審查。沒有清楚分類前，不要把所有 Job 都指向同一組 Runner。

第二步：檢查 Runner 的可存取範圍

在 GitHub 設定中檢視 Runner 組允許的倉庫與使用條件。再與工作流程內指定的組別和標籤互相比對。設定看似限制了標籤，但若倉庫授權過寬，仍可能讓非預期工作流程使用該主機。

第三步：逐個 Job 核對 Token 和 Secrets

檢查工作流程及 Job 層級的 permissions，確認 Token 只取得必要能力。列出每個 Job 實際可用的 Secrets；一般測試或 PR 驗證若不需要簽名與發布憑據，就不要讓它們共用發布工作流程的授權。

第四步：定義任務後清理內容

完成 Job 後，檢查工作目錄、暫存檔、建置產物、快取及與簽名有關的暫存狀態。清除不再需要的資料，並確認清理結果有記錄。這是降低殘留風險的維護措施，不是隔離證明。

第五步：建立失敗復原與移除流程

常駐 Runner 要有明確的停用、主機重設、重新註冊與憑據輪替程序。臨時 Runner 也要安排診斷資料的保存方式：一次性執行不會自動替你保留足夠的故障證據。GitHub 提供 Runner 監控與排障指引，以及移除 Runner 的流程；按你的部署方式確認記錄保留和退役步驟。監控與排障說明、移除自託管 Runner 的說明

第六步：用代表性工作驗收邊界

在不暴露正式憑據的前提下，執行一個代表性建置，檢查 Runner 是否按預期接收工作、工作結束後哪些檔案或狀態仍存在，以及日誌是否足以追蹤失敗。若驗收涉及發布，再以最小必要權限檢查簽名工作流程，並保存脫敏設定與授權紀錄。單次建置成功只證明該次工作完成，不證明主機已隔離，也不保證其他工作流程安全。

06

讓臨時執行可追蹤，讓常駐主機可復原

GitHub 建議在自動擴展等情境採用臨時 Runner；官方文件也說明，臨時 Runner 處理完一個工作後會自動取消註冊。但 Runner 自動取消註冊，不等於主機已重設，也不等於診斷資料會自動保留。自託管 Runner 的臨時部署說明

因此，選臨時環境時要另行確認主機如何回收、如何重建，以及哪些脫敏日誌、工作結果和清理紀錄會留存。選常駐環境時，則要確認任務後處理、Runner 重新註冊和主機重設由誰負責。兩種方式都需要可追溯的故障資料，只是維護責任不同。

遠端 Mac 可提供你執行 macOS 建置的主機，但不會自動替 GitHub Actions 配置 Runner 隔離、清除 Secrets 或執行主機重設。若你正評估遠端環境，先查看VpsMesh 的遠端 Mac 環境與連線方式，再依工作流程確認實際可用配置、交付方式和憑據管理邊界。

如果你目前靠一台常駐 Mac 同時跑 PR、簽名和發布，主要風險是不同信任等級共用環境、憑據暴露面不清楚，以及主機故障後要自行復原。相較之下，按需使用遠端 Mac 可以讓你取得獨立的 macOS 建置環境，適合臨時驗收或分開發布工作；但租用本身不等於一次性 Runner 或安全隔離。若你需要穩定、長期的重負載建置，或必須直接接觸實體介面，先評估自購主機；若要臨時建立建置環境，可從VpsMesh 的 Mac 方案資訊開始核對，再自行確認 Runner 部署、工作後處理與憑據權限。