GitHub Actions 為什麼很慢？別再每個作業都重建一次環境
很慢的 GitHub Actions 作業，大部分時間都花在第一個測試執行之前。設定 Node、下載相依套件、建置 Docker 映像檔：每次推送都是同樣的幾分鐘，而團隊裡總有人在等那個綠色勾勾。按分鐘計費時，這幾分鐘你也要付錢。
Skipbox 是會在作業之間保留機器的 GitHub Actions Runner，所以一個作業安裝的東西，下一個作業開始時還在磁碟上。改一行 runs-on: skipbox，作業就會在你的專屬機器上執行，每月固定 $39，分鐘數不限。
每個作業都從空白的 VM 開始
GitHub 託管 Runner 為每個作業準備一台新的虛擬機器。上一個作業下載或建置的東西都不在上面，所以每個作業都要重建同樣的狀態：
| 步驟 | GitHub 託管 Runner | Skipbox |
|---|---|---|
| 設定 Node、Python、Java | 下載工具鏈 | 從上一個作業留下的工具快取中找到 |
| 安裝相依套件 | 下載並解開快取壓縮檔；沒命中時，整個從套件登錄下載 | 從磁碟讀取套件管理工具的快取 |
| 建置 Docker 映像檔 | 從沒有任何層開始，每個步驟都重建 | 重複使用上次建置的層 |
| 執行測試 | 私有儲存庫的 ubuntu-latest 是 2 顆 CPU | 4 vCPU 起 |
前三列都沒有產生任何新東西。它們只是把機器恢復成昨天的樣子。
GitHub 的快取能減輕這個問題，但改變不了它。每個儲存庫只有 10 GB，7 天沒有作業讀取的項目會被刪除，新的功能分支也無法讀取其他功能分支的快取。即使命中，每次執行還是要下載並解開一個壓縮檔。
等待讓你付出什麼代價
假設每個作業的準備要花 3 分鐘，而團隊每天跑 100 個作業。那就是每天 300 分鐘的 Runner 時間，都花在把機器恢復原狀上，而每個 Pull Request 都要分攤等待。審查更晚開始，合併更晚完成，工程師在等待時轉去做別的事。
按分鐘計費時，這些分鐘數都會出現在帳單上。以 4 vCPU Runner 的每月分鐘數計算：
| 每月分鐘數（4 vCPU） | GitHub | Skipbox S | 每月省下 |
|---|---|---|---|
| 10,000 | $102 | $39 | $63 |
| 20,000 | $222 | $39 | $183 |
| 30,000 | $342 | $39 | $303 |
GitHub 的金額是扣除 GitHub Team 內含用量後的帳單。把你自己的分鐘數填進首頁的費用試算，不必登入。
而且執行次數只會越來越多：
- AI 程式設計代理。 代理每次推送都會啟動 CI。等待和帳單都跟著推送次數增加，而不是人數。
- 更多測試。 一套端對端測試或矩陣，會在它增加的每個作業裡重複準備步驟。
- 預算。 用 GitHub 預算壓住帳單，作業就會在月中停止啟動，合併也跟著停擺。
自己動手加速，是一整個專案
留在 GitHub 託管 Runner 上又要讓它變快，就得接下這些工作：
- 以 lockfile 的雜湊值作為快取 key，並反覆調整
restore-keys直到命中 - 加入 buildx，用
cache-to匯出 Docker 的快取，而且一樣受限於 10 GB - 把測試分片，但每個分片都會重複準備步驟，計費的分鐘數也跟著增加
- 或是自己維運自架 Runner：佈建、更新作業系統、在作業之間清理環境，掛掉時還要修好
每一項都是在繞過一台什麼都會忘記的機器。Skipbox 會保留機器，所以這些都不需要。
換到 Skipbox 後有什麼不同
準備好的環境留在磁碟上。 你的作業在帳號專屬的機器上執行，而這台機器在作業之間一直都在。Docker 映像檔、層和建置快取；npm、pip、Gradle 等的套件快取；setup-node 等 Action 安裝的工具。快取空間至少是 GitHub 的 7 倍，不會在 7 天後過期，也沒有分支的限制。
更大的機器，固定的價格。 編譯器和測試執行工具會依核心數啟動 worker，所以核心越多，受 CPU 限制的步驟就越短。
| 方案 | 機器 | 價格 |
|---|---|---|
| S | 4 vCPU · 16 GB | 每月 $39 |
| M | 8 vCPU · 16 GB | 每月 $79 |
| L | 16 vCPU · 32 GB | 每月 $149 |
每個方案的分鐘數都不限。Skipbox 的作業不用 GitHub 分鐘數，所以 GitHub 預算絕不會讓它們停下來。
沒有機器要照顧。 Skipbox 會佈建機器、更新作業系統和工具、在每個作業後清理環境、執行健康檢查，並重建檢查失敗的機器。
換過去只要改一行
jobs:
build:
runs-on: skipbox # was ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test- 使用 GitHub 登入 Skipbox。
- 安裝 Skipbox GitHub App，並選擇儲存庫。
- 修改
runs-on並推送。
第一個作業安裝的東西，第二個作業開始時就在磁碟上。
安全性
- 機器只屬於你的帳號。其他公司的作業不會在上面執行。
- 每個作業結束後，Runner 的憑證、程序和容器都會被清除。從 2026 年 11 月 13 日起，你的 checkout 和它的建置輸出（Cargo 的
target/）會留在你的專屬機器上，供之後的作業使用；開啟「每個作業都用新 VM」，每個作業就會用一台全新的機器。 - 沒有寫入權限的人提交的程式碼（例如來自 fork 的 Pull Request）會在全新、用完即丟的機器上執行。
詳情請見作業如何隔離。
用你最慢的作業試試看
試用免費，為期 7 天或 3,000 作業分鐘，以先到者為準，不需信用卡。把最慢的作業改成 runs-on: skipbox，連續執行兩次，再把各步驟的時間和 GitHub 上的並排比較。
常見問題
GitHub Actions 為什麼這麼慢？
GitHub 託管 Runner 上的每個作業，都從一台沒有上次執行任何東西的新 VM 開始，所以在測試開始之前，它要先下載工具、重新安裝相依套件、重建 Docker 映像檔。Skipbox 在你帳號專屬的機器上執行作業，並把這些狀態留在磁碟上，所以下一個作業會從上一個作業結束的地方接著開始。
我已經加了 actions/cache，為什麼工作流程還是很慢？
因為 VM 每次都是新的，即使快取命中，每個作業還是要下載並解開一個壓縮檔。而且 GitHub 的快取每個儲存庫只有 10 GB，7 天沒用到的項目會被刪除，也無法從同層的其他分支讀取。在 Skipbox 上，套件快取和 Docker 層本來就在機器的磁碟上，不需要管理任何 key。
怎麼讓 GitHub Actions 裡的 Docker 建置變快？
讓建置拿到上次建置的層。在 GitHub 託管 Runner 上，這表示要用 buildx 匯出快取、每次執行時再匯入，而且一樣受限於 10 GB。在 Skipbox 上，Docker 的映像檔和建置快取會在作業之間留在機器上，所以 docker build 會自己重複使用這些層。
改用 Skipbox 需要重寫工作流程嗎？
不需要。Linux 作業只要把 runs-on 改成 skipbox。機器執行內含 Docker、Node.js 和 Python 的 Ubuntu 24.04，你的步驟和 Action 照原樣執行。
可以免費用我自己很慢的作業試試看嗎？
可以。試用為期 7 天或 3,000 作業分鐘，以先到者為準，不需信用卡。把最慢的作業改成 runs-on: skipbox，連續執行兩次，再把各步驟的時間和 GitHub 上的比較。
更新於 2026年11月11日