# Migrate from Depot runners without losing the cache

> Migrate from Depot runners to another GitHub Actions runner: the label map, what the branch-shared cache does next, and the job length where it pays.

Source: https://latchkey.dev/learn/runners/migrate-from-depot  
Updated: 2026-09-20

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](/learn/runners/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](/learn/runners/migrate-from-blacksmith).

| Depot label | What it is | Closest Latchkey label | What changes |
| --- | --- | --- | --- |
| `depot-ubuntu-24.04` | 2 vCPU, 8 GB, 100 GB disk | `latchkey-small` | 58% cheaper a minute, 43 GB of disk, no RAM-disk accelerator |
| `depot-ubuntu-22.04-4` | 4 vCPU, 16 GB, 130 GB disk | `latchkey-medium` | Same cores, 15.3 GB usable measured, a third of the disk |
| `depot-ubuntu-24.04-8` | 8 vCPU, 32 GB, 150 GB disk | `latchkey-large` | Same cores and memory, 43 GB of disk |
| `depot-ubuntu-24.04-16` | 16 vCPU, 64 GB, 180 GB disk | `latchkey-xlarge` | The largest size Latchkey publishes |
| `depot-ubuntu-24.04-32` and `-64` | 32 or 64 vCPU, 128 or 256 GB | None | No equivalent; these jobs stay on Depot or go to Blacksmith at 32 |
| `depot-ubuntu-24.04-arm` and `depot-windows-2025` | Graviton4 arm64, or Windows | None | Linux x86_64 only on the other side, so these stay put |
| `depot-macos-latest` | 8 CPU, 24 GB, 400 GB disk | None | No macOS runner at any price; the destinations are priced separately |

> One constraint is identical on both sides and catches personal accounts: Depot requires the repository to be owned by a GitHub organization, and so does Latchkey. Ubicloud, Blacksmith and Namespace each have their own connection step, listed in the roundup.

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

```.github/workflows/ci.yml
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 ./...
```

> The `restore-keys` line is the part worth adding deliberately. On Depot a branch could read an entry written on `main` because the namespace is shared; with `actions/cache` a feature branch falls back to the default branch only through a prefix match, so without a prefix key a new branch starts cold every time.

## 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](/learn/failures/buildx-failed-to-reserve-cache-gha) when the backend is unhappy, or [a Docker Hub rate limit](/learn/failures/docker-hub-pull-rate-limit-in-ci) 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.

## FAQ

### How does Depot speed up Docker builds in CI?

By running BuildKit builders beside the runner and keeping their state warm, rather than exporting a layer cache to a registry on every build. Its documentation also publishes cache throughput up to 1,000 MiB/s on 12.5 Gbps of network. That is the part a `runs-on` change does not carry with it: off Depot, the builder starts empty and imports a cache each run.

### Will my cache keys still work after leaving Depot?

The keys yes, the behavior no. Depot documents that its cache is not isolated by branch, so entries written on `main` are readable from any branch of the same repository. `actions/cache` restores only from the writing branch or the default branch, so add `restore-keys` prefixes before you move, or every new branch begins with a cold cache.

### Does per-second billing make Depot cheaper for short jobs?

Below about 25 seconds a job, yes. Depot tracks by the second and bills whole minutes monthly, where a per-minute vendor rounds each job up individually. Against a rate 58% lower, rounding has to more than double your billed minutes to matter, which needs jobs shorter than 25 seconds. Above that the cheaper rate wins, and by 3 minutes a job it wins by more than two to one.

### What is the Latchkey equivalent of depot-ubuntu-24.04-4?

`latchkey-medium`, which is 4 vCPU with 16 GB against Depot's 4 vCPU with 16 GB, at $0.005 a minute against $0.012. A real run on 2026-09-20 reported 15,617 MB of memory and 43 GB of free disk, against the 130 GB of disk Depot publishes for that label, so a job that writes a large scratch directory is the one to check first.

## References

- [Depot runner types: every label with CPUs, memory, disk and per-minute price (verified 2026-09-20)](https://depot.dev/docs/github-actions/runner-types)
- [Depot GitHub Actions runners: per-second tracking, cache scope and organization requirement (verified 2026-09-20)](https://depot.dev/docs/github-actions/overview)
- [Depot pricing: plan fees, included minutes and cache storage (verified 2026-09-20)](https://depot.dev/pricing)
- [GitHub Actions dependency caching: 10 GB per repository, eviction and branch scope (verified 2026-09-20)](https://docs.github.com/en/actions/reference/dependency-caching-reference)
- [Latchkey pricing: runner sizes, rates and included minutes (verified 2026-09-20)](https://latchkey.dev/pricing)

---

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