self-hosted GitHub Actions runnerの選択肢を比較 (2026)
自前のインフラ内にrunnerを置きたいなら、いくつかのツールが、生のrunnerエージェントを自分で動かすよりはるかに手間を減らしてくれます。
self-hostingはもはや、VM上でGitHub runnerのバイナリを手作業で管理することを意味しません。あるカテゴリのツールが、自前のクラウドやハードウェア内でrunnerを起動しライフサイクルを管理します。AWSアカウント内のRunsOn、Firecracker microVMを使うActuated、クラウド内でオンデマンド(GPUを含む)runnerを起動するCirun、Kubernetes上のActions Runner Controller (ARC) です。これらはジョブがどこで動くか、どう隔離するか、どれだけ自分で運用するかで異なります。各プロジェクトのサイトで現在の機能を確認してください。
self-hosted runnerツールの概観
| ツール | 動作場所 | 知られている点 |
|---|---|---|
| RunsOn | 自分のAWSアカウント (EC2/spot) | 生のEC2費用、データは自分のクラウドに留まる |
| Actuated | 自前のベアメタル / Arm、Firecracker microVM | 強力なmicroVM隔離、Armワークロード |
| Cirun | 自分のクラウド、オンデマンド | GPUを含むrunnerをオンデマンドで起動 |
| Actions Runner Controller (ARC) | 自分のKubernetesクラスタ | K8sネイティブなrunnerのオートスケーリング |
すでに動かしている場所で選ぶ
- AWS上で最も低い生のcomputeが欲しい: RunsOnはEC2/spot費用で自分のアカウントにrunnerを維持する。
- 自前のベアメタルやArmハードウェアがあり隔離が欲しい: ActuatedはFirecracker microVMを使う。
- GPUや専用ハードウェアがオンデマンドで必要: Cirunがクラウド内で起動する。
- すでにKubernetesを運用している: ARCがrunnerをpodとしてオートスケールする。
それでも自分で運用するもの
これらはいずれもデータとcomputeを自分のインフラ内に保ちます。それがまさに制御とデータ所在の観点での狙いです。トレードオフは、スケーリングポリシー、イメージのパッチ適用、クォータ制限、ディスクの後始末、詰まったフリートのオンコールが自分の責任のまま残ることです。その継続的な運用時間こそ、どのツールを選んでもself-hostingの本当のコストです。
マネージドという中間解
フリートを所有せずにself-hosted風の経済性が欲しいなら、マネージドrunnerが代替案です。Latchkeyはruns-onを1行入れ替えるだけで到達できるマネージドで隔離されたrunner上でジョブを実行し、低い分単位料金で、自己修復を加えて一時的な失敗が自動的に回復するようにします。インフラを所有することを手放す代わりに、それを運用しなくてよくなります。
結論
自前クラウドでのrunnerは、プラットフォームで選びましょう。RunsOn (AWS)、Actuated (ベアメタル/Arm)、Cirun (オンデマンド/GPU)、ARC (Kubernetes) です。いずれかの運用負荷が本当のコストなら、同等の経済性をフリート運用なしで得られるLatchkeyのようなマネージドrunnerを検討してください。