Latchkey vs RunsOn: マネージド GitHub Actions ランナー比較

Latchkey も RunsOn も、GitHub ホステッドより速く安い GitHub Actions ランナーを提供します。最大の違いは、Latchkey が 自己修復 を備えており、一時的な障害が自動的に回復する点です。

RunsOn は、最大限のコスト管理のために、自分の AWS アカウント内に self-hosted な GitHub Actions ランナーをデプロイします。Latchkey は GitHub ホステッドより安いマネージドランナー上で GitHub Actions を実行し、自己修復 CI を追加します。一時的・機械的な障害を検知して修復し自動でリトライするため、不安定なビルドがパイプラインを失敗させることがなくなります。以下で両者を比較します。

一目でわかる比較

機能	RunsOn	Latchkey
ドロップイン型マネージドランナー	あり	あり
GitHub ホステッドより安い	あり	あり（1分あたり約70%安い）
組み込みキャッシュ	あり	あり（依存関係 + Docker レイヤー）
自己修復 CI（一時的な障害の自動リトライ）	なし	あり
得意分野	自分の AWS 内のランナー	自己修復 + 低コストなマネージドランナー

RunsOn の強み

RunsOn は、EC2 の素のコストで自分の AWS アカウント内にランナーを置き、データの所在を完全に管理したい場合に最適です。

Latchkey が加えるもの

Latchkey は自己修復 CI を中心に設計されています。マネージドランナー上では、メモリ不足による強制終了、ディスク満杯エラー、レジストリのタイムアウトなど、一時的・機械的な障害が自動的に検知・リトライされます。そのため再実行に料金を払い続けることも、赤いビルドのお守りをすることもなくなります。さらに、GitHub ホステッドより1分あたり約70%低いコストのマネージドランナーを組み合わせて提供します。

RunsOn と Latchkey の選び方

自分の AWS アカウント内にランナーを置き、そのインフラを自分で管理するなら RunsOn。
最も低コストなマネージドランナーに 加えて、不安定な再実行を自動で解消する自己修復が欲しいなら Latchkey。

結論

自分のクラウド内で自己管理するランナーを最優先するなら、RunsOn は堅実な選択です。より安いランナーと、一時的な障害から自力で回復するパイプラインが欲しいなら、Latchkey の方が適しています。無料で始めて、実際のビルドで比較してみてください。

よくある質問

Latchkey は RunsOn のドロップイン代替になりますか？

どちらもラベルの変更だけで GitHub Actions のワークフローにマネージドランナーを接続するため、切り替えの手間はわずかです。ベンダーの料金は変わるため、RunsOn の最新料金は公式サイトで確認してください。