Every job gets a fresh EC2 instance in your own AWS account, on Spot, for 5–15× less than GitHub charges. AWS bills you for the compute at cost, and RunsOn is a yearly license, priced by the runners you launch a month (one per job), that never meters your minutes. Setup is one CloudFormation stack and about ten minutes, with no Kubernetes cluster to keep alive. Then it just runs.
card at checkout, nothing charged for 15 days · then from €300 / $350 a year · free for non-commercial use
Running 3M+ jobs a day for 900 companies, including Cursor, Tripadvisor and the Apache Software Foundation.
the label is a query — pick constraints, resolved at launch
# the label is a query — each line one constraint jobs: build: runs-on: - runs-on=${{ github.run_id }} - cpu=16 - family=c8i - image=ubuntu24-full-x64 - extras=s3-cache steps: [...]
Some of the 900 companies running RunsOn in production.
A month of heavy builds: 150,000 minutes on 16-core Linux runners. GitHub bills each minute at its own rate. On RunsOn the same minutes run on spot instances in your AWS account, billed by AWS directly, and the license is one flat line that doesn't move with them.
One month of CI billed two ways, for 150,000 minutes of 16-core Linux jobs. GitHub-hosted: $6,300.00. RunsOn: $673.11, of which $598.05 is EC2 spot, $45.89 is EBS and $29.17 is a flat license. The license is on the bill before any job runs; GitHub's bill passes RunsOn's, license included, after 774 minutes.
| 16-core Linux runner 150,000 min × $0.042 | $6,300.00 |
|---|
| EC2 spot · 16-core Linux 150,000 min × $0.003987 | $598.05 |
|---|---|
| EBS gp3 · 30 GB per job prorated over the same minutes | $45.89 |
| RunsOn license flat $350 a year ÷ 12 | $29.17 |
The same 150,000 minutes on a hosted runner vendor's 16 vCPU Linux x64 runner, at list price before free minutes: $2,400.00 at Ubicloud premium ($0.016/min) and $4,800.00 at Avrea, Blacksmith, StarSling or WarpBuild ($0.032/min). hosted runners compared →
On real Rust, TypeScript and Docker builds, RunsOn had the lowest cost per build in all three, ahead of Ubicloud, at the EC2 cost each RunsOn job measured on spot, on-demand fallbacks included (license and plan fees aside). GitHub-hosted runners were the slowest or second-slowest of 8–9 providers in every build. Run by RunsOn, which sells one of the runners measured. every runner, build and run →
From GitHub-hosted runners, you keep the workflow and change the bill. From a hosted runner vendor, the runners move into your own AWS account. From Actions Runner Controller, you keep self-hosting and drop the cluster.
| dimension | GitHub-hosted | RunsOn |
|---|---|---|
| price | per minute, at GitHub's rate | AWS spot at cost, 5–15× cheaper |
| machines | a fixed menu of sizes | any EC2 instance, x64 · arm64 · gpu |
| cache | 10 GB free per repo, more billed | S3 in your VPC, no size cap |
| code runs on | GitHub's infrastructure | your AWS account, fresh VM per job |
| setup | none | one CloudFormation stack, ~10 min |
| dimension | hosted vendor | RunsOn |
|---|---|---|
| price | list price from $0.01/min (Ubicloud standard) to $0.032/min at 16 vCPU | EC2 spot at cost: $0.0043/min for a 16 vCPU c8id.4xlarge with its disk, plus a yearly license |
| control plane | the vendor's | in your AWS account |
| code runs on | usually the vendor's machines; bring-your-own-cloud plans add a per-minute fee on top of your cloud bill | your AWS account and VPC, fresh VM per job |
| machines | the vendor's shapes | any EC2 instance, x64 · arm64 · gpu |
| dimension | ARC | RunsOn |
|---|---|---|
| prerequisite | a Kubernetes cluster, plus Helm | one CloudFormation stack, no cluster |
| scaling | scale sets on nodes you size | one EC2 instance per job |
| runner groups | scale sets inside the cluster | Fleet: scale-set fleets defined in Terraform, no inbound endpoint |
| images | containers you build and patch | AMIs from GitHub's templates, kept current |
| windows & gpu | extra node groups and images | a label |
| idle cost | node pools sized for peak | no runners between jobs; one small Fargate task; warm pools opt-in |
Instance choice, caching, nested virtualization: the parts a runner needs around it. They come with the stack, already wired, and you turn them on from the label.
The instance is the job. The label is a query — family, cpu, ram, image, volume — resolved against live spot capacity at launch. No pools to size, no scale sets to babysit.
Add extras=s3-cache to the label and a
runs-on/action@v2 step, and
actions/cache is backed by an S3 bucket in
your account, in the same region and VPC. Your cache steps stay as
they are.
Restoring 4 GB with actions/cache, the median RunsOn runner against GitHub-hosted at the same size: 27s against 59s at 2, 19s against 41s at 4, 15s against 33s at 8 vCPU. Run by RunsOn, which sells one of the runners measured. cache benchmark →
KVM for Linux, Hyper-V for Windows — nested virtualization is just a label. Android emulators, VM-based e2e suites, Windows containers: they run.
+ docker layer caching · per-job cost reporting · spot→on-demand retry · static egress IPs · warm pools · byo AMIs
“By leveraging AWS with ECR, RunsOn helped cut our cache restore and image pull times by 80% and 60% respectively.”
Ruffin White — Senior Robotics Engineer, Dexory
“We've been using Actions Runner Controller on EKS, but hit a number of scaling issues, job pickup delays, and job cancellations. … We started trialing RunsOn … and have been thoroughly impressed.”
David Moran — Lead DevSecOps Engineer, SmithRx
“Less than 10 min to test, install and use the product. … The cache download speed is blazing fast thanks to amazon s3 endpoint.”
Christopher Brookes — SRE, Appchoose
The long versions are in the docs.
runs-on: ubuntu-latest becomes runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64. Linux x64 and arm64, Windows and GPU are all included, and GitHub Enterprise Server is supported through the Terraform module.ubuntu-latest keeps running on GitHub. Most teams move the slow, expensive jobs first and the rest when convenient. macOS jobs stay where they are: RunsOn is Linux and Windows on EC2, and the two coexist in the same workflow.runs-on.com, both over TLS: a license check (org name, region, license key, app version) and a per-launch telemetry event (region, instance type, boot timings, enabled features). Neither carries repository contents, secrets, or anything from the runner filesystem, and neither sits in the job's execution path.The CloudFormation stack takes about ten minutes. Then the first job lands on a spot instance in your own account.
One CloudFormation stack creates its own VPC, the cache bucket, IAM roles and the control plane. For an existing VPC, GitHub Enterprise Server or IAM permission boundaries, use the Terraform / OpenTofu module; Fleet installs with its own Terraform module.
Register the private GitHub App from the stack's outputs; on an org, that usually takes an owner. Runners are registered per job, and none waits idle between jobs.
Swap a single line in your workflow. Every existing action, cache step, and secret keeps working untouched.
# the entire migration, in one diffruns-on: ubuntu-latestruns-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64A job is queued, an instance boots in your account, the job runs, and the instance is terminated. In the burst benchmark, the median wait from queued to running was 16–22s (run by RunsOn, which sells one of the runners measured). If GitHub must not call into your account at all, Fleet, installed with the Terraform module, runs the same loop pull-based: no inbound webhook, no public endpoint.
the trial runs the real product in your account · card at checkout, nothing charged for 15 days · then from €300 / $350 a year · run the numbers on your bill