Buildkite vs Depot for Docker Builds
Depot started as Docker build acceleration and the runner product inherits that: RAM disks by default and an uncapped cache at 1,000 MiB/s. Buildkite is a CI platform that happens to run containers.
If your Docker builds are slow, these two solve it at different layers. Depot attacks the build itself: persistent build cache, RAM disk mounted by default, and a remote builder that keeps layer cache warm between runs rather than rebuilding it per job. Buildkite gives you a platform and agents, and leaves the Docker build performance question to you.
That distinction matters because a slow container build is usually a cache problem, not a compute problem. Moving a cold-cache Docker build to a faster machine makes it somewhat faster; giving it a warm persistent layer cache makes it dramatically faster.
Standard GitHub-hosted runners are free and unlimited on public repositories, and public repos get 4 vCPU and 16 GB rather than the 2 vCPU and 8 GB private repositories receive. No paid runner beats free, so everything below assumes a private repository past its included minutes.
Buildkite vs Depot at a glance
| Buildkite | Depot | |
|---|---|---|
| Primary product | CI platform and agents | Build acceleration, plus GH Actions runners |
| Docker layer cache | Whatever you configure yourself | Persistent, uncapped, up to 1,000 MiB/s |
| Disk | Standard agent disk | RAM disk by default, cited 3x faster access |
| Compute price (Linux) | $0.004 per vCPU-minute | $0.004/min at 2 vCPU, $0.008 at 4 |
| Billing granularity | Per vCPU-minute | Per second |
| Seat cost | $30 per active user/month on Pro, $3.50 per agent | Plans from $20/month |
| Keeps GitHub Actions? | No, it replaces it | Yes |
| Isolation | Agent model, yours or hosted | Single-tenant EC2 instance per job |
Find out whether your build is cache-bound first
This decision is cheap to make correctly, because the measurement takes one run. If most of your build time is spent re-executing layers that did not change, the cache is your bottleneck and a faster machine is the wrong purchase.
# how long with a completely cold cache?
docker build --no-cache --progress=plain -t app . 2>&1 | tail -5
# and with a warm one?
docker build --progress=plain -t app . 2>&1 | tail -5
# if those two numbers are close, your cache is not being reused between
# CI runs at all, which is the single most common container-build problemThe cost comparison is dominated by seats, not minutes
Buildkite Pro is $30 per active user per month plus $3.50 per agent per month, before compute. Depot plans start at $20/month total. On a team of fifteen the difference is roughly $450/month in fixed cost, which will usually exceed the entire compute line for a mid-sized pipeline.
- Buildkite hosted Linux compute is billed per vCPU-minute, so a 4 vCPU agent is $0.016/min, not $0.004.
- Depot bills per second rather than rounding to the minute, which matters across a wide matrix of short jobs.
- Depot cache storage is uncapped, with overage at $0.20/GB/month beyond plan inclusions.
Switching, and switching back
Every managed runner in this category is selected by the runs-on label, so adoption and reversal are the same one-line edit. That makes a two-week trial on your slowest job a better decision procedure than any amount of modelling.
jobs:
build:
runs-on: ubuntu-latest # GitHub-hosted
# runs-on: latchkey-small # Latchkey
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
Container builds are your bottleneck and GitHub Actions is otherwise fine: Depot. The persistent uncapped layer cache and RAM disk target exactly that problem, adoption is a runs-on change, and per-second billing helps on wide matrices.
You need a different orchestrator, or agents inside your own network: Buildkite. It is a platform decision, not a build-performance one, and should be justified on platform grounds.
Measure the cold-versus-warm gap before choosing either. If those two numbers are close, no runner upgrade will help you as much as fixing cache reuse.