GitHubホスト型ではなく自分のランナーを動かすのはなぜ？

実際の理由が三つ：自分の依存とツールチェーンを焼き込む（毎回入れ直さない）、内部レジストリやデータベースのようなプライベートリソースへのアクセス、そしてマシンの制御 — そのサイズ、キャッシュ、ネットワーク。GitHubホスト型の分数ときれいな環境が合うなら、それに留まってください。この三つのどれかが特に要るとき自ホストを。

自ホストのランナーを使うのは安全ですか？

プライベートリポでは、はい。公開リポでは、いいえ — 決して。ワークフローはトリガーした者の任意のコードを走らせ、公開リポでは見知らぬ人のプルリクエストがその人のコードをあなたのランナーで走らせられます。GitHub自身のドキュメントも同じことを言います。自ホストのランナーはプライベートリポに留めるか、箱をインターネットに手渡していると受け入れましょう。

ランナーにCPUとRAMはどれくらい要りますか？

完全にビルド次第。典型的なコンパイル＆テストのジョブは2コアと4-8 GBで快適 — ここではSmallかMedium。重いビルド（大きなネイティブコンパイル、大きなDockerイメージ、メモリを食うテストスイート）はもっと欲しがり、当て推量ではなく実際のジョブに合わせるべきです。一度の実ランを見れば分かります。

一つのランナーで複数のリポを扱えますか？

ランナーは組織に登録でき複数のリポに拾われますが、既定では一度に一ジョブです。より多くの並列には、より多くのランナーを — それぞれが自分のsystemdサービス。ただ全部プライベートリポに留めること。

IDを渡す必要がありますか？

いいえ。サインアップはメール、支払いはUSDCかUSDT。書類なし、約1分でroot。

VPSで自ホストのGitHub Actionsランナーを動かす

GitHubホスト型のランナーは良い既定です。ビルドが彼らの持たない何かを欲しがった瞬間、それらは要らなくなります — あなたのプライベートパッケージレジストリ、毎回入れ直すのに疲れた特定のツールチェーンバージョン、自分のネットワーク上のデータベース、あるいは単にマシンのより多くの制御。そのとき、VPS上の自ホストランナーが値打ちを稼ぎます。

このガイドは一つをちゃんと動かします：インストール、登録、systemdの下で生き、そして — 人々が間違える部分 — 安全に。その最後から始めましょう、それが噛みつく部分だからです。

唯一のセキュリティルール

GitHub Actionsのワークフローは任意のコードを走らせます — ワークフローファイルにあるもの、そしてそのコードが引き込むもの何でも。自分のリポではそれはあなたのコードで、問題ありません。公開リポでは、見知らぬ人からのプルリクエストがその人のコードをあなたのランナーで走らせられます。それはバグではなく、CIがそう動くのです。GitHub自身のドキュメントは平然と言います：公開リポジトリで自ホストのランナーを使うな。

だからルールは単純で交渉の余地なし：自ホストのランナーはプライベートリポのためのもの。 リポが公開なら、GitHubホスト型のランナーを使って先に進みましょう。以下すべてはプライベートリポを前提とします。

ランナーが箱に要求するもの

ビルド次第で、ページの数字ではなく自分のに合わせてサイズを取るべきです：

典型的なコンパイル＆テストのジョブ — 2コアと4-8 GBで快適。Small（$8、4 vCPU / 4 GB）か Medium（$12、6 vCPU / 6 GB）がこれらの大半をカバー。
より重いビルド — 大きなネイティブコンパイル、大きなDockerイメージビルド、メモリを食うテストスイート — はより余裕を欲しがります。一度の実ラン（ビルド中に htop）を見て、期待ではなく実際に見えるものに合わせて。

ディスクも大事：ビルドキャッシュ、Dockerレイヤー、クローンしたリポが積み上がります。目を配ってpruneを。

1. 箱を準備する

ランナー用に非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. ランナーをダウンロードして登録する

GitHubのリポ（またはorg）で Settings → Actions → Runners → New self-hosted runner へ。GitHubが正確なダウンロードコマンドと registration token を渡します（短命なので新鮮なのを取る）。runner ユーザーとして：

sudo -iu runner
mkdir actions-runner && cd actions-runner
# あなたのOS/arch向けにGitHubが示す正確な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 はランナー名、ラベル、workフォルダを尋ねます — 始めるには既定でOK。ラベルはワークフローがこのランナーを狙う手段です（runs-on: self-hosted）。

3. systemdサービスとして動かす

ランナーには、systemdサービスをあなたのために入れるヘルパーが付いています — それを使い、ランナーが再起動を生き延び失敗で再起動するように。まだ runner ユーザーのインストールですが、サービスコマンドはrootが要ります：

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

それが actions.runner.* を runner ユーザーとして動くsystemdユニットとして登録し、起動時に始めます。ログはjournaldへ：

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

GitHubのRunnersページに戻ると、ランナーは今 Idle — 緑の点。ワークフローをそれに向けます：

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

プッシュすれば、ジョブがあなたの箱で走ります。

4. きれいに保つ

自ホストのランナーはジョブの間ファイルシステムを再利用します — それが速さの勝ち（温かいキャッシュ）で、落とし穴（残った状態）です。二つの習慣が健康に保ちます：

定期的にprune。 特にDocker — cronで docker system prune、さもないとディスクが死んだレイヤーで静かに埋まります。
箱に秘密を保存しない。 GitHub Actionsのシークレットを使い、ラン毎に注入、ランナーのhomeに置かれたファイルではなく。ランナーが侵害されれば、ディスク上のものは一緒に行きます。

ジョブごとに本当にきれいな環境が要るなら、各ジョブをコンテナステップの中で走らせます — ランナーは残り、ジョブの散らかりは残りません。

いつ自ホストするか、正直に

自分のツールチェーンを焼き込みたい、プライベートネットワークリソースへのアクセス、マシンの制御が要るとき自ホストを。きれいな使い捨ての環境と彼らの分数が合うならGitHubホスト型に留まる — それは本当に単純で、単純には価値があります。そして決して、公開リポで自ホストしないこと。それは好みではありません。

プライベートリポのランナーが要るものなら：プランを選び — 軽いビルドには Small（$8）、重くなったら Medium（$12） — USDCまたはUSDTで支払い（KYCなし、書類なし）、約60秒でrootを得ます。それからこのページを下へ進め、数分後にはジョブを拾うランナーができています。

プランを見て VPS を注文 →