RunsOn

Self-hosted CI runners, honestly reviewed. No marketing fluff, just what you get when you route GitHub Actions through your own AWS account.

TL;DR

• What it is: A managed solution that runs GitHub Actions jobs on EC2 instances inside your own AWS account, replacing GitHub-hosted runners at a fraction of the cost [README].
• Who it’s for: Engineering teams spending more than $100/month on GitHub Actions who want lower costs, faster runners, and full control over their CI infrastructure — without the operational burden of managing Kubernetes for Actions Runner Controller [homepage].
• Cost savings: GitHub-hosted 2-cpu x64 runners run at $0.008/min. RunsOn with AWS spot pricing gets that down to roughly $0.0008/min — a 10x reduction. Real-world testimonials report 70–90% savings [3][homepage].
• Key strength: Near-zero migration effort (swap one line in your workflow file), one-click CloudFormation deploy, and S3-backed caching that can be 10x faster than GitHub’s built-in cache [README][3].
• Key weakness: AWS-only, and the “MIT license” label in the repo covers only the public CloudFormation assets — the actual product requires a license key (free for non-commercial use, paid for commercial, with a 15-day trial). Non-AWS shops need not apply [README][5].

---

What is RunsOn

RunsOn is a managed service that provisions ephemeral EC2 instances in your own AWS account every time a GitHub Actions job fires. From GitHub’s perspective, the job runs on a “self-hosted runner.” From your perspective, you get a fresh VM that starts, runs the job, and terminates — all without you managing a runner fleet, a Kubernetes cluster, or a long-lived server.

The pitch in one sentence from the GitHub README: “Self-hosted GitHub Actions runners made simple. For AWS. 10x cheaper, 40% faster, and unlimited caching.”

What makes this worth paying attention to isn’t just the cost angle. GitHub’s hosted runner catalog is narrow: ubuntu-latest, windows-latest, a handful of larger runners at $0.016–$0.064/min. RunsOn gives you access to the entire EC2 instance catalog — from a 2-vCPU t3.small up to 896-vCPU high-memory instances, x64 and ARM64, GPU-equipped instances, instances with NVMe storage — at whatever EC2 spot or on-demand price AWS charges, with no markup from RunsOn [README][homepage].

The project is built by Cyril Rohr, a solo founder who started it from frustration with CI/CD bottlenecks. As of early 2026, it processes roughly 1.36 million GitHub Actions jobs per day and describes itself as powering approximately 1.5% of worldwide GitHub Actions traffic [1][homepage]. That’s a meaningful scale signal for a solo-founder product.

---

Why people choose it

The testimonials page [3] reads like a broken record in the best way — different companies, same outcome. The pattern is: some combination of cost reduced by 70–90%, runtime cut by 2–5x, setup completed in under 10 minutes, and then “I can’t think of any downsides.”

The cost argument is straightforward. GitHub charges $0.008/min for a standard Linux runner and the price scales up linearly with cores. A 16-cpu runner runs $0.064/min. At 40,000 minutes/month, that’s $320/month in CI costs before you’ve touched a database or deployed anything. RunsOn replaces that with AWS EC2 spot pricing, which for comparable instance types runs 70–90% lower [homepage][2]. Corentin Smith, CTO at Dashdoc: “After benchmarking a lot of tools, it’s the best. We run thousands of jobs per day. Costs divided by 4.” [3]

The performance argument is less obvious but real. RunsOn’s benchmarks claim raw CPU performance 30% higher than GitHub-hosted runners on comparable specs [README]. The bigger gain in practice comes from the S3 cache backend: because the cache lives in your own S3 bucket and the runner is in the same AWS region, cache downloads and uploads are dramatically faster than GitHub’s cache service. One Aptos Labs engineer called out the S3 caching as an unexpected win that further reduced build times beyond what they’d planned for [3].

The control argument matters for compliance-sensitive teams. When you use GitHub-hosted runners, your code, secrets, build artifacts, and logs all pass through GitHub’s infrastructure. With RunsOn, the runner lives in your VPC. Logs, caches, and secrets never leave your AWS account [homepage]. This is the same privacy argument that drives self-hosted infrastructure decisions in general — but RunsOn makes it achievable without running your own runner fleet.

