Depot vs Blacksmith: GitHub Actions ランナー比較

著者 Daniel Zoghalchali·Latchkey

強みの異なる2つの人気マネージドランナー: Docker ビルドなら Depot、素の CPU 速度なら Blacksmith。

Depot も Blacksmith も GitHub ホステッドランナーを上回りますが、最適化している対象が異なります。ここでは正直な使い分けと、Latchkey のような自己修復オプションがどこに入るかを示します。

Depot vs Blacksmith at a glance

こんなときは Depot

CI が Docker イメージのビルドに支配されていて、リモートビルドキャッシュがボトルネックになっている場合。

こんなときは Blacksmith

ビルド/テスト時間が CPU に律速されていて、コアあたりの高速なハードウェアが効く場合。

• Published workload claims: Node.js builds 5.9x, Rust 4x, Docker 3x, and Android 2.3x faster than GitHub-hosted.
• Co-located CI cache and Docker layer caching, with sticky disks and static IPs as add-ons.
• Installed as a GitHub App, selected with runs-on labels.
• 3,000 free minutes per month.

第3の選択肢

本当の悩みがコストと不安定な再実行なら、どちらもそれを解決しません。Latchkey はより安いマネージドランナー上に自己修復を追加します。

• Unlimited cache storage, against the 10 GB per-repository ceiling on GitHub-hosted cache.
• RAM disks on by default, so heavy write workloads never touch a network volume.
• Billed per second rather than rounded up to the minute.
• No concurrency cap on simultaneous jobs.
• Runner images track GitHub-hosted definitions, updated within one to two weeks of a release.

実際のボトルネックはどちらか?

正直なところ、多くのチームはそれを把握しておらず、ブランドの印象で選んでいます。1つのjobで確かめられます。現在のrunnerで代表的なworkflowにこのステップを追加し、CPU時間と実時間の内訳を読んでください。

- name: Where does this job spend its time
  run: |
    /usr/bin/time -v ./your-build-command 2>&1 | tee timing.txt
    echo "--- cache restore ---"
    du -sh ~/.cache 2>/dev/null || true

# In the output:
#   "Percent of CPU this job got"  near 100% (or N x 100% when parallel)
#     -> CPU-bound. A faster core wins. Favor Blacksmith.
#   "Percent of CPU this job got"  well under 100%
#     -> the job is waiting on disk or network. Favor Depot.
#   "Elapsed (wall clock) time"  dominated by actions/cache restore
#     -> cache throughput is your ceiling. Favor Depot.

判断ルール

内訳が分かれば、選択は機械的です。

どちらもやらないこと

両ベンダーとも、成功するjobをより早く終わらせることで競っています。どちらも、コードとは無関係な理由でjobが失敗したときに起こることは変えません。registryのタイムアウト、不安定なネットワークマウント、一時的な依存解決の失敗、インストールされなかったブラウザバイナリ。どちらのプラットフォームでもそのjobは失敗し、人が気づき、誰かが再実行を押します。失敗したminuteと差し替えのminuteの両方を支払い、マージは人が起きているかどうかに左右されます。

• 失敗した実行は課金されます。再実行も同じです。どちらのベンダーも一時的な失敗を割り引きません。
• 実時間のコストはrunnerのminuteではなく、失敗とそれに気づいた人との間の空白です。
• flake率はrunnerの速度とは無関係です。2倍速いrunnerでも同じ頻度で、ただ早く失敗します。

How to evaluate a managed runner honestly

Runner vendors compete on a headline per-minute rate, and the rate is rarely what decides the bill. Measure the whole job, on your own pipeline, before committing.

• Compare at equal machine shape. A cheaper per-minute rate on fewer vCPUs or less RAM is not cheaper per unit of work.
• Check billing granularity. Per-minute rounding costs real money on a wide matrix of short jobs; per-second does not.
• Include queue and boot time. A runner that is cheaper per minute but slower to start can cost more per merge.
• Count your re-runs. If a meaningful share of your runs are retries of a failed job, you are paying for the same work twice at whatever rate you negotiated, and no rate card prices that.
• Verify the free tier is recurring. A one-time credit is not a free tier.

The verdict

Docker がボトルネック: Depot。CPU がボトルネック: Blacksmith。コスト + 信頼性: それらと並べて Latchkey も評価を。

よくある質問

関連ガイド