2026年 GitHub Actions 用雲端 Mac 跑 iOS 自托管 Runner：比官方托管省多少錢？5步配置避坑清單

2026年 GitHub Actions 用雲端 Mac 跑 iOS 自托管 Runner：比官方托管省多少錢？5步配置避坑清單

2026年 GitHub Actions 用雲端 Mac 跑 iOS 自托管 Runner：比官方托管省多少錢？5步配置避坑清單

導語摘要

正在評估 iOS CI/CD 成本的 DevOps 工程師或技術負責人請注意：2026年 GitHub 官方 macOS Runner 的每分鐘費率雖已於1月調降，但標準型（3–4核 M1/Intel）仍達 $0.062/分鐘，月均75小時構建量即產生約 $279 美元的純計算費用，若加上 Xcode 快取儲存與更大機型，帳單輕易突破 $350。本文給出官方托管 vs 雲端 Mac 自托管 Runner 的真實 TCO 對比表、損益平衡點計算公式，以及 Mac mini M4 節點的 5步完整注冊流程（含可複製指令），同時涵蓋 Xcode 版本標籤路由、代碼簽名安全配置，以及三類高頻故障的排查命令——幫助 iOS 團隊在30分鐘內完成迁移決策。

一、GitHub 官方 macOS Runner 費用究竟有多高？2026年帳單拆解

GitHub 在 2025年12月16日宣佈，自 2026年1月1日起調降托管 Runner 費率最多39%，但這並非免費午餐——與此同時，自 2026年3月1日起，自托管 Runner 也新增了每分鐘 $0.002 的「Actions 雲端平台費」。對 iOS 團隊而言，真正的核心成本仍在 macOS Runner 本身的高單價。

2026年現行費率對照

Runner 類型 SKU 每分鐘費率（USD） 備註
macOS 3–4 核（M1/Intel） actions_macos $0.062 標準型，最常見
macOS 12 核（大型） macos_l $0.077 需 GitHub Team 以上方案
Linux 2 核（x64） actions_linux $0.006 對比參照
自托管 Runner 平台費（2026/3起） — $0.002 計入方案免費額度

注意：以上為 2026年1月1日生效的新費率，已含 $0.002/分鐘的雲端平台費。自托管 Runner 的 $0.002 平台費則自3月1日另行計算。

月度費用試算（以75小時構建量為例）

設定情境：中型 iOS App，日均觸發 CI 約15次，每次構建約6分鐘（含 Xcode 編譯 + 單元測試 + Archive）。

月構建分鐘數 = 15 次/天 × 30 天 × 6 分鐘 = 2,700 分鐘（45 小時）
月構建分鐘數 = 25 次/天 × 30 天 × 6 分鐘 = 4,500 分鐘（75 小時）
月構建量 官方 macOS Runner（$0.062/min） 雲端 Mac mini M4 固定月租 + 平台費
45 小時（2,700 分鐘） $167.4 ~$109 + $5.4 = ~$114
75 小時（4,500 分鐘） $279.0 ~$109 + $9.0 = ~$118
120 小時（7,200 分鐘） $446.4 ~$109 + $14.4 = ~$123

雲端 Mac mini M4 固定月租參考價：香港/新加坡節點約 $99–$110/月（16 GB / 256 GB 方案）；自托管平台費按 $0.002/分鐘計算，且通常可被方案免費額度抵消。

損益平衡點公式

損益平衡月構建分鐘數 = 雲端 Mac 月租 ÷ (官方費率 - 自托管平台費率)
= $109 ÷ ($0.062 - $0.002)
= $109 ÷ $0.060
≈ 1,817 分鐘（約 30.3 小時）

結論：月構建量超過 30 小時，雲端 Mac 自托管方案即開始省錢；超過75小時，月省金額已達 $160+ 美元，折合年省約 $1,920。

二、自托管 Runner 的核心收益：持久快取、區域節點與並發控制

除了直接的費用節省，雲端 Mac 自托管 Runner 還帶來三項官方托管做不到的能力。

