RunsOn vs Depot for GitHub Actions runners

By Daniel Zoghalchali·Latchkey

RunsOn vs Depot is not a rate comparison, because RunsOn does not charge a rate: it charges a flat annual license priced by how many jobs you run a month, and leaves the compute on your own AWS bill at spot prices. Depot charges $0.006 a minute for a 2 vCPU Linux runner and runs it in its own account, so the two only meet if you convert one into the other.

RunsOn installs a CloudFormation stack into your AWS account and launches an ephemeral EC2 runner there for each job, on spot with on-demand fallback, on any instance shape your quotas allow. AWS bills you for the instances with no markup from RunsOn, and RunsOn bills you once a year for a license. The tiers are keyed to runners per month, where a runner is one ephemeral instance and therefore one job: under 50,000 is $350 a year, under 200,000 is $1,050, under 500,000 is $2,100, and past that Enterprise is $4,200.

Depot sells the opposite arrangement. Its runners are ephemeral EC2 instances in Depot's own AWS account, carrying a RAM disk in front of the root disk and a cache service of its own, and you pay Depot a monthly plan plus a per-minute rate. Nothing is yours to operate, nothing appears on an AWS invoice, and the meter runs on time rather than on job count.

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

RunsOn, Depot and Latchkey side by side (read 21 September 2026)

The meters measure different things, and that is the whole comparison

Depot bills time. RunsOn bills job count, once a year, in steps. Two hundred jobs of twenty minutes and four thousand jobs of one minute cost Depot the same money and put RunsOn four tiers apart. Nothing else on either page matters as much as that sentence.

So the number to find before you compare anything is your own monthly job count, which is the count of workflow jobs rather than workflow runs. RunsOn defines a runner as one ephemeral runner it launches, one per GitHub Actions job, and its own tier guide says under 50,000 covers about 79% of teams.

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.

The cheap way to get a real answer is to point one slow job at each candidate for a fortnight, because runner selection is per job and the Actions run log hands you the timings for free.

RunsOn publishes a CPU score beside every instance row on its pricing table, which is more than most vendors do, and the comparison it draws is against the equivalent GitHub-hosted runner rather than against Depot. Depot publishes an up to 3x claim with no named workload. Neither is a measurement you can carry to your own repository.

What does transfer is queue latency, and the two are shaped differently there. A RunsOn job in Flex mode waits for an EC2 instance to launch, which is why Fleet exists and keeps a warm pool. Depot has no equivalent decision to make because the pool is not yours. If a cold start is what hurts, read GitHub Actions cold start and setup time before you attribute it to a vendor.

Cost: the same month, with the AWS bill kept separate

The workload every comparison here uses: 10,000 Linux minutes at 2 vCPU plus 2,000 macOS minutes on a private repository. RunsOn sells no macOS runner, so that half of its bill is GitHub-hosted, exactly as it is for Latchkey.

RunsOn wins that month by a wide margin and the margin is not the whole story, because two of its three bill lines are not on the table. Its own pricing page names them: the license to RunsOn, EC2 compute to AWS, and storage and transfer to AWS for the S3 cache bucket and the EBS volumes. NAT gateway hours, cross-zone transfer and the S3 requests behind Magic Cache all land on your AWS invoice, and none of them appear in the $10. The published $0.0010 a minute is spot in us-east-1 with a 30 GB gp3 volume at 400 MB/s included, so it is an honest instance price and not an honest total.

The crossover is easier to state than the total. RunsOn costs you $29 a month plus your EC2 bill at roughly a sixth of Depot's rate, so on Linux minutes alone the license pays for itself at about 5,800 minutes a month of 2 vCPU compute. Below that Depot is cheaper before you count a single hour of anybody's time; above it RunsOn pulls away and keeps pulling, because nothing in its price grows with minutes. 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.

The line neither vendor prices is the one that decides this for most teams. RunsOn hands you an AWS account to own: quotas, AMIs, a stack to upgrade, spot capacity when a region is short, and a security boundary that is now yours. Depot hands you a label. If nobody wants that account, the compute saving is paid for in a currency the invoice does not show.

Reliability

