Depot vs Blacksmith Docker cache for GitHub Actions builds

By Kaveh Alemi·Latchkey

The depot vs blacksmith docker cache question is really one about geography: Depot keeps your layers on a remote BuildKit builder with its own NVMe disk, and Blacksmith keeps them on a sticky disk that reattaches to the runner the job is already on. That decides the workflow edit, the cold-cache failure mode, and which line of the invoice the cache lands on.

Depot touches Docker builds in two separate products, and it matters which one you buy. Its GitHub Actions runners carry a RAM-disk accelerator and Depot Cache; its container builds are a different service, where an ephemeral EC2 builder runs an optimized BuildKit with a persistent NVMe layer cache, 50 GB by default and up to 500 GB, and builds amd64 and arm64 natively without emulation.

Blacksmith does one thing here: it gives BuildKit a disk that survives the job. useblacksmith/setup-docker-builder@v2 mounts a sticky disk keyed by the cache-key input its v2 README requires, one key per build target, and useblacksmith/build-push-action@v2 builds against it, so the cache lives beside the runner rather than in a cache service. There is no second product to buy.

Every cell below was read from the vendor's own public pricing or documentation page on 20 September 2026. Where a vendor does not publish a number, the cell says "not published" instead of carrying a guess.

Depot, Blacksmith and Latchkey side by side (read 20 September 2026)

The two cache models, and what each one costs you

A Docker layer cache is only useful if it is near the machine that reads it, and the two vendors solve that in opposite directions. Blacksmith moves the disk to the job: a sticky disk is an ext4 volume that reattaches to whichever runner takes the next run with the same cache key, so BuildKit sees a warm local filesystem. Depot moves the job to the disk: the build runs on a remote builder with NVMe attached, and your runner sends context and receives an image.

The consequences show up in three places. The edit: Blacksmith is two action swaps in the Docker job, Depot is a setup action plus a project id. The failure mode: a sticky disk idle for seven days is evicted and the next build is cold. And the bill, which both marketing pages skip.

Speed

Not benchmarked yet; the runner benchmark report will replace this section. We have not run the same workload on these runners ourselves, and until we have, there is no number here worth quoting.

The cheap way to get a real answer is to point one slow job at each candidate for a week, because runner selection is per job and the Actions run log gives you the timings for free.

Both vendors publish a claim, and both are marketing rather than measurement. Blacksmith's documentation says "Our customers have reported 2x to 40x improvements in build times" from Docker layer caching: a reported range, not a benchmark. Depot says its runners are "up to 3x faster than a GitHub-hosted runner" and its cache gives "10x faster caching". Neither names the workload, so neither transfers to your Dockerfile.

The number you can trust is your own cache hit rate: count how many layers say CACHED in the build log on a normal pull request. If most do, a faster cache is not your bottleneck and a cheaper runner minute is worth more. If none do, read buildx failed to reserve cache first, because a cache that is not being written is not a vendor problem.

Cost: the same month, then the cache on top

Start with the runner minutes, at the workload every comparison here uses: 10,000 Linux minutes at 2 vCPU plus 2,000 macOS minutes on a private repository.

On runner minutes Blacksmith is a third cheaper than Depot at both published Linux sizes, $0.004 against $0.006 at 2 vCPU and $0.008 against $0.012 at 4 vCPU, and it is the only one with a standing free tier. Depot charges exactly GitHub-hosted list price and sells more machine for it. Latchkey's own plan is $5 to $49 a month on top of that compute, and its 2,000 to 6,000 included minutes are not netted off, so the figure is gross on both counts.

Now the cache, where the two land in the same place by different routes. A 50 GB layer cache on Blacksmith is 50 GB of sticky disk at $0.50 per GB per month, which is $25 a month. The same 50 GB on Depot is the $20 Developer plan, which includes 25 GB, plus 25 GB of overage at $0.20 per GB per month, which is $5: $25 a month again. The shapes differ. Blacksmith scales linearly with the disk you keep; Depot is mostly a plan fee until you pass 25 GB.

If you use Depot's remote builders and not just its runners, there is a third meter. Build minutes are tracked by the second and billed separately: the $20 Developer plan includes 500 of them, overage is $0.04 a minute, and the Large builder consumes them at 2x, Extra Large at 4x. Two hundred builds a month at three minutes each is 600 build minutes, so 100 bill at $0.04, which is $4 on top of the plan. That is cheap until a build takes twenty minutes.