痛點拆解：官方托管的隱性限制

  1. DerivedData 每次清零：官方托管 Runner 使用全新的短暫虛擬機（ephemeral VM），每次 job 結束即銷毀。Xcode 的 DerivedData 無法跨 job 保留，中型 App（約100萬行 Swift）的冷啟動完整編譯通常需要 8–12 分鐘；而持久化 Runner 的增量構建可壓縮至 2–4 分鐘，節省計費時間高達50%以上。
  2. 並發上限與排隊風險：GitHub Free/Pro 方案的 macOS 並發上限通常為1–2個，衝刺週或多 PR 同時跑測試時，後續 job 需排隊等候，拖累 Review 週期。自托管節點池可自由設定並發上限，或透過 runner group 橫向擴充節點。
  3. App Store Connect 上傳延遲：官方 Runner 的伺服器位於美國，從亞洲團隊角度看，Archive 後上傳至 App Store Connect 的頻寬往往受到跨洋線路限制。選用香港（HK）或新加坡（SG）節點的雲端 Mac，與 Apple 亞太區伺服器距離更近，上傳時延可縮短約 30–60%。
  4. Xcode 版本固化成本：官方托管 Runner 的 Xcode 版本跟隨 GitHub 映像更新節奏，有時在你尚未準備好時即強制升級，需額外管理 runs-on: macos-14 等版本標籤。自托管節點上你完全掌控已安裝的 Xcode 版本，可同時維護多版本供不同項目路由使用。
  5. 快取儲存費用：官方托管方案的 Actions Cache 每個 repo 上限10 GB，超過後自動清除最舊快取；若同時有多個 branch 的快取共存（DerivedData 典型大小6–14 GB），快取命中率會明顯下降。自托管 Runner 的磁碟快取無此限制，256 GB SSD 足夠容納多個 App 的完整 DerivedData。

三、決策矩陣：官方托管 vs 自托管 vs 混合策略

評估維度 官方托管 Runner 雲端 Mac 自托管 Runner 混合策略
月構建量 < 30 小時 > 30 小時 主流程自托管、偶發任務用官方
DerivedData 快取 ❌ 每次清零 ✅ 磁碟持久化 視 job 類型分配
並發彈性 ❌ 受方案上限限制 ✅ 節點池自定義 高峰期 burst 用官方
Xcode 版本控制 跟隨 GitHub 映像 ✅ 完全自主 —
代碼簽名隔離 ✅ Ephemeral VM 天然隔離 需自行清理 Keychain 生產簽名放自托管
運維負擔 ✅ 零運維 需監控服務狀態 中等
安全合規（ephemeral） ✅ 符合 ephemeral 要求 需額外配置 合規 job 走官方
區域節點（HK/SG） ❌ 不可選 ✅ 可選 —
月費（75小時構建） ~$279 ~$118 視比例而定

推薦決策： - 繼續用官方托管：月構建量 < 30 小時、團隊無任何運維資源、合規要求強制 ephemeral 環境。 - 迁移自托管：月構建量 > 30 小時且持續增長、需要 DerivedData 持久快取、有亞太上傳需求。 - 混合策略：生產簽名 + Archive 放自托管節點，PR 驗證 / 單元測試等短任務繼續用官方（可消耗免費額度）。

四、5步完成雲端 Mac 節點注冊（含 YAML 示例）

以下步驟基於 Mac mini M4（arm64，macOS Sequoia / macOS 26）節點，假設已透過 SSH 獲得訪問憑據。

步驟一：SSH 登入並建立專用 CI 使用者

# 以預設管理員帳號 SSH 入節點
ssh admin@<your-node-ip>

# 建立非管理員 CI 專用使用者（避免 Runner 以 root 權限運行）
sudo dscl . -create /Users/ci-runner
sudo dscl . -create /Users/ci-runner UserShell /bin/zsh
sudo dscl . -create /Users/ci-runner RealName "CI Runner"
sudo dscl . -create /Users/ci-runner UniqueID 505
sudo dscl . -create /Users/ci-runner PrimaryGroupID 20
sudo dscl . -create /Users/ci-runner NFSHomeDirectory /Users/ci-runner
sudo dscl . -passwd /Users/ci-runner <strong-password>
sudo createhomedir -c -u ci-runner

# 確認使用者已建立
id ci-runner

檢查點：id ci-runner 應顯示 UID=505，且 /Users/ci-runner 目錄存在。

步驟二：切換至 CI 使用者並下載 arm64 Runner 套件

# 切換至 CI 使用者
sudo -u ci-runner -i

# 建立 Runner 工作目錄
mkdir ~/actions-runner && cd ~/actions-runner

# 下載最新版 arm64 macOS Runner（請至 GitHub Settings > Actions > Runners 取得最新版本號）
curl -o actions-runner-osx-arm64.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.323.0/actions-runner-osx-arm64-2.323.0.tar.gz

# 驗證雜湊值（從 GitHub Runner 頁面取得對應 SHA-256）
shasum -a 256 actions-runner-osx-arm64.tar.gz

# 解壓縮
tar xzf ./actions-runner-osx-arm64.tar.gz

檢查點：ls ~/actions-runner 應看到 config.sh、run.sh、svc.sh 等檔案。

步驟三：執行 config.sh 注冊 Runner 並設定自定義標籤

前往你的 GitHub 儲存庫 Settings → Actions → Runners → New self-hosted runner，選擇 macOS + ARM64，複製頁面上自動產生的 Token。

# 在 ci-runner 使用者下執行
./config.sh \
  --url https://github.com/<YOUR_ORG>/<YOUR_REPO> \
  --token <REGISTRATION_TOKEN_FROM_GITHUB> \
  --name "mac-mini-m4-hk-01" \
  --labels "self-hosted,macOS,ARM64,M4,xcode-26,region-hk" \
  --work "_work" \
  --unattended

標籤策略說明：xcode-26 標示已安裝 Xcode 26（macOS 26 對應版本），region-hk 標示香港節點。不同項目可透過 runs-on 精確路由至指定節點，避免版本衝突（詳見第五節）。

檢查點：命令執行後應顯示「Runner successfully added」，並在 GitHub Settings 頁面看到新 Runner 狀態為 Idle。

步驟四：安裝 launchd 持久服務

# 仍在 ci-runner 使用者下執行
cd ~/actions-runner
./svc.sh install

# 啟動服務
./svc.sh start

# 確認服務狀態
./svc.sh status

重要：svc.sh install 會將 Runner 安裝為 LaunchAgent（非 LaunchDaemon），確保它在使用者登入階段運行，這對 Keychain 訪問權限至關重要（詳見第六節代碼簽名章節）。

檢查點：./svc.sh status 顯示 active (running)，GitHub Settings 頁面 Runner 狀態保持 Idle。

步驟五：驗證第一個 iOS 構建工作流

在你的儲存庫中建立 .github/workflows/ios-build.yml：

name: iOS Build (Self-Hosted M4)

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: [self-hosted, macOS, ARM64, M4, xcode-26, region-hk]
    timeout-minutes: 30

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Cache DerivedData
        uses: actions/cache@v4
        with:
          path: ~/Library/Developer/Xcode/DerivedData
          key: ${{ runner.os }}-deriveddata-${{ hashFiles('**/*.xcodeproj/project.pbxproj') }}
          restore-keys: |
            ${{ runner.os }}-deriveddata-

      - name: Cache SPM Packages
        uses: actions/cache@v4
        with:
          path: |
            .build
            ~/Library/Developer/Xcode/DerivedData/ModuleCache.noindex
            ~/Library/Caches/org.swift.swiftpm
          key: ${{ runner.os }}-spm-${{ hashFiles('**/Package.resolved') }}

      - name: Build and Test
        run: |
          xcodebuild clean build test \
            -scheme "YourApp" \
            -destination "platform=iOS Simulator,name=iPhone 16 Pro,OS=18.4" \
            -derivedDataPath ~/Library/Developer/Xcode/DerivedData \
            CODE_SIGNING_ALLOWED=NO \
            | xcpretty

      - name: Archive (main branch only)
        if: github.ref == 'refs/heads/main'
        run: |
          xcodebuild archive \
            -scheme "YourApp" \
            -archivePath $RUNNER_TEMP/YourApp.xcarchive \
            -derivedDataPath ~/Library/Developer/Xcode/DerivedData

檢查點：Push 一個 commit，確認 GitHub Actions 頁面顯示 job 被路由至你的自托管節點（Runner 名稱顯示為 mac-mini-m4-hk-01）。

五、Xcode 版本標籤與 runs-on 路由策略

當團隊有多個 iOS / macOS 項目共用同一節點池時，標籤路由是避免版本衝突的核心機制。

標籤命名規範建議

