# Depot vs GitHub Actions hosted runners

> Depot vs GitHub Actions hosted runners: identical published rates, very different machines. What the same $0.006 a minute actually buys.

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

Depot vs GitHub Actions hosted runners is not a price comparison: Depot charges $0.006 a minute for a 2 vCPU Linux runner, which is GitHub-hosted list price to the cent. You choose Depot for what the same money buys, which is seven times the disk, a RAM-disk accelerator and per-second metering, and you stay on GitHub-hosted if your repositories are public or your minutes fit inside the free allowance.

GitHub-hosted runners come with the platform: nothing to install, an included monthly allowance, and a standard private-repo Linux machine of 2 vCPU, 8 GB of RAM and 14 GB of disk. On public repositories they are free and unlimited, and the free machine is 4 vCPU with 16 GB.

Depot sells ephemeral EC2 runners you adopt with a `runs-on` change. At the same published rate it hands you 100 GB of disk instead of 14 GB, a RAM disk in front of it, and a bill metered to the second rather than rounded up to the minute. It is aimed at teams whose CI is I/O-bound or made of hundreds of short jobs.

Every cell below was read from the vendor's own public pricing or documentation page on 20 September 2026. Where a vendor does not publish a number, the cell says "not published" instead of carrying a guess.

## Comparison

|  | GitHub-hosted | Depot | Latchkey |
| --- | --- | --- | --- |
| Price per minute, 2 vCPU Linux x64 | $0.006 (2 vCPU, 8 GB RAM, 14 GB SSD on a private repo; free on public repos) | $0.006 (2 vCPU, 8 GB RAM, 100 GB disk, 2 GB RAM disk) | **$0.0025** (2 vCPU, 8 GB RAM, 100 GB disk) |
| Price per minute, 4 vCPU Linux x64 | $0.012 as a larger runner; the free public-repo standard runner is already 4 vCPU and 16 GB | $0.012 (4 vCPU, 16 GB RAM, 130 GB disk, 4 GB RAM disk) | **$0.005** (4 vCPU, 16 GB RAM, 100 GB disk) |
| Free tier | 2,000 minutes a month on Free, 3,000 on Team, 50,000 on Enterprise Cloud, private repos only | None standalone: 2,000 minutes with the $20/month Developer plan, 20,000 with the $200/month Startup plan | 30-day trial, then 2,000 included minutes a month on Developer, 4,000 on Launch, 6,000 on Scale |
| Billing granularity | Every job is rounded up to the nearest whole minute | Per-second usage tracking, with whole minutes billed at the end of the month and no one-minute minimum | Per minute |
| Runner sizes and OS | Linux x64 and arm64, Windows x64 and arm64, macOS on M-series and Intel; larger runners to 96 vCPU x64 | 2 to 64 vCPU on Linux x64 and arm64 (Graviton4); Windows Server 2022 and 2025 at 2 to 64 vCPU, with no Hyper-V; macOS at 8 vCPU | 2, 4, 8 and 16 vCPU, Ubuntu 24.04 on x86_64 only. arm64, Windows and macOS are not offered |
| Cache: type, limit, persistence | `actions/cache`, 10 GB per repository, entries removed after 7 days without access, restorable only from the same or the default branch | Depot Cache, 25 GB included on Developer and 250 GB on Startup, then $0.20/GB/month; entries are shared across branches rather than isolated | Size not published. `latchkey-dev/cache-action@v1` swaps one line for `actions/cache`, keeping `path`, `key` and `restore-keys`; entries are isolated per organization, versioned by OS, kept 14 days; a failed restore warns rather than failing the job |
| Docker build acceleration | None built in. `cache-to: type=gha` writes into the same 10 GB store | A RAM-disk accelerator on every runner, 2 GB at 2 vCPU rising to 32 GB at 64 vCPU; remote container builds are a separate Depot product | `latchkey-dev/docker-cache-action@v1`, layers held in a Latchkey-managed private registry per organization |
| Concurrency limits | 20 concurrent jobs on Free, 40 on Pro, 60 on Team, 500 on Enterprise Cloud. macOS is capped separately at 5, or 50 on Enterprise | Not published | Not published; warm-pool capacity varies by plan |
| Where jobs run | GitHub's own hosted fleet | Ephemeral EC2 instances in Depot's AWS account, or in your own account on Depot Managed | Latchkey's own AWS estate on m6a-class hosts, one job per runner, private network, destroyed after the job |
| Self-healing or retries | None. A failed job waits for a person, or for retry logic you wrote yourself | Not offered | Built in: transient failures are diagnosed and retried inside the run |
| Setup change required | None; this is the default | Change the `runs-on` label. The repository must be owned by a GitHub organization | A `runs-on` label change. GitHub organization accounts only |

