What Depot GitHub Actions runners are, and how they work
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, Depot against WarpBuild and the Docker cache comparison with Blacksmith 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.
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 testThe 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 buildoutside 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. 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.
Key takeaways
- Ephemeral single-tenant EC2 from a standby pool, GitHub's own runner image, terminated after one job.
- Intel and Arm cost the same at every size, from $0.006 at 2 vCPU to $0.192 at 64.
- Billed minutes are elapsed minutes times a size multiplier, tracked per second and rounded once at month end.
- Plans are $20 with 2,000 included minutes and 25 GB of cache, or $200 with 20,000 and 250 GB.
- Cache is scoped per repository but not isolated by branch, and macOS requires the Startup plan.
Frequently asked questions
What runner types does Depot offer?
How does Depot bill GitHub Actions minutes?
Does Depot isolate cache entries between branches?
Do Depot runners support macOS and Windows?
Related guides
References
- Depot GitHub Actions runner types, sizes, rates and multipliers
- Depot GitHub Actions runners overview: architecture, cache and per-second tracking
- Depot pricing: plans, included usage and overage rates
- GitHub Actions runner pricing, for the rates compared here
- Latchkey runner sizes, rates and plans
- GitHub Actions documentation