Skip to content
Latchkey

Depot vs GitHub-Hosted Runners: What You Actually Gain

Depot is $0.004/min against GitHub-hosted list of $0.006, but the rate is the least interesting difference. Uncapped cache, RAM disks, and per-second billing are what change your bill.

Depot runs each GitHub Actions job on a single-tenant EC2 instance with a RAM disk mounted by default, backed by a cache tier rated to 1,000 MiB/s with no storage cap. It is a drop-in: install the app, change runs-on, keep your workflows.

The per-minute saving against GitHub-hosted is real but modest. The differences that actually move a bill are structural: GitHub caps Actions cache at 10 GB per repository and rounds every job up to the nearest minute, and Depot does neither.

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.

Published figures, private repository, Linux

GitHub-hostedDepot
2 vCPU$0.006/min$0.004/min
4 vCPU$0.012/min$0.008/min
8 vCPU$0.022/min$0.016/min
16 vCPU$0.042/min$0.032/min
Cache storage10 GB per repository, hard capUnlimited, $0.20/GB/month overage
Cache throughputNot publishedUp to 1,000 MiB/s both ways
DiskStandard SSD, ~14 GB freeRAM disk by default, cited 3x faster
Billing granularityRounded up per minutePer second
ConcurrencyLimited by planNo published cap
IsolationFresh VM per jobSingle-tenant EC2 per job
Automatic failure recoveryNoNo

Per-second billing is not a rounding detail

GitHub rounds every job up to the nearest minute. A matrix of short jobs pays a large fraction of its bill for time it did not use, and the effect grows with matrix width rather than with job length.

MatrixReal time per jobBilled on GitHub-hostedBilled per second
20 jobs40 s20 min13.3 min
40 jobs70 s80 min46.7 min
60 jobs25 s60 min25 min

The 10 GB cache cap is the other structural difference

GitHub caps Actions cache at 10 GB per repository and evicts least-recently-used entries past it. A monorepo with several toolchains exceeds that easily, and the failure mode is silent: caches stop persisting and builds simply get slower with no error to investigate.

  • Entries not read for 7 days are evicted regardless of the cap, so infrequently-run workflows never have a warm cache.
  • Caches are branch-scoped, so a feature branch cannot use another feature branch cache.
  • Depot removes the cap and bills storage instead, which turns a silent performance cliff into a line item you can see.

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

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.

The verdict

Public repository: stay on GitHub-hosted. Free and unlimited, on a bigger machine than private repos get.

Private repo with a wide matrix of short jobs: Depot, largely for per-second billing. The rate difference is secondary to no longer paying for rounding.

Private repo hitting the 10 GB cache ceiling: Depot, decisively. That cap has no workaround on GitHub-hosted and its symptoms are invisible.

Private repo with a handful of long jobs and a small cache: the difference is roughly a 33% rate saving and little else. Real, but not urgent.

Frequently asked questions

Depot vs GitHub-Hosted Runners: What You Actually Gain?
Depot runs each GitHub Actions job on a single-tenant EC2 instance with a RAM disk mounted by default, backed by a cache tier rated to 1,000 MiB/s with no storage cap. It is a drop-in: install the app, change runs-on, keep your workflows.
Per-second billing is not a rounding detail?
GitHub rounds every job up to the nearest minute. A matrix of short jobs pays a large fraction of its bill for time it did not use, and the effect grows with matrix width rather than with job length.
The 10 GB cache cap is the other structural difference?
GitHub caps Actions cache at 10 GB per repository and evicts least-recently-used entries past it. A monorepo with several toolchains exceeds that easily, and the failure mode is silent: caches stop persisting and builds simply get slower with no error to investigate.
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?
Public repository: stay on GitHub-hosted. Free and unlimited, on a bigger machine than private repos get.

Related guides

References

Latchkey runs the same jobs at $0.0025/min against $0.004/min, and repairs transient failures. Start free → 30-day trial · No credit card