Depotの代替：自己修復するGitHub Actionsランナー
Depotは強力なドロップイン型のマネージドランナーです。ボトルネックがDockerビルドのスループットではなく、不安定な再実行と分単位のコストであるなら、自己修復型の代替のほうが適しているかもしれません。
Depotは、runs-onラベルを変更するだけで導入できるマネージドGitHub Actionsランナーを提供します（例：runs-on: depot-ubuntu-24.04、Depotのドキュメントより）。加えて分散キャッシュとリモートDockerビルドも備えます。その役割において本当に優れています。このページは、Depotが際立つ場面と、チームが代替を探す場面を公平に整理したもので、適切なツールを選べるようにするためのものです。Latchkeyはそうした代替の一つで、同じくドロップインですが、自己修復するCIを中心に設計されています。ベンダー固有の内容は変わるため、最新のDepotの詳細はdepot.dev/docsで、料金はdepot.dev/pricingで確認してください。
Depot vs 自己修復型の代替
| 機能 | Depot | Latchkey |
|---|---|---|
| runs-onラベルによるドロップイン導入 | 対応（例：depot-ubuntu-24.04） | 対応 |
| GitHubホスト型より安価 | 対応（Depot：GitHubホスト型の約半分のコスト） | 対応（分単位で最大70%低減） |
| 分散キャッシュ | 対応（Depot：10倍高速、最大1000 MiB/s、設定不要） | 組み込み（依存関係 + Dockerレイヤー） |
| リモートDockerビルド | 強力（ランナーの隣にBuildKitビルダー） | 標準的なDockerレイヤーキャッシング |
| ランナーの種類 | Intel/ARM/macOS/Windows/GPU（GPUはBusinessプラン） | マネージドLinuxランナーのサイズ各種 |
| 自己修復するCI（一時的な失敗の自動修正 + リトライ） | なし | あり |
Depotが本当に得意とすること
正当に評価しましょう。Depotのドキュメントによれば、そのランナーはruns-onラベルの変更だけで導入でき、高速なCPU（Intel向けは第4世代AMD EPYC Genoa、ARM向けはAWS Graviton4）で動作し、Depotが設定変更なしで最大10倍高速、アップロード/ダウンロードは最大1000 MiB/sと謳う統合された分散キャッシュを備えます。そのUltra Runnersは、GitHubホスト型より最大3倍高速と謳われています（Depotはこれを、メモリの最大25%を確保するRAMディスクによるものと一部説明しています）。CIがコンテナイメージのビルドとキャッシュヒット率に支配されているなら、Depotは強力な選択です。
チームが代替を探す理由
通常の理由は速度ではなく、信頼性とコストです。高速なランナーでも、一時的・機械的な問題では失敗し、それらのジョブを再実行すると費用と時間がかかります。それこそ自己修復するランナーが埋めるギャップです。注意：Depotのよく知られた「55x」という数字は、Dockerビルドの顧客事例（PostHog）とホームページのDockerビルドのキャッチコピーから来ており、そのランナーのものではないため、ランナーへの期待値の設定には使わないでください。
Latchkeyが適する場面
Latchkeyはruns-onの入れ替えで到達できるドロップイン型のマネージドランナーで、自己修復するCIを中心に構築されています。一時的・機械的な失敗を自動で検出・診断・修正・リトライし、GitHub Actionsより分単位で最大70%低いコストを掲げています。多くのチームはDockerビルドの多いジョブにはDepotを残し、不安定でコストに敏感なワークフローをLatchkeyへ移します。両方を併用できます。
結論
コンテナビルドとキャッシュヒット率がCIを支配しているなら、Depotは堅実な選択であり、それらのジョブには使い続ける価値があります。より大きな痛みが不安定な再実行と分単位のコストであるなら、Latchkeyのような自己修復型の代替を一つのワークフローで評価し、実際のビルドと比較してみてください。最新のDepotの料金は必ずdepot.dev/pricingで確認してください。