# What Depot GitHub Actions runners are, and how they work

> How Depot GitHub Actions runners work: ephemeral EC2 by size, per-second tracking with a size multiplier, the shared cache, and the plan minutes.

Source: https://latchkey.dev/learn/runners/depot-runners-explained  
Updated: 2026-09-20

Depot github actions runners are ephemeral, single-tenant EC2 instances that Depot launches from a standby pool when GitHub sends it a webhook, runs one job on GitHub's own runner image, and terminates. You adopt them by changing `runs-on` to a `depot-` label; what changes underneath is the hardware, a cache that is shared across branches, and a billing model that tracks by the second and multiplies by machine size.

Depot sells build acceleration in four shapes: remote container builds, these GitHub Actions runners, its own CI sandboxes, and the cache and registry underneath them. The runners are the part that needs no new mental model, because the orchestration, the logs and the actions are still GitHub Actions.

Everything here was read from depot.dev on 20 September 2026 and is dated on the page. If you want the head-to-heads instead, [Depot against GitHub-hosted runners](/learn/runners/depot-vs-github-hosted-runners), [Depot against WarpBuild](/learn/runners/depot-vs-warpbuild) and [the Docker cache comparison with Blacksmith](/learn/runners/depot-vs-blacksmith-for-docker-builds) carry the full tables.

## How a Depot runner starts, and how it ends

The architecture is webhook-driven and Depot documents each step. GitHub sends a `workflow_job` event to Depot's control plane; Depot takes a fresh EC2 instance from a pre-provisioned standby pool matching the label you asked for; it registers that runner in your organization's default runner group; the job runs on GitHub's standard runner image; and the instance is terminated when the job finishes. Instances are single-tenant and never reused.

The hardware is named rather than implied. Intel runners are 4th Gen AMD EPYC Genoa instances, Arm runners are AWS Graviton4, and both get an EBS volume provisioned at 8,000 IOPS and 250 MB/s. Linux and macOS runners also reserve part of the machine's memory as a RAM-backed disk accelerator that buffers reads and writes to the root disk, which is a real architectural difference rather than a marketing line.

Your repository has to be owned by a GitHub organization; personal accounts cannot use Depot runners.

```.github/workflows/ci.yml
jobs:
   build:
-    runs-on: ubuntu-24.04
+    runs-on: depot-ubuntu-24.04        # or depot-ubuntu-latest
     steps:
       - uses: actions/checkout@v5
       - run: npm ci && npm test
```

## The sizes, and the multiplier attached to each one

Labels encode the size: `depot-ubuntu-24.04` is the 2 vCPU base, and a numeric suffix picks the rest of the ladder. Arm labels add `-arm` and cost exactly the same as Intel at every size, which is unusual in this market. The last column is the one to read twice, because it is what drains your plan's included minutes.

| Label | vCPU | Memory | Disk | Accelerator | Per minute | Minutes multiplier |
| --- | --- | --- | --- | --- | --- | --- |
| `depot-ubuntu-24.04` | 2 | 8 GB | 100 GB | 2 GB | $0.006 | 1x |
| `depot-ubuntu-24.04-4` | 4 | 16 GB | 130 GB | 4 GB | $0.012 | 2x |
| `depot-ubuntu-24.04-8` | 8 | 32 GB | 150 GB | 8 GB | $0.024 | 4x |
| `depot-ubuntu-24.04-16` | 16 | 64 GB | 180 GB | 8 GB | $0.048 | 8x |
| `depot-ubuntu-24.04-32` | 32 | 128 GB | 200 GB | 16 GB | $0.096 | 16x |
| `depot-ubuntu-24.04-64` | 64 | 256 GB | 250 GB | 32 GB | $0.192 | 32x |
| `depot-windows-2025` | 2 | 8 GB | 100 GB | None | $0.008 | 2x |
| `depot-macos-26` | 8 | 24 GB | 400 GB | 2 GB | $0.08 | Not published |

Windows runs Server 2022 or 2025 at the same ladder up to 64 vCPU, with one caveat Depot states plainly: EC2 gives it no Hyper-V, so anything that needs it, Docker included, is unlikely to work. macOS runs on M2 chips for macOS 14 and 15 and M4 for macOS 26, all at 8 vCPU and $0.08 a minute, with a 12,000 IOPS volume; Depot also warns that Apple licensing keeps macOS capacity from being fully elastic, so macOS jobs can queue at busy times. macOS is a Startup-plan feature, not a Developer-plan one.

## Billing: per second, multiplied by size, netted against a plan

Depot's wording on its runners overview is worth quoting because it is unusually precise: "We track builds by the second and bill for whole minutes used at the end of the month. No one minute minimum enforced." So there is exactly one rounding step, and it happens once per month rather than once per job. On a matrix of forty 70-second jobs, GitHub bills 80 minutes and Depot bills the 47 minutes those jobs actually took.

What your bill counts is billed minutes, not elapsed minutes: elapsed time multiplied by the size multiplier in the table above. The plan then nets its included minutes off that number. Developer is $20 a month with 2,000 included GitHub Actions minutes, 25 GB of cache and storage, and one user; Startup is $200 with 20,000 minutes, 250 GB and unlimited users; additional minutes are $0.006 and extra cache is $0.20 per GB a month.

