Skip to content
Latchkey LogoLatchkey home

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.

Billed minutes for one 10-minute job: 10 at 2 vCPU, 20 at 4, 40 at 8, 80 at 16, 160 at 32, 320 at 64
Depot bills elapsed minutes multiplied by a size multiplier, so a plan allowance is spent at the size of the machine. Multipliers and rates read from depot.dev on 20 September 2026.

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.

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

LabelvCPUMemoryDiskAcceleratorPer minuteMinutes multiplier
depot-ubuntu-24.0428 GB100 GB2 GB$0.0061x
depot-ubuntu-24.04-4416 GB130 GB4 GB$0.0122x
depot-ubuntu-24.04-8832 GB150 GB8 GB$0.0244x
depot-ubuntu-24.04-161664 GB180 GB8 GB$0.0488x
depot-ubuntu-24.04-3232128 GB200 GB16 GB$0.09616x
depot-ubuntu-24.04-6464256 GB250 GB32 GB$0.19232x
depot-windows-202528 GB100 GBNone$0.0082x
depot-macos-26824 GB400 GB2 GB$0.08Not 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. 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?
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.

Related guides

References

Per-second metering at list price, or per-minute at $0.0025. Latchkey is the second one. Start free → 30-day trial · No credit card