Versus Actions Runner Controller (ARC). ARC is GitHub’s own Kubernetes-based solution for self-hosted runners. It works, but it requires Kubernetes expertise, ongoing maintenance, and careful tuning to handle burst workloads without queue buildup. RunsOn replaces that complexity with a CloudFormation stack that you deploy once [homepage]. The Aptos Labs team migrated from k8s-based ARC to RunsOn and noted the switch was clean [3].

Versus third-party runner providers (Depot, Warpbuild, BuildJet). These services offer faster runners without AWS complexity, but they’re still third parties — your code runs on their infrastructure, you pay their markup, and you’re subject to their pricing changes. BuildJet announced it was shutting down in early 2026, which RunsOn covered in a blog post [1]. That event illustrates the durability argument for RunsOn: if the vendor closes, you’re not mid-migration — your AWS infrastructure stays up.

---

Features

Core runner capabilities:

• Linux (x64 and ARM64), Windows, and GPU runner support [README]
• Ephemeral VM per job — fresh environment every time, no state bleed between runs [README]
• Any EC2 instance family: from 2-vCPU general purpose up to 896-vCPU memory-optimized instances [homepage]
• Spot instances with automatic on-demand fallback if spot capacity is unavailable [README]
• Bring Your Own Image (BYOI) — use a custom AMI or one of the public runner images maintained for AWS [README]

Networking and security:

• Optional SSH access to running jobs — team SSH keys imported automatically from GitHub [3]
• Static IPs for workflows that need to allowlist runner IP addresses [README]
• Private subnet support with no public egress [README]
• Multi-AZ and multi-environment support [README]
• StepSecurity integration for supply chain attack protection (network monitoring, file integrity checks) [1]

Caching:

• S3-backed cache backend — your own S3 bucket, not GitHub’s cache service [README]
• “Magic Caching” — an automatic cache layer that doesn’t require configuring cache steps in each workflow [README]
• EFS support for sharing files across jobs in the same workflow [1]
• Ephemeral registry for faster Docker builds [1]
• tmpfs (YOLO mode) for workloads that benefit from RAM-backed temp storage [1]

Observability:

• Per-job cost tracking [README]
• CloudWatch metrics [homepage]
• OpenTelemetry traces out of the box [homepage]
• Email cost and alert reports [5]

Deployment:

• CloudFormation template — one-click deploy, one-click upgrade [README]
• Terraform / OpenTofu support added in v2.11.0 (March 2026) [1]
• 10 supported AWS regions across US, EU, and APAC [5]

Workflow integration:

• One-line change to adopt: swap runs-on: ubuntu-latest for runs-on: runs-on/runner=2cpu-linux-x64 [README]
• Existing actions, cache steps, and secrets work without modification [homepage]
• Flexible label syntax for selecting instance size, image, networking, and extras per-job [README]

---

Pricing: the actual math

The license model is worth clarifying up front: RunsOn is not purely open-source the way some tools on this site are. The public GitHub repository contains MIT-licensed CloudFormation templates and supporting assets. The product itself — the RunsOn service that runs in your account — requires a license key. Non-commercial use is free. Commercial use starts with a 15-day trial; after that you pay for a license [README][5].

Pricing tiers aren’t published as flat dollar amounts on the website. The pricing page shows a calculator that computes your AWS costs at spot and on-demand prices for various runner sizes, plus the license cost. The framing throughout is “no markup on AWS costs, no per-minute fees from us.”

GitHub-hosted runner costs for reference:

• 2-cpu Linux: $0.008/min ($0.48/hr)
• 4-cpu Linux: $0.016/min ($0.96/hr)
• 8-cpu Linux: $0.032/min ($1.92/hr)
• 16-cpu Linux: $0.064/min ($3.84/hr)

RunsOn on AWS spot (approximate, varies by region and instance family):

• 2-cpu equivalent (e.g. c7a.large): ~$0.02–0.04/hr on spot = $0.0003–0.0007/min
• That’s 7–15x cheaper than GitHub’s rate at the same compute tier [homepage][README]

Concrete example: A team running 50,000 minutes/month on 4-cpu Linux runners. GitHub hosted: $800/month. RunsOn on spot at $0.016/hr for comparable EC2: roughly $53/month in AWS costs + the RunsOn license. Even being conservative about spot savings, the difference is $500–700/month [2][homepage].

The $0.002/min GitHub self-hosted fee: In December 2025, GitHub announced they would charge $0.002/min for all self-hosted runner usage starting March 2026. This would add $80/month per 40,000 minutes consumed. RunsOn updated its pricing calculator with a toggle to show before/after costs [2]. As of the announcement, the fee was subsequently suspended — so it’s not currently active — but it’s a risk worth knowing about for long-term planning.