## Speed

Not benchmarked yet; the runner benchmark report will replace this section. We have not run the same workload on these runners ourselves, and until we have, there is no number here worth quoting.

What you will find elsewhere is each vendor's own figure, measured on a workload the vendor chose. Those numbers are not wrong, but they are not comparable to each other, and none of them is your repository. The cheap way to get a real answer is to point one slow job at each candidate for a week: runner selection is per job, so three jobs in the same workflow file can run on three providers, and the Actions run log gives you the timings for free.

## Cost: where the identical rate stops being identical

Because the rate is the same, the only thing that moves the bill is how minutes are counted. GitHub rounds every job up to the nearest whole minute. Depot, in its own words, does per-second usage tracking and bills whole minutes at the end of the month, so the rounding happens once across the month rather than once per job.

Take a realistic matrix: 40 jobs, each finishing in 70 seconds. That is 46.7 minutes of work. GitHub bills it as 80 minutes because each job rounds from 1 minute 10 seconds to 2. Depot counts the seconds, so the same matrix is 47 billed minutes. At $0.006/min that is $0.48 against $0.28, so per-second tracking removes about 41% of the line on identical work. Run that matrix on every pull request in a busy week and the difference is the whole argument.

Now the month-scale view, at 10,000 Linux minutes at 2 vCPU and 2,000 macOS minutes:

|  | 10,000 Linux minutes at 2 vCPU | 2,000 macOS minutes | Monthly total |
| --- | --- | --- | --- |
| GitHub-hosted | $60 at $0.006/min | $124 at $0.062/min | $184 |
| Depot | $60 at $0.006/min | $160 at $0.08/min | $220 before plan fees |
| Latchkey | $25 at $0.0025/min | Not offered: $124 on GitHub-hosted | $149 plus $5 to $49 a month for the plan |

Depot is more expensive on this mix, and the two reasons are worth stating plainly. Its macOS runners are $0.08/min against GitHub's $0.062, and it has no standalone free tier, so the bill starts at a $20 monthly plan even before any minutes run. On a Linux-only month with lots of short jobs, the rounding difference alone can put Depot ahead; on a macOS-heavy month it cannot.

The other thing the rate hides is what the machine is. At $0.006/min GitHub gives a private repository 14 GB of disk. Depot gives 100 GB plus a 2 GB RAM disk. If your workflow currently runs a disk-clearing action before it can build, you are already paying minutes for that, and the comparison is not $0.006 against $0.006. Latchkey's own plan is $5 to $49 a month on top of that compute, and its 2,000 to 6,000 included minutes are not netted off, so the figure is gross on both counts.

## Reliability

Neither publishes an Actions SLA on the pages read here. Depot does publish one honest caveat worth repeating: because of Apple licensing its macOS capacity is not elastic, so macOS jobs can queue during busy periods. GitHub's own macOS concurrency is capped at 5 concurrent jobs on every plan below Enterprise, which lifts it to 50, so neither side of this comparison is unlimited on macOS.

On both platforms a transient failure is a failed job and a billed minute. Depot's Windows runners have no Hyper-V because of an EC2 limitation, and its own documentation says Docker is unlikely to work there, which is the kind of constraint that is much cheaper to read than to discover.

For the failures that look like runner problems and are not, start with [exit code 137](/learn/failures/exit-code-137-in-github-actions) and [freeing disk space on GitHub Actions runners](/learn/failures/free-disk-space-on-github-actions-runners).

## When to choose GitHub-hosted

