Depot vs Blacksmith: Managed GitHub Actions Runners Compared

By Daniel Zoghalchali·Latchkey

Depot and Blacksmith charge the same per minute at every comparable runner size. The real choice is architectural: Blacksmith optimizes single-core wall-clock, Depot optimizes disk and cache throughput.

Depot and Blacksmith are the two managed GitHub Actions runner providers teams shortlist most often, and almost every comparison of them leads with price. That is the one thing that will not decide it. As of 2026-08-20 their published Linux x64 rates are identical at every size that both sell: $0.004/min at 2 vCPU, $0.008 at 4 vCPU, $0.016 at 8 vCPU, and $0.032 at 16 vCPU. You cannot pick between them on the rate card.

What actually differs is the machine underneath and what it is tuned for. Blacksmith runs jobs on bare-metal gaming CPUs inside Firecracker microVMs, chasing the highest single-thread performance available in the category. Depot runs each job on a single-tenant EC2 instance with a RAM disk mounted by default and a cache tier rated to 1,000 MiB/s, chasing I/O throughput. Those are different bets, and which one pays off depends entirely on where your pipeline spends its minutes.

This page compares them on published, dated figures, then gives you a way to measure which bottleneck you have before you commit. Every price and claim below is sourced from the vendor pricing or product pages and was verified on 2026-08-20.

Depot vs Blacksmith at a glance

They cost the same, so price cannot decide it

Set the two rate cards side by side and the Linux x64 columns match exactly. This is not a coincidence: both vendors anchor to the same competitive reference point, and both undercut GitHub-hosted, which lists Linux 2-core x64 at $0.006/min as of 2026-08-20.

Blacksmith: buy single-core speed

Blacksmith runs on bare-metal consumer-grade gaming CPUs rather than the server parts most clouds rent. The point is clock speed and single-thread throughput: Blacksmith cites a single-thread PassMark score of 4484, which the independent RunsOn benchmark ranks highest among managed GitHub Actions runner providers. Jobs boot into an ephemeral Firecracker microVM in under three seconds.

• 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.

Depot: buy I/O and billing precision

Depot came to runners from Docker build acceleration, and the runner product carries that heritage. Each job gets a single-tenant EC2 instance with a RAM disk mounted by default, which Depot rates at 3x faster disk access than the standard runner filesystem. Cache storage is unlimited rather than capped, and rated to 1,000 MiB/s in both directions.

• 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.

Which bottleneck do you actually have?

The honest answer is that most teams do not know, and pick on brand impression. You can find out in one job. Add this step to a representative workflow on your current runners and read the split between CPU time and wall-clock time.

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

The decision rule

Once you know the split, the choice is mechanical.

What neither of them does

Both vendors compete on making a successful job finish sooner. Neither changes what happens when a job fails for a reason that has nothing to do with your code: a registry timeout, a flaky network mount, a transient dependency resolution failure, a browser binary that did not install. On both platforms that job fails, a human notices, and someone clicks re-run. You pay for the failed minutes and the replacement minutes, and the merge waits on a person being awake.

• The failed run is billed. So is the re-run. Neither vendor discounts a transient failure.
• The wall-clock cost is not the runner minutes, it is the gap between the failure and the human who noticed it.
• Flake rate is independent of runner speed. A 2x faster runner fails just as often, only sooner.

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

Do not choose on price, because there is no price difference to choose on. At every Linux x64 size both vendors publish the same rate, and both undercut GitHub-hosted list price by the same margin.

Choose Blacksmith if your critical path is a single core working hard: compilation, bundling, a single-threaded test runner, or ARM64 builds where its published $0.0025/min rate has no Depot equivalent. Choose Depot if your critical path is I/O: large Docker layers, big cache restores against the 10 GB GitHub ceiling, or a wide matrix of short jobs where per-second billing stops the rounding tax.

Measure first. The step above tells you which you are in a single run, and it is the difference between a decision and a guess.

Frequently asked questions

Related guides

References

• Depot pricing (verified 2026-08-20)
• Depot GitHub Actions runners (verified 2026-08-20)
• Blacksmith pricing (verified 2026-08-20)
• GitHub Actions larger runner per-minute rates (verified 2026-08-20)
• GitHub Actions documentation