標籤 用途 示例值
xcode-26 標示節點上的主 Xcode 版本 xcode-26、xcode-16-4
region-hk / region-sg 標示節點地理位置 region-hk（香港）、region-sg（新加坡）
mem-24g 標示記憶體規格 mem-16g、mem-24g
exclusive 標示此節點不接受並行 job 適用於需要全機資源的 Release Archive

多版本 Xcode 路由示例

若你有一台安裝了 Xcode 16.x 的舊節點與一台安裝了 Xcode 26 的新節點，可這樣路由：

# 舊 App，需要 Xcode 16.4 SDK
jobs:
  build-legacy:
    runs-on: [self-hosted, macOS, ARM64, xcode-16-4, region-hk]

# 新 App，使用最新 Xcode 26
jobs:
  build-new:
    runs-on: [self-hosted, macOS, ARM64, xcode-26, region-sg]

避坑提示：切勿讓兩個使用不同 Xcode 版本的 job 同時在同一節點的同一使用者下執行 xcodebuild，否則 DerivedData/ModuleCache 可能出現模組映射衝突，導致 SwiftEmitModule 隨機失敗。最簡單的解法是在節點上為不同 Xcode 版本建立獨立的 CI 使用者帳號。

六、代碼簽名安全配置：證書入 Keychain vs GitHub Secrets 最佳實踐

iOS 代碼簽名是自托管 Runner 最容易出錯的環節，核心問題在於：Runner 以 launchd 服務形式運行時，其 Keychain 上下文與互動式終端不同。

方案對比

面向 永久存入 Runner Keychain GitHub Encrypted Secrets（推薦）
安全性 證書常駐磁碟，節點被攻陷即洩露 每次 job 動態解密，Job 結束自動清理
輪換成本 需 SSH 進節點手動更新 在 GitHub UI 更新即可，無需觸碰節點
多 repo 共用 需在每台節點複製 Organization Secrets 一次設定全 repo 共用
launchd 服務相容性 需額外配置 SessionCreate 透過 $RUNNER_TEMP 臨時 Keychain，相容性更佳
Audit Log 無 GitHub 的 Secret Access Log 可稽核
適用場景 個人開發者、快速原型 生產環境、多人團隊（強烈推薦）

生產級推薦配置（GitHub Secrets 方案）

第一步：準備以下 Secrets（在 repo 或 Organization Settings 中設定）

Secret 名稱 內容
BUILD_CERTIFICATE_BASE64 P12 證書的 Base64 編碼字串
P12_PASSWORD P12 密碼
BUILD_PROVISION_PROFILE_BASE64 .mobileprovision 的 Base64 編碼字串
KEYCHAIN_PASSWORD 隨機產生的臨時 Keychain 密碼

第二步：在 YAML 中動態建立臨時 Keychain

- name: 安裝簽名證書與描述檔
  env:
    BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }}
    P12_PASSWORD: ${{ secrets.P12_PASSWORD }}
    BUILD_PROVISION_PROFILE_BASE64: ${{ secrets.BUILD_PROVISION_PROFILE_BASE64 }}
    KEYCHAIN_PASSWORD: ${{ secrets.KEYCHAIN_PASSWORD }}
  run: |
    # 解碼證書
    CERTIFICATE_PATH=$RUNNER_TEMP/build_certificate.p12
    echo -n "$BUILD_CERTIFICATE_BASE64" | base64 --decode -o $CERTIFICATE_PATH

    # 建立臨時 Keychain（每次 job 獨立）
    KEYCHAIN_PATH=$RUNNER_TEMP/app-signing.keychain-db
    security create-keychain -p "$KEYCHAIN_PASSWORD" $KEYCHAIN_PATH
    security set-keychain-settings -lut 21600 $KEYCHAIN_PATH
    security unlock-keychain -p "$KEYCHAIN_PASSWORD" $KEYCHAIN_PATH

    # 匯入證書
    security import $CERTIFICATE_PATH -P "$P12_PASSWORD" \
      -A -t cert -f pkcs12 -k $KEYCHAIN_PATH
    security set-key-partition-list -S apple-tool:,apple: \
      -k "$KEYCHAIN_PASSWORD" $KEYCHAIN_PATH
    security list-keychain -d user -s $KEYCHAIN_PATH

    # 安裝描述檔
    PP_PATH=$RUNNER_TEMP/build_pp.mobileprovision
    echo -n "$BUILD_PROVISION_PROFILE_BASE64" | base64 --decode -o $PP_PATH
    mkdir -p ~/Library/MobileDevice/Provisioning\ Profiles
    cp $PP_PATH ~/Library/MobileDevice/Provisioning\ Profiles/

- name: 清理簽名資產（必須放最後，if: always()）
  if: ${{ always() }}
  run: |
    security delete-keychain $RUNNER_TEMP/app-signing.keychain-db || true
    rm -f ~/Library/MobileDevice/Provisioning\ Profiles/build_pp.mobileprovision

關鍵細節：if: ${{ always() }} 確保即使前面的 step 失敗，簽名資產依然會被清除，避免敏感檔案殘留在節點磁碟。

七、常見報錯速查：Runner Offline / 證書 Keychain 鎖 / DerivedData 滿盤

報錯1：Runner 顯示 Offline

症狀：GitHub Settings 頁面 Runner 狀態為紅色 Offline，job 排隊但永遠不啟動。

原因定位：

# 確認 launchd 服務是否在運行
sudo launchctl list | grep actions.runner

# 查看 Runner 日誌（最後50行）
tail -50 ~/actions-runner/_diag/Runner_*.log

# 確認 svc.sh 服務狀態
cd ~/actions-runner && ./svc.sh status

修復動作： - 若服務已停止：./svc.sh start - 若服務顯示 exit code 非0：檢查是否因節點重啟後磁碟空間滿導致啟動失敗（df -h） - 若 Token 已過期（Registration Token 有效期24小時）：需重新執行 ./config.sh --token <NEW_TOKEN>

報錯2：xcodebuild archive 報 errSecInternalComponent（Keychain 鎖定）

症狀：/usr/bin/codesign: errSecInternalComponent，或「No signing certificate found」，僅在 svc.sh 服務模式下出現，但互動式 ./run.sh 正常。

原因：svc.sh 安裝為 LaunchDaemon 時，預設不建立使用者 Session，無法訪問使用者 Keychain。

修復動作：

# 找到 plist 位置
ls ~/Library/LaunchAgents/ | grep actions.runner

# 若為 LaunchDaemon（在 /Library/LaunchDaemons/ 下），需將 SessionCreate 設為 true
sudo plutil -replace SessionCreate -bool true \
  /Library/LaunchDaemons/com.github.actions.runner.*.plist

# 重新載入服務
sudo launchctl unload /Library/LaunchDaemons/com.github.actions.runner.*.plist
sudo launchctl load  /Library/LaunchDaemons/com.github.actions.runner.*.plist

根本解法：使用 ./svc.sh install 時確保以 CI 使用者身份執行（sudo -u ci-runner -i），Runner 會被安裝為 LaunchAgent 而非 LaunchDaemon，天然具備使用者 Session 上下文，簽名問題即可避免。

報錯3：DerivedData 滿盤導致構建失敗

症狀：xcodebuild 報 No space left on device，或構建時間突然暴增。

原因：中型 App 的 DerivedData 在 Debug 穩態約佔 6–14 GB，UI Test 期間可額外產生 3–10 GB 的 xcresult Bundle，加上 SPM 套件快取，256 GB SSD 在未定期清理的情況下數週即可填滿。

原因定位與修復：

# 查看磁碟使用量
df -h /

# 查看 DerivedData 實際大小
du -sh ~/Library/Developer/Xcode/DerivedData/