Reliability

Take uptime as unmeasured: no Actions SLA appears on either vendor's pages. What both do publish is enough to predict the bad days. Blacksmith states that the first Docker run is uncached and that a sticky disk idle for seven days is evicted, so a repository that builds weekly is permanently cold. Depot Cache is shared across branches rather than isolated per branch, which is faster and less strict than GitHub's scoping.

The failure neither addresses is the build that dies mechanically halfway through: a registry timeout, a rate limit on a base image pull, a disk full of layers. Those bill the minutes they burned, fail the job, and wait for a person to press re-run, which bills again. Docker Hub pull rate limit and registry mirror cover the two that hit Docker jobs hardest.

When to choose Depot

• You want the build off the runner. A remote builder with 16 vCPU and 32 GB means a 2 vCPU runner can drive a large build, which is the opposite of the usual "buy a bigger runner" answer.
• You build amd64 and arm64 from one workflow and are tired of QEMU. Depot builds both natively on the builder rather than emulating one of them.
• Your cache is large and you would rather pay for it by the gigabyte past a plan allowance than manage disks and their idle eviction.
• Your jobs are short and numerous, because per-second tracking with no one-minute minimum removes rounding that a lower rate does not.
• One caveat before you commit: Depot documents that its Windows runners have no Hyper-V on EC2, so Docker on Windows is unlikely to work there.

When to choose Blacksmith

• You want the lowest runner rate of the two: $0.004 against $0.006 at 2 vCPU, with 3,000 free minutes a month on top.
• You want the smallest possible change. Two action swaps inside the Docker job, and the build still runs where it ran before.
• Your Docker job also does other work, such as tests against the image it just built, and you would rather keep that on one machine than split it across a runner and a builder.
• You want the cache and the runner from one vendor, on one invoice, with no separate build-minute meter to model.
• Note the trade you are accepting: a sticky disk is per cache key with five disks per job, so a repository that builds many distinct images needs its keys planned rather than pasted.

Switching: the exact diff

Both start with a runs-on change, and each wants two more lines in the Docker job. Blacksmith keeps the build local and swaps the builder underneath it; Depot installs the CLI and replaces the build action, after which the build leaves the runner. Runner selection is per job, so point one Docker job at each for two weeks and compare real numbers instead of vendor claims.

 jobs:
   image:
-    runs-on: ubuntu-latest
+    runs-on: blacksmith-4vcpu-ubuntu-2404
     steps:
       - uses: actions/checkout@v7
+      - uses: useblacksmith/setup-docker-builder@v2
+        with:
+          cache-key: docker/Dockerfile
-      - uses: docker/build-push-action@v7
+      - uses: useblacksmith/build-push-action@v2
         with:
           context: .

   image-on-depot:
-    runs-on: ubuntu-latest
+    runs-on: depot-ubuntu-24.04-4
     permissions:
       contents: read
       id-token: write
     steps:
       - uses: actions/checkout@v7
+      - uses: depot/setup-action@v1
-      - uses: docker/build-push-action@v7
+      - uses: depot/build-push-action@v1
         with:
+          project: your-depot-project-id
           context: .

The verdict

For most teams the honest answer is Blacksmith, because the change is smaller, the runner rate is a third lower, and a warm local disk is a good enough cache for a Dockerfile that has not been split across a dozen images. Depot is the better buy when the build itself has outgrown the runner: native multi-architecture images, a layer cache measured in hundreds of gigabytes, or a build you want executed on a 16 vCPU machine while the job that drives it stays on a cheap one. The two cache bills land in the same place at 50 GB, $25 a month either way, so cost is not the deciding axis at that size and architecture is. What neither does is notice that the build failed because a registry timed out at minute nine, repair it, and carry on, which on a Docker-heavy pipeline is the line item that grows quietest.

Frequently asked questions

Related guides

References

• Blacksmith Docker layer caching with sticky disks
• Blacksmith pricing
• Depot container builds: builders, cache and sizes
• Depot GitHub Actions runner types and per-minute prices
• Depot container builds in GitHub Actions
• Docker documentation
• Docker build cache
• GitHub Actions documentation