The GitHub Actions runner alternative that runs in your own AWS account.
BuildJet is shutting down. WarpBuild, Depot and Namespace rent you their machines by the minute. RunsOn starts a fresh EC2 instance for each job inside your own AWS account, on Spot: AWS bills you for the instance at cost, and RunsOn is a flat license from €300 a year. Your code, secrets and caches never leave your VPC.
One CloudFormation stack, about 10 minutes to the first job. The trial runs the real product in your account.
- GitHub-hosted $0.0120 8.3× more
- Blacksmith $0.0080 5.5× more
- WarpBuild $0.0080 5.5× more
- Namespace * $0.0060 4.1× more
- Ubicloud $0.0025 1.7× more
- RunsOn $0.0015 billed by AWS
*Namespace's price is for 4 vCPU with 8 GB of RAM; the others have 16 GB. RunsOn's figure is m8a.xlarge spot in us-east-1 (7-day average of the cheapest zone) plus a 30 GB gp3 volume. The license (from €300 / $350 a year) is flat, so it isn't in the per-minute figure. Hosted prices are the standard tier from each provider's pricing page, checked 2026-10-03. Every size and platform →
Why the gap is this wide.
A hosted runner company buys a fleet of servers, keeps part of it idle to absorb your bursts, and prices every minute to cover both plus its margin. RunsOn owns no runners. Each job gets an instance in your account that exists only while the job runs, AWS bills it at cost, and your credits and commitments apply. The license steps up with runner volume, never with minutes.
What comes with the stack
- Any EC2 instance type per job: x64, arm64, GPU or Windows
- Docker layer caching, and an S3 cache with no 10GB cap
- Hot warm pools for jobs that must start in under 6 seconds
- Static egress IPs, and runners inside your VPC
- Spot first, with automatic on-demand fallback and retry
- Per-job cost reporting and a daily AWS budget
Who you're buying from
RunsOn is bootstrapped. There are no investors to pay back, only customers, so the roadmap follows what the people running it ask for. There's no support tier between you and the code: a bug report goes straight to engineering, and fixes often ship within days.
“Very easy to set up, very stable. Documentation is really good and the support is reactive. RunsOn allowed us to provide any kind of runner, while being confident that the pricing would be okay.”
Rémy G., Infrastructure lead Coming from BuildJet, WarpBuild, Depot or Namespace.
The runner images are ported from GitHub's own templates, so your
steps stay as they are. You change the runs-on: label one job at a time, and anything you haven't moved keeps
running where it is.
BuildJet
BuildJet announced in February 2026 that it is shutting down, so
you're moving anyway. Per job, the move is one
runs-on: label:
- buildjet-4vcpu-ubuntu-2204
+ runs-on=${{ github.run_id }}/runner=4cpu-linux-x64WarpBuild
WarpBuild charges $0.0080 a minute for a 4-vCPU runner. The same size on RunsOn is $0.0015 of EC2 on your own AWS bill, and the license is a yearly fee that never counts minutes.
Depot
Depot sells fast Docker builds on its own machines. RunsOn ships Docker layer caching and an uncapped S3 cache in the stack, on instances inside your VPC, so image layers and build secrets stay in your account.
Namespace
Namespace rents fast machines by the minute. On RunsOn the job's label picks the EC2 instance type, so a job that needs the fastest core asks for it and the others stay on cheaper ones. The CPU benchmark ranks both. See the live ranking →
“We did a review of alternative solutions, from Buildjet to Warpbuild, and we ended up with RunsOn. Right now it is the best compromise: runners boot fast, and it's very cost efficient at scale.”
Where your code runs.
Ubicloud, Blacksmith, Namespace, Depot and WarpBuild run your jobs on their machines, so your source and build secrets leave your account on every job. On RunsOn the job runs on an EC2 instance in your own VPC, under your own IAM.
what stays inside
Nothing leaves. The runners sit in your VPC under your IAM roles, and no third party handles the code.
what leaves your account
Fine for many teams. Not an option when compliance or data residency says the code stays in your account.
What makes RunsOn different.
Three things a hosted runner can't give you, because the machines are theirs.
Jobs stay in your AWS account
The control plane, the runners, the cache and your secrets live inside your account. GitHub sends in the job request, and the job runs behind your own network boundary.
Use the EC2 shape your job needs
The label says what the job needs: a CPU count, an architecture, an instance family, a bigger disk. RunsOn resolves it when the job starts.
runs-on: runner=2cpu-linux-x64
runs-on: runner=16cpu-linux-arm64
runs-on: family=g6e.xlarge
runs-on: volume=80gbPay AWS for compute, RunsOn for the license
AWS bills the instances at its own rate, and your credits and commitments apply. RunsOn is a flat yearly license that never counts minutes.
What each option trades.
Cache speeds and boot times change every quarter, and the benchmarks track them. Where the work runs, who operates the runners and how compute is billed stay put.
| option | where it wins | the tradeoff |
|---|---|---|
| GitHub-hostedruns on GitHub | No setup, and good for small standard jobs. | Few instance sizes, the highest per-minute price, and code runs on GitHub's infrastructure. |
| Hosted providersWarpBuild, Depot, Namespace, Blacksmith, Ubicloudruns on vendor | Managed runners with nothing to operate. | Your jobs run on the vendor's machines, and every minute carries the vendor's margin. |
| BuildJetruns on vendor | Showed early that GitHub Actions runners could be cheaper and faster. | Shutting down, announced February 2026. Its users have to move their workflows to new runners. |
| RunsOnrecommendedruns in your account | Ephemeral EC2 runners in your AWS account, any EC2 shape, AWS credits and commitments apply. | AWS only, and you deploy a CloudFormation stack before the first workflow runs. |
| Actions Runner Controllerruns in your cluster | Fits teams already standardized on Kubernetes. | You operate the cluster, the autoscaling and the runner images. |
| AWS CodeBuildruns in your account | Native AWS service and AWS procurement path. | Its own runner model and compute types, with a narrower choice of instances. |
The benchmarks are public.
The same builds run on every provider every three days, and each result is published with its cost. 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.
Build benchmarks
The same Rust, TypeScript and Docker builds on every provider: time and cost per build, queue time under a burst, and how much a runner varies from run to run.
See the overview → passmarkCPU performance
Single-thread and all-core PassMark for each provider's runners on x64 and arm64, with the CPU each job got.
See CPU results → 4 GB restoreCache performance
How long a runner takes to restore a 4 GB cache, per cache action. With actions/cache, RunsOn restores 1.8–2.0× faster than GitHub-hosted at the same size.
See cache results → fioI/O performance
Small-read latency, synced writes and throughput of the disk under the job workspace, for builds where storage is the bottleneck.
See I/O results →When RunsOn is the wrong fit.
You don't use AWS
RunsOn runs only on AWS. On GCP or Azure, a hosted provider or Actions Runner Controller fits better.
You need macOS runners
EC2 Mac instances carry a 24-hour minimum allocation, which doesn't fit one instance per job. Several hosted providers sell macOS runners.
You want zero setup
A hosted provider is a signup and a label. RunsOn is a CloudFormation stack in your account first, about 10 minutes.
GitHub Actions runners, question by question.
Cheapest runners
RunsOn's Linux runners cost 5–11× less per minute than GitHub-hosted: EC2 Spot in your own AWS account, where your credits apply. Among hosted providers, Ubicloud has the lowest price for a 4-vCPU Linux runner, $0.0025 a minute against $0.0015 on RunsOn.
Fastest runners
Speed depends on the CPU a provider runs, not only on its vCPU count. The CPU benchmark scores each provider's runners on x64 and arm64, single-thread and all cores. See the live benchmark →
GPU support
RunsOn runs GPU jobs on EC2 GPU instances, NVIDIA T4 to H200, picked in the job label and billed by AWS. They work on every GitHub plan, including free.
Windows support
RunsOn has Windows Server runners on EC2, selected with an image label such as windows25-full-x64.
macOS builds
RunsOn has no macOS runners. EC2 Mac instances carry a 24-hour minimum allocation, which doesn't fit one instance per job. Hosted providers that pool Mac hosts across customers sell macOS runners.
Queue time
In the public burst benchmark, 15 jobs queued at once, a RunsOn job's median wait from queued to running was 17–24s, depending on the runner type (28 x64 types measured). Hot warm pools bring the wait under 6 seconds where it matters. Queue times per provider →
Best for enterprise
RunsOn deploys in your AWS account, inside your VPC and under your IAM, and runs 3M+ jobs a day across 900+ companies. Actions Runner Controller suits teams standardized on Kubernetes, and AWS CodeBuild fits AWS-native procurement.
Hosted vs self-hosted
GitHub-hosted runners need no setup and suit short, standard jobs. Self-hosted runners cost less per minute and let you pick the machine, which matters for CPU-heavy and long-running jobs.
Keep CI in your own account.
One CloudFormation stack, a private GitHub App for your org, about 10 minutes to the first job. The trial runs the real product in your account for 15 days, then it's a flat license from €300 / $350 a year.