Even with the fee active, RunsOn’s math still works: at the 4-cpu level, adding $0.002/min to $0.003–0.005/min AWS spot cost still lands well below GitHub’s $0.016/min [2].

---

Deployment reality check

The installation guide [5] is honest: it takes about 10 minutes for a technical user who already has an AWS account. That claim is borne out repeatedly in testimonials — multiple engineers describe it as faster than advertised [3].

What the install actually involves:

1. Select your AWS region from a list of 10 supported regions
2. Click through to CloudFormation, fill in your GitHub org name, license key, and alert email
3. Wait for the stack to create (~5 minutes)
4. Click the RunsOn URL in the CloudFormation outputs to register the GitHub App
5. Select which repositories to install the app on
6. Update one workflow file to verify it works

The CloudFormation template handles IAM role creation (least-privilege permissions), networking setup, and the RunsOn service itself. You don’t touch EC2 directly.

Prerequisites:

• An AWS account (RunsOn recommends a dedicated sub-account for isolation)
• GitHub organization or personal account
• A RunsOn license key (the 15-day trial is available without a credit card upfront) [5]

What can go sideways:

• AWS account limits on EC2 instances. If you want to run 50 concurrent 16-cpu runners, your AWS account needs the corresponding vCPU limits. New accounts start with low limits; you may need to request increases via AWS support before the economics fully kick in.
• Spot interruptions. AWS can reclaim spot instances mid-job. RunsOn handles automatic fallback to on-demand, but very long-running jobs (multi-hour) carry more interruption risk. The on-demand fallback means it rarely fails, just gets more expensive.
• Windows runners are supported but less documented. The bulk of the testimonial evidence is Linux-focused.
• Solo-founder maintenance risk. This is a real flag for any team making a long-term infrastructure bet. Cyril Rohr has been responsive by all accounts [3], but the project doesn’t have a large engineering team behind it. The Terraform module (added March 2026) brought in a co-contributor, which is a positive signal [1].
• The GitHub self-hosted fee, if it gets reinstated. Not a current issue, but worth tracking.

For a non-AWS shop — GCP or Azure primary — RunsOn doesn’t help you. It’s AWS-specific by design and there’s no indication of multi-cloud support planned [README].

---

Pros and cons

Pros

• Genuine cost savings. 70–90% reduction in CI costs is not marketing copy — it’s consistently reported across independent teams at different usage volumes [3].
• True infrastructure isolation. Runners, logs, caches, and secrets never leave your VPC. This matters for regulated industries and teams that can’t send code through third-party infrastructure [homepage].
• Full EC2 catalog. Access to GPU instances, ARM64, NVMe-backed instances, and anything else AWS offers — not locked into GitHub’s narrow runner menu [README].
• 10-minute real install time. The testimonials back up the claim. Not “10 minutes if everything goes perfectly” — it actually seems to go that fast in practice [3][5].
• S3 caching is a meaningful bonus. Engineers who switched primarily for cost savings report faster builds as an unexpected side effect, driven by the S3 cache [3].
• Ephemeral runners by default. Every job gets a clean environment. No stale state, no artifact bleed between builds, no runner hygiene problems [README].
• CloudWatch + OpenTelemetry built in. Per-job cost tracking and metrics out of the box — you’re not flying blind on what CI costs [homepage].
• Responsive solo founder. The testimonials page [3] repeatedly mentions Cyril responding to support requests within hours, implementing feature requests within days. That’s rare for infrastructure tooling.

Cons

• AWS-only. If your team runs on GCP or Azure, RunsOn isn’t an option. No multi-cloud support [README].
• The “MIT license” framing is misleading. The repository and CloudFormation templates are MIT. The product requires a commercial license. Worth understanding before you build it into a budget assumption [README][5].
• Requires an AWS account and baseline AWS literacy. You need to understand sub-accounts, IAM, and EC2 to get value from the customization options. The baseline install is simple; tuning for production workloads requires more AWS knowledge.
• Solo-founder concentration risk. One person runs this at 1.36 million jobs/day. Cyril is clearly capable and responsive, but the bus-factor reality should factor into a long-term infrastructure decision [1].
• Windows support is secondary. Linux is the first-class experience. Windows runners exist but aren’t as thoroughly documented or tested based on the available material [README].
• Spot interruptions require tolerance. Long-running jobs on spot instances carry risk of mid-job termination. The on-demand fallback mitigates failures but not cost surprises [README].
• GitHub’s self-hosted fee is a pending variable. GitHub suspended the $0.002/min fee but didn’t cancel it. If reinstated, it reduces but doesn’t eliminate the savings margin for smaller runner sizes [2].

