Migrate from Depot runners without losing the cache

By Kaveh Alemi·Latchkey

Teams that migrate from Depot runners in 2026 are usually reacting to one number: Depot lists its GitHub Actions runners at $0.006 a minute, which is GitHub-hosted list price to the cent. The move itself is a label per job, and the two things that do not move with it are the remote BuildKit builders and a cache that behaves differently from every other cache in this market.

Start with what you are giving up, because it is specific and some of it is unusual. Depot tracks usage by the second and bills whole minutes at the end of the month, with no one-minute minimum, so a wide matrix of short jobs does not pay for rounding. Its runner documentation publishes 100 GB of disk on the smallest Linux runner, rising to 250 GB, with a slice of memory reserved as a RAM-disk accelerator in front of it. It publishes no concurrency limit, no cache size limit and no network limit.

And its cache is not isolated by branch: its documentation says entries from main and from other branches share one namespace, scoped by repository. That is the opposite of actions/cache, where an entry is restorable only from the branch that wrote it or from the default branch. It is the single change most likely to make a migrated pipeline slower without any error appearing.

The alternatives and their rates are in Depot alternatives. This page is the cutover: the label map, the cache work, and the arithmetic for whether per-second tracking was worth the rate.

The label map, with the disk in it

Depot labels carry the Ubuntu version and a vCPU suffix, so depot-ubuntu-22.04-4 is a 4 vCPU runner on 22.04. Sizes match Latchkey up to 16 vCPU and the memory matches at every step; the disk does not. Depot publishes 100 GB at 2 vCPU and 130 GB at 4, while a Latchkey runner reports 43 GB free, measured on 2026-09-20 and quoted in migrate from Blacksmith.

The pre-flight checklist

Seven items. The cache ones are the two that decide whether this migration feels neutral or feels like a regression.

• Labels. Grep the workflow directory for runs-on:.*depot- to find every job, including the Windows and macOS ones you may not be able to move.
• Depot actions. Grep for depot/. The build actions and the CLI talk to Depot builders and have no meaning on another runner.
• Cache scope. List the jobs that restore a cache written by another branch. On Depot that works; on actions/cache it does not, and those jobs will start cold on every feature branch.
• Cache size. Depot sells 25 GB on its $20 Developer plan and 250 GB on Startup. GitHub gives 10 GB per repository with 7-day eviction, Latchkey 25 GB per repository. If you are above 25 GB, decide what stops being cached before the first run tells you.
• Secrets. Nothing to move unless something was configured on the Depot organization rather than in repository secrets.
• Matrix and concurrency. Depot publishes no concurrency limit. GitHub-hosted is 20 to 500 concurrent jobs by plan, and a matrix that ran flat out may now queue.
• Artifacts. Unchanged; actions/upload-artifact is a GitHub feature and is unaffected by the runner.

The before and after

One line for the runner, and a real cache step for the work the Depot cache was doing without being asked.

jobs:
  build:
    # before
    # runs-on: depot-ubuntu-24.04-4
    # after
    runs-on: latchkey-medium
    steps:
      - uses: actions/checkout@v5
      - uses: actions/cache@v4
        with:
          path: ~/.cache/go-build
          key: go-${{ hashFiles('**/go.sum') }}
          restore-keys: |
            go-
      - run: go build ./... && go test ./...

Docker builds are the real migration

Depot runs BuildKit builders next to the runner and keeps their state warm, which is a different product from a layer cache you export. Off Depot you are exporting again: cache-from and cache-to against a registry or the Actions cache backend, uploading and downloading the blob on every build. For a Dockerfile with a heavy dependency stage that is slower, and the honest answer for a pipeline dominated by image builds is that Depot is the better tool and the rate is what it costs.

For everyone else the layer cache on the runner is enough, and the failure modes are the ordinary ones: a buildx cache reservation error when the backend is unhappy, or a Docker Hub rate limit once every job starts pulling base images again rather than finding them warm.

Was the per-second tracking worth the rate?

This is arithmetic, not opinion. Depot bills the seconds your jobs actually ran, totalled into whole minutes monthly. A per-minute vendor rounds each job up on its own. At $0.006 against $0.0025 the rate gap is 58%, so rounding has to inflate your billed minutes by more than 2.4 times before Depot comes out ahead, which happens only when a job is shorter than 25 seconds.

Worked on 1,000 jobs: at 15 seconds each, Depot bills 250 minutes for $1.50 and a per-minute vendor bills 1,000 for $2.50. At 25 seconds they are level at $2.50. At 40 seconds it is $4.00 against $2.50, at 70 seconds $7.00 against $5.00, and at 3 minutes $18.00 against $7.50. Plan fees sit outside all of those: Depot's Developer plan is $20 a month and Latchkey's starts at $5, and neither plan's included minutes are netted off above.

When staying on Depot is right

Four cases. Docker builds are most of your minutes, and the remote builders do work no layer cache matches. Your cache is bigger than 25 GB, or you depend on entries written on one branch being read on another. Your jobs are shorter than about 25 seconds, where per-second tracking beats a cheaper rounded minute. Or you need arm64, Windows, macOS, GPU, or sizes above 16 vCPU, none of which Latchkey has.

What moving buys, if none of those holds: $0.0025 a minute for 2 vCPU with 8 GB against $0.006, 25 GB of cache per repository, and a transient failure diagnosed and retried inside the run instead of billing the failure and the re-run. What it costs: the disk drops from 100 GB to 43, the builders go away, and the cache starts obeying branch scope.

The short answer

Move the Linux jobs that are not Docker-bound, keep the rest on Depot for now, and do it one job at a time. The rate saving is 58% on every size up to 16 vCPU, and it is real only if the cache work above is done properly rather than discovered through timings.

Stay whole if image builds are the pipeline. At $0.006 the minute is no longer the argument for Depot, but the builders, the 250 GB cache and the per-second tracking still are, and a migration that ignores them trades a rate cut for a slower build.

Frequently asked questions

Related guides

References

• Depot runner types: every label with CPUs, memory, disk and per-minute price (verified 2026-09-20)
• Depot GitHub Actions runners: per-second tracking, cache scope and organization requirement (verified 2026-09-20)
• Depot pricing: plan fees, included minutes and cache storage (verified 2026-09-20)
• GitHub Actions dependency caching: 10 GB per repository, eviction and branch scope (verified 2026-09-20)
• Latchkey pricing: runner sizes, rates and included minutes (verified 2026-09-20)
• GitHub Actions documentation