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

> GitHub Actions における Depot と Blacksmith の比較。Depot は Docker ビルドキャッシュ、Blacksmith は CPU 速度で先行します。どう選ぶか、そして自己修復がどこに位置づくかを解説します。

Source: https://latchkey.dev/ja/learn/compare-runners/depot-vs-blacksmith  
Updated: 2026-08-20

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

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

## Comparison

|  | Depot | Blacksmith |
| --- | --- | --- |
| 得意なこと | Docker ビルドの高速化 + リモートキャッシュ | 高クロックの CPU ランナー |
| 最適なワークロード | コンテナ中心のパイプライン | シングルスレッドのビルド/テスト |
| 自己修復 | なし | なし |
| Linux arm64、2 vCPU | 個別料金の公表なし | $0.0025/min |
| コンピュート基盤 | jobごとにシングルテナントのEC2インスタンス | ベアメタルのゲーミングCPU、Firecracker microVM |
| 最適化の対象 | ディスクとcacheのスループット | シングルコアの実時間速度 |
| Cache | 無制限ストレージ、最大1,000 MiB/s | 同一ロケーションのcache、sticky disk |
| 課金の粒度 | 秒単位 | 分単位 |
| 無料枠 | 月$20のDeveloperプランにminuteを含む | 月3,000分 |
| 起動時間 | 非公表 | 3秒未満 (公表値) |
| 失敗の自動回復 | なし | なし |

## こんなときは Depot

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

| Linux x64 size | GitHub-hosted | Depot | Blacksmith |
| --- | --- | --- | --- |
| 2 vCPU | $0.006 | $0.004 | $0.004 |
| 4 vCPU | $0.012 | $0.008 | $0.008 |
| 8 vCPU | $0.022 | $0.016 | $0.016 |
| 16 vCPU | $0.042 | $0.032 | $0.032 |

> The one published rate that does separate them is Linux arm64. Blacksmith lists ARM at $0.0025/min; Depot does not publish a separate ARM rate. If your builds run on ARM, that gap is real money and it favors Blacksmith.

## こんなときは 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.

> Single-thread performance is the right thing to optimize when your critical path is one process doing one thing: `tsc`, a Rust or Kotlin compile, a Webpack bundle, a single-threaded test runner. Adding vCPUs does not help those; a faster core does.

## 第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.

> Per-second billing sounds like a rounding detail and is not. A pipeline of 40 short jobs averaging 70 seconds each pays for 40 full minutes on a per-minute biller and roughly 47 minutes of actual time on a per-second one. The shorter and more numerous your jobs, the more the rounding costs you.

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

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

```Measure before you choose (GitHub Actions step)
- 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.
```

## 判断ルール

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

| pipelineを支配しているもの | 選ぶべきもの | 理由 |
| --- | --- | --- |
| TypeScript、Rust、Kotlin、C++のコンパイル | Blacksmith | コンパイルのクリティカルパスはシングルスレッド。効くのはクロック速度 |
| 大きなlayerを持つDockerイメージのビルド | Depot | layer cacheのスループットとRAMディスクがビルド時間を支配する |
| 大きな依存ツリーの `actions/cache` 復元 | Depot | 10 GB上限に対し、1,000 MiB/sで無制限のcache |
| シングルスレッドのテストランナー | Blacksmith | コンパイルと同じ理由。作業をするのは1コア |
| 大きなmatrixに多数の短いjob | Depot | 秒単位課金により、切り上げ分を払わずに済む |
| ARM64ビルド | Blacksmith | 公表ARM料金$0.0025/min。DepotはARMの個別料金を公表していない |
| 断続的に失敗して再実行されるjob | どちらも解決しない | どちらも再実行を通常料金で課金する |

## どちらもやらないこと

両ベンダーとも、成功する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.

> Switching between managed runners is a one-line `runs-on` change in both directions, so a two-week trial on your slowest job costs almost nothing and beats any amount of modelling.

## 結論

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

## FAQ

### DepotとBlacksmithはどちらが安いですか?

どちらでもありません。2026-08-20時点で、両者が販売するすべてのサイズで公表Linux x64料金は同一です。2 vCPUで$0.004/min、4で$0.008、8で$0.016、16で$0.032です。公表料金で異なるのはLinux arm64だけで、Blacksmithは$0.0025/minを掲示し、DepotはARMの個別料金を公表していません。

### DepotとBlacksmithはどちらが速いですか?

jobの内容によります。Blacksmithはシングルスレッド PassMark 4484とされるベアメタルのゲーミングCPUを使うため、CPU律速の作業で速くなります。Depotは既定でRAMディスクをマウントし、ストレージ上限なしで最大1,000 MiB/sのcacheを提供するため、I/O律速の作業で速くなります。コンパイル中心のpipelineはBlacksmith、Dockerやcache中心のpipelineはDepotが有利です。

### どちらへの切り替え方は?

どちらもdrop-inです。GitHub Appをインストールし、workflowの `runs-on` labelを変更します。YAML、action、ステップはそれ以外そのままです。つまり離脱も同じくらい安く、どちらの選択もロックインになりません。

### DepotやBlacksmithは失敗したjobを自動で再試行しますか?

いいえ。どちらの製品にも一時的な失敗の自動検知と修復は含まれません。registryのタイムアウトや存在しないブラウザバイナリで失敗したjobは、どちらのプラットフォームでも失敗し、どちらでも課金され、人が再実行を押すのを待ちます。runner上での自動修復は、両者が空けたままにしているギャップです。

### それぞれの無料枠は?

Blacksmithは月3,000分の無料枠を公表しています。Depotは代わりに有料プランにminuteを束ねており、月$20のDeveloperプランからで、GitHub Actions 2,000分、Dockerビルド500分、cache 25 GBを含みます。

### 秒単位課金はなぜ重要ですか?

GitHub Actionsのmatrixは短いjobを多数生むからです。70秒かかるjobは、分単位の課金者には2分として、秒単位の課金者には70秒として請求されます。40 jobのmatrix全体では、同じ作業でおよそ15%の差になります。Depotは秒単位、Blacksmithは分単位で課金します。

### どちらかがGitHub Actionsの10 GB cache上限を解消しますか?

Depotは明示的にそうしています。cacheストレージは無制限で、プラン内包分を超えた分は$0.20/GB/月で課金されます。Blacksmithは同一ロケーションのcacheと任意のsticky diskを提供しますが、ストレージ上限の数値は公表していないため、大きなcacheを移行する前に自分のワーキングセットで確認してください。

### 両方を使えますか?

はい、大規模なmonorepoでは正解になり得ます。runnerの選択はjob単位なので、同じworkflowファイル内で異なる `runs-on` labelを使い、コンパイル中心のjobを一方に、Docker中心のjobを他方に向けられます。代償は2つのベンダー関係と2つの請求書です。

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt