# Buildkite vs Depot for Docker Builds

> Buildkite vs Depot for container builds: a full CI platform against a build-acceleration product. Published rates, cache behaviour, and which one your Docker bottleneck actually needs.

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

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.

## Comparison

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

```Terminal
# 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 problem
```

> On most CI providers each job starts with no layer cache, so every build is effectively the cold number. That is the gap Depot is built to close, and no amount of extra vCPU closes it.

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

```workflow.yml
jobs:
  build:
    runs-on: ubuntu-latest        # GitHub-hosted
    # runs-on: latchkey-small     # Latchkey
```

> Runner selection is per job, so you do not have to migrate a pipeline to test one. Point the most expensive job at a candidate, compare two weeks of real runs, and expand only if the numbers hold.

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

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

## FAQ

### Buildkite vs Depot for Docker Builds?

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.

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

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

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

### Which should I choose?

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.

---

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