# Depot vs GitHub-Hosted Runners: What You Actually Gain

> Depot vs GitHub-hosted runners on published rates, cache limits, and billing granularity. Depot lifts the 10 GB cache cap and bills per second; here is when that is worth it.

Source: https://latchkey.dev/learn/compare-runners/depot-vs-github-hosted  
Updated: 2026-08-20

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.

## Comparison

|  | GitHub-hosted | Depot |
| --- | --- | --- |
| 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 storage | 10 GB per repository, hard cap | Unlimited, $0.20/GB/month overage |
| Cache throughput | Not published | Up to 1,000 MiB/s both ways |
| Disk | Standard SSD, ~14 GB free | RAM disk by default, cited 3x faster |
| Billing granularity | Rounded up per minute | Per second |
| Concurrency | Limited by plan | No published cap |
| Isolation | Fresh VM per job | Single-tenant EC2 per job |
| Automatic failure recovery | No | No |

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

| Matrix | Real time per job | Billed on GitHub-hosted | Billed per second |
| --- | --- | --- | --- |
| 20 jobs | 40 s | 20 min | 13.3 min |
| 40 jobs | 70 s | 80 min | 46.7 min |
| 60 jobs | 25 s | 60 min | 25 min |

> The shorter and more numerous your jobs, the more the rounding costs. A wide lint or unit-test matrix is the worst case and also the most common one.

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

> Runner selection is per job, so you do not have to migrate a pipeline to test one. Point the most expensive job at a candidate, compare two weeks of real runs, and expand only if the numbers hold.

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

> Switching between managed runners is a one-line `runs-on` change in both directions, so a two-week trial on your slowest job costs almost nothing and beats any amount of modelling.

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

## FAQ

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

---

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