- Your repositories are public: free and unlimited on a 4 vCPU and 16 GB machine.
- Your minutes fit the included allowance, and adding a $20 to $200 monthly plan to save nothing per minute makes no sense.
- Your bill is mostly macOS, where GitHub is the cheaper of the two at $0.062/min.
- You need Windows with Docker, Windows on arm64, or macOS on Intel, none of which Depot offers on this rate card.

## When to choose Depot

- Your matrices are wide and your jobs are short, so per-minute rounding is quietly inflating a third or more of your Linux bill.
- Your jobs are disk-bound: 100 GB of disk and a RAM-disk accelerator at the same price as 14 GB is the clearest win on this page.
- You want sizes GitHub does not sell at that shape, up to 64 vCPU with 256 GB of RAM on both x64 and Graviton4 arm64.
- Your cache does not fit in 10 GB and you would rather pay $0.20/GB/month than rebuild it. Note the trade: Depot cache entries are not isolated by branch, which is faster and less strict than GitHub's branch scoping.

## Switching: the exact diff

There is no app install step in Depot's runner path; the repository has to be owned by a GitHub organization rather than a personal account, and then it is the label. `depot-ubuntu-latest` tracks the current LTS if you would rather not pin.

```.github/workflows/ci.yml
jobs:
   test:
-    runs-on: ubuntu-latest
+    runs-on: depot-ubuntu-24.04

   build-arm:
-    runs-on: ubuntu-24.04-arm
+    runs-on: depot-ubuntu-24.04-arm-4
```

## The verdict

Depot is not a discount on GitHub-hosted runners and does not pretend to be: the published Linux rates are identical at 2 and 4 vCPU. What changes is the machine behind the rate and the way the meter runs, and both of those favour a particular shape of CI, namely lots of short jobs that touch a lot of disk. If that is your workflow, the per-second metering alone can be worth a third of the Linux line, and the 100 GB disk removes work you are currently paying for. If your repositories are public, or your minutes fit the free allowance, or your bill is mostly macOS, staying put is the correct answer and the plan fee is pure cost. Neither option does anything for the job that fails on a registry timeout and bills you twice.

## FAQ

### Is Depot cheaper than GitHub Actions?

Not per minute. As read on 20 September 2026 both list Linux at $0.006/min at 2 vCPU and $0.012 at 4 vCPU. Depot can still produce a smaller bill because it meters to the second with no one-minute minimum, and GitHub rounds every job up to a whole minute, which on a matrix of 70-second jobs is roughly a 42% difference on the same work. On macOS Depot is more expensive, at $0.08/min against $0.062.

### Why does per-second billing matter?

Because GitHub Actions encourages many small jobs. A matrix fans out into dozens of jobs that each run for seconds, and every one of them is rounded up to a whole minute by a per-minute biller. The shorter your average job, the larger the share of your bill that is rounding rather than compute. Measure it before you argue about rates: divide your billed minutes by your elapsed minutes.

### What are the fastest drop-in replacements for GitHub-hosted runners?

Every managed vendor in this category is a drop-in in the sense that matters, which is that you change a `runs-on` label and nothing else. Which is fastest depends on whether your jobs are CPU-bound, I/O-bound or waiting on a cache, and no vendor benchmark will tell you which of those you are. We have not published our own benchmark yet; when the runner benchmark report lands it will carry the raw timings.

### Do Depot runners work with Docker on Windows?

Depot's own documentation says no: its Windows runners have no Hyper-V because of an AWS EC2 limitation, so anything that requires it, Docker included, is unlikely to work. Linux Docker builds are the path Depot supports, and its remote container builds are a separate product from the Actions runners.

## References

- [Depot GitHub Actions runner types and per-minute prices](https://depot.dev/docs/github-actions/runner-types)
- [Depot pricing and plan inclusions](https://depot.dev/pricing)
- [GitHub Actions per-minute rates and minute multipliers](https://docs.github.com/en/billing/reference/actions-minute-multipliers)
- [GitHub-hosted runner specifications](https://docs.github.com/en/actions/reference/runners/github-hosted-runners)
- [GitHub Actions usage limits](https://docs.github.com/en/actions/reference/limits)

---

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