Put those together on the workload every page in this area uses. Ten thousand minutes a month on the 2 vCPU runner is 10,000 billed minutes, less the 2,000 the Developer plan includes, so 8,000 at $0.006 is $48, and $68 with the plan against $60 on GitHub-hosted runners. Move the same workload to the 4 vCPU runner and it becomes 20,000 billed minutes, $108 of overage and $128 with the plan, against $120 for a GitHub larger runner at that size.

## The cache, and the thing to know about it

Depot runners are wired into the same cache orchestration system as its container builds, with no workflow changes: it advertises upload and download at up to 1,000 MiB/s over 12.5 Gbps of network throughput and describes the result as 10x faster caching, which is a vendor claim rather than a measurement here. Cache entries are scoped per repository, so one repository cannot read another's entries.

Inside a repository the scoping is deliberately looser than GitHub's, and this is the sentence to notice: cache is not isolated by branch, so entries from the default branch and from every other branch share one namespace, and you control isolation through how you format your cache keys. That is a genuine convenience, since feature branches get warm caches immediately, and a genuine trade, because a cache entry written by any branch is readable by the rest.

If you also use Depot for Docker image builds, the BuildKit builder runs in the same private network as the runner, which is the architectural reason a build-then-test job can be faster there than on a runner that has to pull the image across the internet.

## What Depot is best at

- Docker-heavy pipelines, because the remote builder and the runner sit in one network and the cache is shared with `depot build` outside CI.
- Arm64 at the same price as Intel, all the way to 64 vCPU with 256 GB, which no other vendor in this area matches on price parity.
- Short jobs and wide matrices, because per-second tracking with no one-minute minimum removes the rounding tax that GitHub applies per job.
- Teams that want controls rather than just speed: egress filtering by IP, CIDR or hostname, custom runner AMIs on the Business plan, and the option to run the same runners inside your own AWS account.
- Anyone who needs no concurrency limit: Depot publishes none, on any plan.

## Where it falls short

- The rate. At 2 and 4 vCPU Depot lists exactly GitHub-hosted list price, $0.006 and $0.012, and from 8 vCPU up it is above GitHub's larger runners: $0.024 against $0.022, $0.048 against $0.042, $0.096 against $0.082 and $0.192 against $0.162.
- macOS needs the $200 Startup plan, so a small team with an iOS app pays ten times the Developer plan fee to reach it, and Depot says that capacity is not fully elastic.
- Windows has no Hyper-V, so Docker on Windows runners is unlikely to work at all.
- The cache is not isolated by branch, which is a trade rather than a bug, but one your threat model has to accept.
- The Developer plan is a single user, and Depot runners require an organization-owned repository.

## What a Latchkey user would notice

Three differences, in the order they show up. Depot sells arm64, Windows and macOS and Latchkey sells none of them, so a mixed-platform pipeline keeps two vendors either way. Depot tracks usage by the second while Latchkey rounds each job up to a whole minute, which favors Depot on short jobs. And at the same 2 vCPU size the rates are $0.006 and $0.0025, a 58% difference, before either plan fee.

The fourth difference is the one neither rate card shows. A job that dies on a registry timeout is billed by Depot and billed again on the re-run; on a Latchkey runner that class of failure is diagnosed and retried inside the same job, which is documented in [self-healing](/documentation/self-healing). If your pipeline is slow, Depot is solving your problem. If it is red for reasons unrelated to your code, faster hardware will not touch it.

## FAQ

### What runner types does Depot offer?

Ubuntu 22.04 and 24.04 on Intel and Arm from 2 to 64 vCPU, Windows Server 2022 and 2025 at the same sizes, and macOS 14, 15 and 26 at 8 vCPU with 24 GB. Intel runners are AMD EPYC Genoa, Arm runners are Graviton4, and macOS runs on M2 or M4 depending on the version.

### How does Depot bill GitHub Actions minutes?

It tracks usage by the second with no one-minute minimum and bills whole minutes at the end of the month. The number that counts is billed minutes, which is elapsed time multiplied by the size multiplier: 1x at 2 vCPU, 2x at 4, 4x at 8 and so on. Your plan's included minutes are subtracted from that total, and the rest is $0.006 a minute.

### Does Depot isolate cache entries between branches?

No, and it says so. Cache entries are scoped per repository, so another repository cannot read them, but inside a repository the default branch and every feature branch share one namespace. Depot's documentation tells you to control isolation through your cache key format. GitHub's own cache behaves the other way, restricting reads to the same branch or the default branch.

### Do Depot runners support macOS and Windows?

Both, with caveats. macOS is on the Startup plan and up, runs at 8 vCPU for $0.08 a minute, and has capacity Depot describes as not fully elastic because of Apple licensing, so jobs can queue. Windows runs Server 2022 or 2025 from $0.008 a minute, but the instances have no Hyper-V, so Depot says workloads that need it, such as Docker, are unlikely to work.

## References

- [Depot GitHub Actions runner types, sizes, rates and multipliers](https://depot.dev/docs/github-actions/runner-types)
- [Depot GitHub Actions runners overview: architecture, cache and per-second tracking](https://depot.dev/docs/github-actions/overview)
- [Depot pricing: plans, included usage and overage rates](https://depot.dev/pricing)
- [GitHub Actions runner pricing, for the rates compared here](https://docs.github.com/en/billing/reference/actions-runner-pricing)
- [Latchkey runner sizes, rates and plans](https://latchkey.dev/pricing)

---

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