Actuated vs self-hosted runner：ephemeral な VM による CI
Actuated はより強力な分離のためにマネージドで ephemeral な microVM runner（Firecracker ベース）を提供します。自作の self-hosted runner は完全な制御が得られますが、すべてを自分で構築・保守します。
GitHub Actions の runner を self-host すると hosted 分のコストは削減できますが、プロビジョニング、スケーリング、パッチ適用、分離といった運用負担が増えます。Actuated は ephemeral な Firecracker microVM を使うマネージドなアプローチを提供し、各 job にクリーンで分離された VM を割り当てることで、長寿命な self-hosted マシンのセキュリティと保守の問題を軽減します。
| Actuated | 自作の self-hosted | |
|---|---|---|
| 分離 | job ごとの ephemeral な microVM | 多くの場合、共有/永続ホスト |
| セットアップと運用 | マネージドなコントロールプレーン | 自分で構築・運用する |
| スケーリング | 自動で処理される | オートスケーリングを自分で実装 |
| セキュリティ保守 | 軽減（job ごとに新しい VM） | 自分でパッチ適用・ハードニング |
| ハードウェアの制御 | 自前のサーバー、マネージド | 完全な制御 |
Actuated が適する場面
self-host の経済性とハードウェアの制御は欲しいが、分離とオートスケーリングを構築する負担は避けたい場合、Actuated は各 job を新しい Firecracker microVM で実行し、永続的な self-hosted runner の再利用とセキュリティの懸念に対処しつつ、マネージドなコントロールプレーンを維持します。
自作の self-hosted が適する場面
純粋な self-host は完全な制御を与えます。任意のハードウェア、任意のネットワーク、任意のカスタマイズが可能で、VM ごとのツール依存もありません。すべてのレイヤーを自分で所有したいプラットフォームエンジニアを抱えるチームや、特殊なハードウェア/コンプライアンス要件がある場合、自作の runner は最も柔軟なままです。ただしスケーリング、分離、パッチ適用を自分で構築するコストがかかります。
その他の選択肢
この 2 つ以外に、マネージドな runner サービスはオートスケーリング、ウォームプール、一時的な失敗の自動リトライとともに runner を代わりに実行し、運用を完全に取り除きつつ、GitHub がホストする分と比べてコストも削減します。自作の runner を運用することも、自分で microVM ツールを動かすことも望まないなら、マネージドな提供を評価しましょう。
結論
マネージドなコントロールプレーンとともに自前のハードウェア上で ephemeral な microVM 分離を得たいなら Actuated を、運用リソースがあり完全な制御が欲しいなら自作の self-hosted runner を選びましょう。運用ゼロを望むチームは、フルマネージドな runner サービスも比較すべきです。