Neither publishes a GitHub Actions SLA on the pages read here, and the failure modes are genuinely different rather than differently branded. On Depot a bad day is Depot's bad day and you wait. On RunsOn a bad day is spot capacity in your chosen instance family, an EC2 quota you did not raise before a matrix widened, or a stack that drifted, and all three are yours to fix.

RunsOn does run its runners inside your own VPC, which is the one reliability-adjacent property nothing managed can offer: a job that needs a private database or an internal registry reaches it without a tunnel. That is also the reason GitHub's own guidance is to keep self-hosted runners off public repositories, because a fork pull request would then execute on your network.

The failure both leave on the floor is the mechanical one. A registry timeout at minute nine bills the minutes it burned, fails the job, and waits for a person. On RunsOn that failure hides inside an EC2 invoice rather than a runner invoice, which makes it quieter rather than cheaper.

When to choose RunsOn

• Your job count is high and your minutes are higher. Nothing in the RunsOn price grows with either beyond a tier step, and at volume that is not a discount, it is a different shape of bill.
• You need the runner inside your own network: a private subnet, an internal registry, a database with no public endpoint, a data residency commitment.
• You want instance shapes nobody sells as a runner size, including GPU families. Its published table runs from a 1 vCPU m7a.medium to a 96 vCPU c7i.24xlarge, and GPU rows from a T4 to an A10.
• You already have a platform team that owns AWS accounts, so the quotas, the AMIs and the stack upgrades land on an existing rota rather than on the person who happened to read the install guide.
• Your project is non-commercial. The free license is the whole product in exchange for a public acknowledgement, which no metered vendor can match.

When to choose Depot

• Nobody wants an AWS account. That is a legitimate answer and it is the most common one.
• You need macOS in the same place as everything else. RunsOn documents that it does not support macOS; Depot sells an 8 vCPU macOS runner with 24 GB at $0.08 a minute.
• Your jobs are short and numerous. Per-second tracking with no one-minute minimum is worth real money on a pipeline of forty-second jobs, and on RunsOn that same pipeline is what pushes you up a license tier.
• Your container builds have outgrown the runner. Depot will run the build on a 16 vCPU remote builder with a persistent NVMe layer cache while a small runner drives it.
• Your volume is modest. Under roughly 5,800 Linux minutes a month the RunsOn license costs more than the compute it saves, before anyone touches CloudFormation.

Switching: the exact diff

Depot is a label. RunsOn is a label after a CloudFormation stack, and its label carries the run id so the ephemeral runner is claimed by the right job. Both changes are per job, so the honest test is to point one workflow at each and read two invoices a fortnight later.

 jobs:
   build-on-depot:
-    runs-on: ubuntu-latest
+    runs-on: depot-ubuntu-24.04-4
     steps:
       - uses: actions/checkout@v7
       - run: make build

   build-on-runs-on:
-    runs-on: ubuntu-latest
+    runs-on: runs-on=${{ github.run_id }}/runner=4cpu-linux-x64
     steps:
       - uses: actions/checkout@v7
       - run: make build

The verdict

RunsOn is the cheaper answer for any team already comfortable owning an AWS account, and it is not close: spot EC2 at its published rates is roughly a sixth of Depot per Linux minute, the license stops growing, and the runners sit inside your own VPC where your private services already are. The crossover is near 5,800 Linux minutes a month, and above it the gap widens every month. What that price buys is also a job description. Quotas, AMIs, stack upgrades, spot capacity and a security boundary all become yours, and the compute saving is being spent in a currency your invoice does not print. Depot is the right purchase when nobody wants that job, when you need macOS beside everything else, or when the thing that has outgrown your runner is the container build rather than the runner. Neither one notices that a job failed for a reason unrelated to your code, repairs it and carries on, which on either bill is the line item that grows quietest.

Frequently asked questions

Related guides

References

• RunsOn pricing: license tiers, published EC2 per-minute costs and the three bill lines (verified 2026-09-21)
• Depot GitHub Actions runner types and per-minute prices (verified 2026-09-21)
• Depot pricing: plans, included usage and overage rates (verified 2026-09-21)
• GitHub Docs: self-hosted runner automatic updates and the 30-day rule (verified 2026-09-21)
• GitHub Actions documentation