---

Who should use this / who shouldn’t

Use RunsOn if:

• Your team spends more than $100/month on GitHub Actions and that number is growing with your build volume.
• You’re already on AWS or willing to create an AWS account for CI infrastructure.
• You’ve looked at Actions Runner Controller and don’t want to maintain a Kubernetes cluster for it.
• You have workloads that need ARM64, GPU, or large-memory runners that GitHub doesn’t offer at reasonable prices.
• Your compliance or security posture requires keeping build artifacts and secrets inside your own infrastructure.
• You want S3-backed caching without building it yourself.

Skip it (stay on GitHub-hosted runners) if:

• You spend less than $100/month on Actions. The license cost and AWS setup overhead won’t pay off.
• Your team has no AWS experience and no one available to handle infrastructure questions.
• You need multi-cloud or non-AWS runner deployment.

Skip it (build ARC yourself) if:

• You already run a mature Kubernetes platform and have operators who are comfortable maintaining it.
• You need fine-grained control over the runner provisioning logic and want to own the entire stack.

Skip it (use a third-party runner provider) if:

• You want managed runners without any AWS involvement and are comfortable trusting a third party with your code. Note: BuildJet shutting down is a cautionary tale about third-party runner vendor risk [1].

---

Alternatives worth considering

• GitHub-hosted runners — zero setup, maximum simplicity, highest cost at scale. The incumbent you’re escaping.
• Actions Runner Controller (ARC) — GitHub’s official Kubernetes-based self-hosted runner solution. More control, more maintenance burden. Right choice if you already own Kubernetes operations.
• Depot — third-party runner provider with fast startup times and a managed model. No AWS required, but your code runs on their infrastructure.
• Warpbuild — similar positioning to Depot: managed, fast, third-party.
• Buildkite — full CI platform with its own self-hosted agent model. Right choice if you want to move off GitHub Actions entirely.
• Philips Terraform module — open-source Terraform module for self-hosted AWS runners. DIY version of what RunsOn does, minus the management layer. More control, more work.

For most teams evaluating “escape GitHub Actions costs on AWS,” the real decision is RunsOn vs. ARC vs. DIY. RunsOn wins on setup simplicity and ongoing maintenance. ARC wins on control and zero license cost. DIY wins if you have specific requirements neither covers.

---

Bottom line

RunsOn is the most pragmatic answer to the GitHub Actions cost problem for AWS-native engineering teams. It doesn’t try to be a CI platform or replace GitHub Actions — it just makes the runners cheaper, faster, and yours. The 10-minute install claim holds up in practice, the cost savings are real and consistently reported by teams at different scales, and the S3 caching is a genuine bonus that wasn’t obvious from the headline pitch.

The caveats are real: AWS-only, commercial license required, solo-founder operation. None of those are dealbreakers for a team spending $500/month on CI, but they’re worth factoring into a long-term decision. If you’re paying GitHub for larger runners, watching your Actions bill climb every sprint, and your team runs on AWS — there’s no serious argument for not at least running the 15-day trial.

If the AWS setup is the blocker, upready.dev handles that deployment for you. One-time fee, done, you own the infrastructure.

---

Sources

1. RunsOn Blog — News, guides, and insights about self-hosted GitHub Actions runners. https://runs-on.com/blog/tags/self-hosted/
2. RunsOn Blog — GitHub to charge $0.002/min for self-hosted runners starting March 2026. https://runs-on.com/blog/github-self-hosted-runner-fee-2026/
3. RunsOn Testimonials — What Engineers Say About RunsOn. https://runs-on.com/testimonials/
4. RunsOn Blog — Pricing tag posts. https://runs-on.com/blog/tags/pricing/
5. RunsOn Installation Guide. https://runs-on.com/guides/install/

Primary sources:

• GitHub repository and README: https://github.com/runs-on/runs-on (1,154 stars, MIT-licensed public assets)
• Official website: https://runs-on.com
• Pricing page: https://runs-on.com/pricing/
• Architecture overview: https://runs-on.com/architecture/