為什麼跑我自己的 runner 而不是 GitHub 託管的？

三個真實理由：把您自己的依賴和工具鏈烤進去（不用每次執行都重灌它們）、存取私有資源比如內部儲存庫或資料庫、以及對機器的掌控——它的大小、它的快取、它的網路。如果 GitHub 託管的分鐘數和一個乾淨環境適合您，就留在上面。當您特別需要這三樣之一時再自託管。

用一個自託管 runner 安全嗎？

在私有儲存庫上，安全。在公開儲存庫上，不——永遠別。一個工作流跑觸發它的人的任意程式碼，在公開儲存庫上一個陌生人的 pull request 能在您的 runner 上跑他們的程式碼。GitHub 自己的文件也這麼說。把自託管 runner 留給私有儲存庫，否則就接受您把機器交給了公用。

一個 runner 需要多少 CPU 和 RAM？

完全取決於您的建置。一個典型的編譯加測試任務，2 核加 4-8 GB 就很舒服——這裡的 Small 或 Medium。重的建置（大的原生編譯、大的 Docker 映像、吃記憶體的測試套件）想要更多，您該按您實際的任務設定，而不是猜。看一次真實執行您就知道了。

一個 runner 能處理多個儲存庫嗎？

一個 runner 能註冊到一個組織、被好幾個儲存庫領用，預設一次一個任務。要更多並行，就跑更多 runner——每個是它自己的 systemd 服務。只要讓它們全都在私有儲存庫上。

我需要給您們證件嗎？

不用。電子郵件註冊、USDC 或 USDT 付款。不用檔案，約一分鐘拿到 root。

在 VPS 上執行一個自託管的 GitHub Actions Runner

GitHub 託管的 runner 是個不錯的預設。在一次建置想要它們沒有的東西的那一刻，您就不再需要它們了——您的私有套件儲存庫、一個您厭倦了每次執行都重灌的特定工具鏈版本、您自己網路上的一個資料庫，或只是對機器多一點掌控。那時，一台 VPS 上的自託管 runner 就值它的錢了。

本指南把一個 runner 正經跑起來：裝好、註冊、在 systemd 下活著，以及——人們弄錯的部分——安全。我們從最後這個開始，因為它是咬人的那部分。

那一條安全規則

一個 GitHub Actions 工作流跑任意程式碼——工作流檔案裡的一切，以及那程式碼拉進來的一切。在您自己的儲存庫上那是您的程式碼，沒問題。在一個公開儲存庫上，一個陌生人的 pull request 能在您的 runner 上跑他們的程式碼。那不是 bug；是 CI 就這麼運作的。GitHub 自己的文件直白地說：別把自託管 runner 用在公開儲存庫上。

所以規則很簡單、也不可商量：自託管 runner 是給私有儲存庫的。 如果您的儲存庫是公開的，用 GitHub 託管的 runner、往前走。下面的一切都假設一個私有儲存庫。

runner 需要機器提供什麼

它取決於建置，您該按您的來設定、而不是照抄頁面上的一個數字：

一個典型的編譯加測試任務 —— 2 核加 4-8 GB 就很舒服。Small（$8，4 vCPU / 4 GB）或 Medium（$12，6 vCPU / 6 GB）覆蓋大多數這類。
更重的建置 —— 大的原生編譯、大的 Docker 映像建置、吃記憶體的測試套件——想要更多餘量。看一次真實執行（建置時開 htop）、按您實際看到的設定，而不是靠希望。

磁碟也要緊：建置快取、Docker 層和克隆的儲存庫會累加。盯著它、及時清理。

1. 準備機器

給 runner 建立一個非 root 使用者——反正 GitHub 的安裝器拒絕以 root 跑，您也想要這樣：

sudo adduser --disabled-password --gecos "" runner
sudo usermod -aG sudo runner   # 只在你的建置真的需要 sudo 時

裝上您建置需要的一切——一個語言工具鏈、Docker、建置工具。比如，如果您的任務建置容器：

sudo apt update && sudo apt install -y docker.io
sudo usermod -aG docker runner

2. 下載並註冊 runner

在 GitHub 上您的儲存庫（或組織）裡，去 Settings → Actions → Runners → New self-hosted runner。GitHub 給您確切的下載指令和一個註冊權杖（它是短期的——現拿現用）。以 runner 使用者身分：

sudo -iu runner
mkdir actions-runner && cd actions-runner
# 用 GitHub 為你的 OS/arch 顯示的確切 URL：
curl -o actions-runner-linux-x64.tar.gz -L "URL_FROM_GITHUB"
tar xzf actions-runner-linux-x64.tar.gz
./config.sh --url https://github.com/YOUR_ORG/YOUR_REPO --token YOUR_TOKEN

config.sh 問一個 runner 名字、標籤和一個工作資料夾——起步用預設值就行。標籤是您的工作流瞄準這個 runner 的方式（runs-on: self-hosted）。

3. 作為 systemd 服務來跑

runner 自備一個幫您安裝 systemd 服務的輔助指令碼——用它，好讓 runner 熬過重新啟動、失敗時重新啟動。仍然在 runner 使用者的安裝裡，但服務指令需要 root：

sudo ./svc.sh install runner
sudo ./svc.sh start
sudo ./svc.sh status

那把 actions.runner.* 註冊成一個以 runner 使用者執行、開機啟動的 systemd unit。記錄進 journald：

sudo journalctl -u 'actions.runner.*' -f

回到 GitHub 的 Runners 頁，您的 runner 現在顯示 Idle——綠點。把一個工作流指向它：

jobs:
  build:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - run: make test

推送，任務就在您的機器上跑。

4. 保持乾淨

一個自託管 runner 在任務之間複用它的檔案系統——那是速度收益（熱快取），也是那把走火的槍（殘留狀態）。兩個習慣讓它健康：

定期清理。 尤其是 Docker——docker system prune 放上 cron，否則磁碟會被死層悄悄填滿。
別在機器上存機密。 用 GitHub Actions secrets、按每次執行注入，而不是躺在 runner 家目錄裡的檔案。如果 runner 被攻陷，磁碟上的任何東西都隨它一起走。

如果您需要每個任務一個真正乾淨的環境，就把每個任務放進一個容器步驟裡跑——runner 留著，任務的爛攤子不留。

什麼時候該自託管，誠實地

當您需要把自己的工具鏈烤進去、存取私有網路資源、或對機器有掌控時自託管。當一個乾淨、一次性的環境和他們的分鐘數適合您時，留在 GitHub 託管的 runner 上——那確實更簡單，而簡單值點東西。而且永遠、在公開儲存庫上，別自託管。那一條不是偏好。

如果您需要的是一個私有儲存庫 runner：挑一個方案——輕建置用 Small（$8）、變重時用 Medium（$12）——用 USDC 或 USDT 付款（免 KYC、不用檔案），您大約 60 秒就有 root。然後照著這一頁往下做，幾分鐘後您就有一個在領任務的 runner 了。

檢視方案並訂購 VPS →