# 查看最大佔用的子目錄（找出哪個 App 的快取最大）
du -sh ~/Library/Developer/Xcode/DerivedData/*/ | sort -rh | head -10

# 清除超過7天未被存取的 DerivedData（加入 crontab 定期執行）
find ~/Library/Developer/Xcode/DerivedData -maxdepth 1 -mindepth 1 \
  -type d -atime +7 -exec rm -rf {} \;

# 清除所有 xcresult（一般可安全刪除）
find ~/Library/Developer/Xcode/DerivedData -name "*.xcresult" \
  -mtime +3 -delete

預防性配置：在 YAML 中每次 Archive 後主動清理 xcresult：

- name: 清理 xcresult（節省磁碟空間）
  if: ${{ always() }}
  run: |
    find ~/Library/Developer/Xcode/DerivedData \
      -name "*.xcresult" -mtime +1 -delete || true

八、何時應退回官方托管？誠實的決策矩陣

自托管方案並非對所有團隊都是最優解，以下情境應審慎評估：

情境 建議方案 原因
月構建量 < 30 小時 官方托管 未達損益平衡點，固定月租反而更貴
團隊無任何 DevOps 人力 官方托管 Runner 服務監控、磁碟清理需要維運成本
法規要求強制 Ephemeral 環境 官方托管 官方 Runner 每次 job 後銷毀 VM，天然滿足
開源公共 repo 官方托管（免費） 公開 repo 使用標準 Runner 完全免費
月構建量 30–120 小時，有 DevOps 資源 自托管 費用優勢明顯，DerivedData 快取加速顯著
Release 衝刺 + 多團隊並行 CI 混合策略 平日用自托管節省成本，衝刺週 burst 用官方
安全要求高但仍需自托管 自托管 + 強化清理 每次 Job 後刪除 Keychain + 描述檔（見第六節）

九、可引用硬核數據彙整

以下為本文使用的關鍵數據，供決策參考或向管理層彙報：

  1. GitHub 官方 macOS Runner（actions_macos）費率：$0.062/分鐘（2026年1月1日新費率，較舊費率已調降約11%，但仍是 Linux 標準型的 10倍以上）
  2. 月構建75小時的費用差距：官方托管 $279 vs 雲端 Mac 自托管約 $118，差距約 $161/月，年省近 $1,930
  3. 損益平衡點：月構建量超過 30 小時（1,817 分鐘） 即值得迁移自托管
  4. DerivedData 持久化節省構建時間：中型 App 冷啟動 8–12 分鐘 → 增量構建 2–4 分鐘，節省計費時間 50–67%
  5. DerivedData 典型磁碟佔用：Debug 穩態 6–14 GB，UI Test 期間額外增加 3–10 GB（來源：macxcode.com 2026年4月數據）
  6. 亞太節點上傳 App Store Connect 延遲改善：香港/新加坡節點比美國托管節點縮短跨洋上傳延遲約 30–60%
  7. 自托管 Runner 新增平台費：自 2026年3月1日起 $0.002/分鐘，計入方案免費額度；月構建75小時的平台費僅約 $9，遠低於官方托管節省金額
  8. Mac mini M4 雲端租用參考價：香港/新加坡節點 16 GB / 256 GB 方案約 $99–$110/月（含1 Gbps 獨立頻寬 + SSH + VNC）

結語：從官方托管到雲端 Mac 自托管——現在是最佳遷移時機

許多 iOS 團隊目前仍在用 GitHub 官方 macOS Runner，這個方案的確夠簡單：零配置、按需使用、帳號開即用。但隨著 App 規模成長、CI 頻率提升，它的侷限會愈來愈明顯：

  • 費用完全不可控：Sprint 後期 PR 密集合併時，單月帳單可能是平時的2–3倍，完全無法預算。
  • DerivedData 每次重算：每個 PR 的構建都要重新走一遍完整編譯，不僅慢，還讓每分鐘計費的帳單加速累積。
  • 無法選擇節點位置：亞太團隊上傳 Archive 只能走美國伺服器，跨洋延遲吃掉本可壓縮的時間成本。
  • Xcode 版本被動升級：映像更新後你的舊 SDK 就消失了，需要緊急調整 workflow，增加維護摩擦。

相比之下，雲端 Mac mini M4 自托管方案在固定月租結構下讓 CI 成本完全可預測——無論你這個月跑了30小時還是120小時，帳單幾乎不變。搭配本文的5步配置流程與代碼簽名安全最佳實踐，迁移成本不超過半個工作天。

立即在 MacDate 開通一台 Mac mini M4 節點，30分鐘完成 GitHub Actions Runner 注冊，首月構建成本直降60%——查看當前套餐與香港 / 新加坡節點價格 →

如果你還在評估「按天租用 Mac」是否適合你的工作流，歡迎先閱讀站內的按天租用 Mac 完全指南 FAQ，了解從開機、SSH 連線到 VNC 桌面的完整上手流程，再決定是否直接進入 CI/CD 節點部署。

延伸閱讀