Spot compute billed at cost by AWS, a yearly license that never meters your minutes, one CloudFormation stack to install. Then it just runs.
Free for 15 days. Step one gets you a trial key: we ask for a card and don't charge it. Then from €300 / $350 a year, free for non-commercial use. Pricing
build:− runs-on:ubuntu-latest+ runs-on:+ - runs-on=${{ github.run_id }}+ - family=m8+r8+ - cpu=4+ - extras=s3-cache+ steps:+ - uses: runs-on/action@v2 - ...
Any 8th-gen general-purpose or memory-optimized instance with 4 vCPU, whichever has spot capacity at launch. actions/cache restores from S3 in your VPC.
build:− runs-on:ubuntu-latest+ runs-on:+ - runs-on=${{ github.run_id }}+ - family=t8i+ - cpu=2 steps: [...]
A burstable t8i at 2 vCPU, for linters, type checks and jobs that mostly wait on something else.
build:− runs-on:ubuntu-latest+ runs-on:+ - runs-on=${{ github.run_id }}+ - family=c8a+c8i+ - cpu=16+ - extras=s3-cache+ steps:+ - uses: runs-on/action@v2 - ...
16 vCPU of compute-optimized 8th-gen, with the build cache restored from S3 in your VPC.
build:− runs-on:ubuntu-latest+ runs-on:+ - runs-on=${{ github.run_id }}+ - family=m8+c8+ - cpu=8+ - extras=ecr-cache+ steps:+ - uses: runs-on/action@v2 - ...
Layers go to an ephemeral ECR registry in your account (turned on in the stack), so the next build pulls them instead of rebuilding. Point Buildx's cache at it: see the Docker caching docs.
build:− runs-on:ubuntu-24.04-arm+ runs-on:+ - runs-on=${{ github.run_id }}+ - family=c9g+c8g+ - cpu=8+ - image=ubuntu24-full-arm64 steps: [...]
Graviton at 8 vCPU, the newer c9g or c8g: arm64 binaries and images built natively, not emulated.
build:− runs-on:ubuntu-latest+ runs-on:+ - runs-on=${{ github.run_id }}+ - family=m8i+c8i+ - cpu=4+ - nested-virt steps: [...]
Nested virtualization gives the job KVM, for Android emulators and VM-based end-to-end tests. It needs the Intel 8th-gen families.
build:− runs-on:windows-latest+ runs-on:+ - runs-on=${{ github.run_id }}+ - family=m8i+ - cpu=4+ - image=windows25-full-x64 steps: [...]
Windows Server 2025, from GitHub's own image templates. The spot price includes the Windows license.
They use runs-on:
3M+ jobs a day 900+ companies
A month of 16-core Linux builds. On RunsOn, AWS bills the minutes at cost and the license is one flat line.
One month of CI billed two ways, for 150,000 minutes of 16-core Linux jobs. GitHub-hosted: $6,300.00. RunsOn: $691.56, of which $616.50 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 776 minutes.
| 16-core Linux runner 150,000 min × $0.042 | $6,300.00 |
|---|
| EC2 spot · 16-core Linux 150,000 min × $0.00411 | $616.50 |
|---|---|
| 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 →
RunsOn's best-value 4 vCPU machine for each build, against GitHub's 4 vCPU runner.
Same images, same actions, same cache steps. The jobs move to EC2 in your AWS account, at what AWS charges for the minutes.
price your own minutes →| dimension | GitHub-hosted | RunsOn |
|---|---|---|
| price | per minute, at GitHub's rate | AWS spot at cost, 5–13× 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, a fresh VM per job |
Your code stays in your VPC and the compute goes on your AWS bill, with your credits and commitments.
hosted runners compared →| dimension | hosted vendor | RunsOn |
|---|---|---|
| price | a per-minute list price | EC2 spot at cost: $0.0044/min for a 16 vCPU c8id.4xlarge, plus a yearly license |
| code runs on | usually the vendor's machines; bring-your-own-cloud plans add a per-minute fee | your AWS account and VPC |
| control plane | the vendor's | in your AWS account |
| machines | the vendor's shapes | any EC2 instance, x64 · arm64 · GPU |
One EC2 instance per job instead of scale sets on nodes you size and patch. Windows and GPU are a label, not another node group.
the full ARC comparison →| dimension | ARC | RunsOn |
|---|---|---|
| prerequisite | a Kubernetes cluster, plus Helm | one CloudFormation stack |
| scaling | scale sets on nodes you size | one EC2 instance per job |
| images | containers you build and patch | AMIs from GitHub's templates, kept current |
| idle cost | node pools sized for peak | no runners between jobs; warm pools opt-in |
| runner groups | scale sets inside the cluster | Fleet: fleets in Terraform, no inbound endpoint |
Each one is a label away.
Add extras=s3-cache and a runs-on/action@v2
step: actions/cache then reads and writes an S3 bucket in
your account, in the same 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: 26s against 59s at 2, 19s against 37s at 4, 16s against 28s at 8 vCPU. cache benchmark →
Turn on the ephemeral ECR registry in the stack, add
extras=ecr-cache and point Buildx at
type=registry: layers stay in your account, so the next build pulls them instead of rebuilding.
type=gha and type=s3 work too.
Jobs run on spot by default. With no spot capacity, the instance launches on-demand instead, and a job that loses its spot instance mid-run is rerun, with new capacity launched on-demand.
KVM on Linux, Hyper-V on Windows, from one label. Android emulators, VM-based end-to-end suites and Windows containers run as they would on a workstation.
Also in the box: per-job cost reportingstatic egress IPswarm poolssticky disksyour own AMIsGPU
“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 “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 “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 runs-on: ubuntu-latest becomes runs-on: runs-on=${{ github.run_id }}/family=m8+r8/cpu=4. 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.CloudFormation One stack, about ten minutes: its own VPC, the cache bucket, IAM roles and the control plane.
Terraform / OpenTofu For an existing VPC, GitHub Enterprise Server, permission boundaries, or Fleet. Flex module · Fleet module
Install the private GitHub App from the stack's outputs. On an org, that usually takes an owner.
Swap runs-on: ubuntu-latest for a RunsOn label. Actions,
cache steps and secrets keep working.
Then, for every job, an instance boots in your account, runs the job, and is terminated. Two ways to run that loop. Flex vs Fleet →
The real product, in your account, free for 15 days. Then from €300 / $350 a year. Run the numbers on your bill →