TL;DR:

  • Depot provides remote Docker build infrastructure with persistent layer caching and native ARM64 builds, replacing slow local or ephemeral CI runners
  • Most teams see 3–5x Docker build time reduction with a two-line config change and no Dockerfile rewrites
  • Pricing is compute-based ($0.003/CPU-minute), making it cost-neutral or cheaper than many CI setups once build time is factored in

If your CI pipeline takes 15 minutes and 10 of those are the Docker build step, you’ve probably already tried multi-stage builds, layer ordering optimisation, and BuildKit. Those all help. But if you’re still rebuilding the same dependency layers every run because your CI runners are ephemeral, you’re hitting a ceiling that better Dockerfile structure can’t fix.

Depot solves this from the infrastructure side rather than the Dockerfile side.

What Depot Is

Depot is a managed build service. Instead of running docker build (or docker buildx build) on your CI runner, you point the build at Depot’s infrastructure. Your CI runner becomes an orchestrator that sends the build context to Depot, where the actual build happens on fast hardware with a persistent cache that survives across runs.

The key difference from a normal CI cache: Docker layer caches on standard CI are typically stored as tarballs in S3 or GCS, then downloaded and loaded at the start of each run. This adds 30–90 seconds of cache restore time even when the cache is fresh. Depot’s remote build infrastructure keeps the cache in memory and on fast NVMe, so cache hits are actually fast rather than “slower than rebuilding.”

What You Get

Persistent build cache. Your layer cache persists between runs in Depot’s infrastructure. A dependency installation step that changes monthly gets cached once and stays cached. No more rebuilding node_modules or pip installs because the CI runner spun up fresh.

Native multi-arch builds. If you need to build for both AMD64 and ARM64 (increasingly common now that ARM-based servers are mainstream), Depot runs native emulators for each architecture rather than using QEMU emulation. Native ARM64 builds on Depot run at full speed; QEMU-emulated ARM64 builds in standard CI can be 5–10x slower than native.

Faster hardware. Depot’s build machines use high-core-count CPUs with fast NVMe. For CPU-bound compilation steps, the raw hardware advantage helps independent of caching.

Concurrent layer builds. BuildKit already supports parallel layer building. Depot extends this with infrastructure that can execute across multiple machines for large multi-stage builds — though most single-image builds don’t need this.

Setting It Up

Installation is genuinely two commands. For GitHub Actions:

# In your .github/workflows/build.yml

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      # Add Depot
      - uses: depot/setup-action@v1
      
      - name: Build and push
        uses: depot/build-push-action@v1
        with:
          project: your-project-id
          context: .
          push: true
          tags: your-image:latest

The depot/build-push-action is a drop-in replacement for docker/build-push-action. Same inputs, same outputs. You add your DEPOT_TOKEN as a GitHub secret and a project ID from the Depot dashboard. That’s it.

For teams using docker buildx build directly in scripts:

# Install the Depot CLI
curl -L https://depot.dev/install-cli.sh | sh

# Replace docker buildx build with depot build
depot build --project your-project-id -t your-image:latest .

No Dockerfile changes. No new build patterns to learn.

Real-World Numbers

Depot publishes case studies with specific timing data, and independent reports on Twitter/X from engineering teams are consistent. Common patterns:

  • A React/Node application with a standard multi-stage build going from 12 minutes cold to 2.5 minutes warm after Depot (first run is still the full build; subsequent runs hit cache)
  • A Python ML service with heavy pip installs going from 8 minutes to 90 seconds warm
  • A monorepo with 5 services that previously built sequentially in 35 minutes now building in 8 minutes with Depot’s parallel build support

The first-run improvement comes from hardware speed. The repeat-run improvement (the bigger number) comes from persistent cache.

Where Depot Fits in Your Stack

Depot is not a CI platform — it’s a Docker build accelerator. It works alongside whatever CI system you use: GitHub Actions, GitLab CI, CircleCI, Buildkite, Jenkins, or a plain bash script. You don’t migrate your CI; you add Depot as the build execution layer.

If you use Docker Compose for local development and a Dockerfile for production, Depot only touches the CI build step. Local builds are unaffected (though you can use Depot CLI locally if you want shared cache with CI).

Depot is also not a container registry. You still push to ECR, GHCR, Docker Hub, or wherever you currently push. Depot builds the image; you push it where you want.

Pricing

Depot bills per CPU-minute of build time: $0.003/CPU-minute on their standard builders (currently 16-core machines). Storage for cache is $0.20/GB-month.

A 2-minute build on a 16-core machine costs $0.096. A team running 200 such builds per day pays around $19/day or $580/month. For comparison, 200 builds taking 10 minutes each on GitHub Actions’ larger runners (which cost around $0.016/minute for 4-core) would cost $320/day. The comparison depends heavily on your current CI setup, but for teams where the builds are CPU-bound and cache misses are expensive, Depot is often cost-neutral while being significantly faster.

There’s a free tier: 500 build minutes/month. That’s enough to evaluate it with a real project before committing.

Who Should Look at This

If your Docker builds are taking more than 5 minutes in CI and you’ve already done the standard optimisations (multi-stage builds, layer ordering, BuildKit enabled), Depot is worth a trial. The setup time is under an hour including waiting for a few test builds to confirm the improvement.

If you’re building multi-arch images and currently using QEMU emulation for ARM64, this is the most impactful single change you can make — native ARM64 builds are reliably 3–8x faster than QEMU depending on the workload.

If your builds are already under 3 minutes and cache is working well, the marginal gain is smaller. Depot is a better fit for teams feeling the cost of slow builds — in developer waiting time, CI queue length, or deploy latency.