Migrate from Depot Runners Without Losing Cache

DEV Community

Migrate from Depot runners without losing the cache

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. The cost of 1,000 jobs at five job lengths, at the rates published on 2026-09-20. Per-second tracking wins below about 25 seconds a job and loses above it. 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. 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 publishes no size and keeps entries 14 days. If you are above your destination's allowance, decide what stops being cached ...

Powered by Readybot.io*