Depot vs GitHub Actions hosted runners

By Kaveh Alemi·Latchkey

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.

Chart: 40 jobs of 70 seconds bill 80 minutes on GitHub against 47 tracked by the second — Identical $0.006/min rates, read 20 September 2026. The difference on a 40-job matrix of 70-second jobs is rounding: 80 billed minutes against 47.

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.

GitHub-hosted, Depot and Latchkey side by side (read 20 September 2026)

	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 and freeing 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.

Switching costs you one line

Latchkey runners are a drop-in replacement: change runs-on: and the rest of the workflow is untouched. Self-healing is on by default, so transient failures are fixed and retried instead of failing the build.

.github/workflows/ci.yml

# before
    runs-on: ubuntu-latest

# after
    runs-on: latchkey-medium

Start free - 30-day trial, no credit card required, or estimate your savings first.

Frequently asked questions

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.