RunsOn alternatives: keep the AWS account, or hand it over

By Kaveh Alemi·Latchkey

RunsOn alternatives split on a single question, and the per-minute tables that dominate this market answer the wrong one: does the compute stay in your AWS account, or does it leave? RunsOn charges a licence from EUR 300 a year and states that the compute is your AWS bill, not ours, with no markup, so what you are really weighing is a spot-priced EC2 bill you operate against a metered minute somebody else operates.

Two camps of alternative: compute that stays in your own cloud account, and compute that leaves it — The alternatives split by where the machines live, not by rate. Licence tiers and rates read from each vendor page on 2026-09-21.

RunsOn is a licence and a CloudFormation stack. You run it in your own AWS account, it starts EC2 instances on demand to serve your jobs, and the instances are billed by AWS per second at spot or on-demand prices. The licence tiers published on its pricing page are Starter from EUR 300 a year for under 50,000 runners a month, Growth at EUR 900 under 200,000, Scale at EUR 1,800 under 500,000 and Enterprise at EUR 3,600 above that, with a free tier for nonprofit, open-source, educational and personal non-commercial use in exchange for a public acknowledgement linking back.

That is a genuinely cheap way to run a lot of CI, and it is cheap because you are doing the operating. Every alternative below is a different answer to how much of that operating you want to keep.

Read the tier unit before anything else

RunsOn's tiers are counted in runners a month, not minutes a month, and that one word changes which repositories are cheap on it. A runner is a machine started to serve a job, so a workflow with a 30-leg matrix consumes 30 runners in one run regardless of how long each leg takes. A team with short, wide pipelines crosses into the next tier at a fraction of the compute of a team with a few long builds.

Work out your own number before you price anything else: total workflow jobs a month, not minutes. If that number is comfortably under 50,000 the licence is EUR 300 a year and is effectively a rounding error against the EC2 bill, which is the point. If it is 300,000, the licence is EUR 1,800 and is still probably a rounding error, which is also the point. The licence is rarely what makes this decision.

The alternatives that keep the machines in your account

Three options keep the compute inside infrastructure you control, which is usually the reason a team chose RunsOn in the first place: a compliance boundary, a VPC with private resources in it, or an existing committed-spend agreement with a cloud provider that CI minutes can be spent against.

They differ in what the vendor supplies and in whether a meter comes back. WarpBuild's bring-your-own-cloud mode is a flat $0.002 a minute for Linux runners in your AWS, GCP or Azure account, so the per-minute meter returns but the machines do not leave. Actuated is a flat per-server licence, $150 for the first and $125 for each additional per month, on hardware you supply that is either bare metal or supports nested virtualization, with a Firecracker microVM per build. Actions Runner Controller is GitHub's own open-source controller, free of licence and expensive in cluster operations.

Alternative	What you pay the vendor	What the vendor supplies	What you operate	Isolation
RunsOn	EUR 300 to 3,600 a year by tier	The controller, AMIs and binaries	AWS account, quotas, spot capacity	One EC2 instance per job
WarpBuild BYOC	$0.002 a minute, flat	Control plane, images, cache	The cloud account and its limits	One VM per job in your account
Actuated	$150 first server, $125 each after, monthly	Control plane and the CI image	The physical or metal hosts	A Firecracker microVM per build
Actions Runner Controller	Nothing	An open-source controller	Kubernetes, scaling, images, upgrades	One pod per job

The alternatives that take the account away

If the AWS account was never the point, and RunsOn was chosen because it was cheap, then the fully managed vendors are a smaller decision than they look. You change a label, the machines are somebody else's, and there is no stack to upgrade. What you pay for that is a per-minute rate instead of a spot-priced EC2 bill.

At the 2 vCPU with 8 GB shape, published Linux x64 rates on 2026-09-21 were $0.0012 at Ubicloud, $0.0025 at Latchkey, $0.004 at Blacksmith and at WarpBuild managed, $0.004 prepaid at Namespace, and $0.006 at Depot and at GitHub-hosted. Against a spot EC2 instance those rates are not obviously good, and against an on-demand instance plus the EBS volume plus the S3 cache traffic they frequently are. The honest way to settle it is your own AWS bill for the last month divided by your own job-minutes for the same month, which is a number nobody but you can compute.

What you actually give up by leaving

Four things, and three of them are structural rather than financial. The compute leaves your account, which ends any argument that CI never touches a third party. Private resources reachable only from inside the VPC stop being reachable without a tunnel you now maintain. Committed cloud spend stops being usable for CI, which for a team with a large commitment can be the entire case.

The fourth is the rate at volume. Nothing metered beats a flat licence plus spot instances once the volume is large, and RunsOn's own framing is honest about why: it adds no markup, so you get the wholesale price of compute and pay a fixed fee for the software. A comparison that ignores that is selling you something.

And what you stop being responsible for

Concede the other direction too, because it is the reason people look. Running runners in your own AWS account means owning EC2 quotas, AMI refreshes, spot interruption handling and a CloudFormation stack that needs upgrading. None of that is difficult and all of it is unbounded: it turns up at the worst time, in a region, on a day when the person who set it up is away.

It also means the runner fleet is yours to debug when a job cannot start. A managed vendor takes that class of problem off you, and so does GitHub-hosted. What owning the fleet does not touch either way is a failure inside the job that is not about your code, which is a different category and is covered in self-healing CI explained.

How to decide

Four questions, in order. The first one that gets a hard answer ends the exercise, which is why it is first.

Must the compute stay in your own cloud account, for compliance, for private network access, or to consume committed spend? If yes, the shortlist is RunsOn, WarpBuild BYOC, Actuated and Actions Runner Controller, and no per-minute table applies.
Count workflow jobs a month, not minutes, and find your RunsOn tier. If the licence is a rounding error against your EC2 bill, the licence is not the reason to leave.
Divide last month's CI-attributable AWS bill by last month's job-minutes. That is your real per-minute cost, and it is the only number comparable with a vendor rate card.
Price the operating work honestly: hours a month on AMIs, quotas, spot capacity and stack upgrades. If that number is small and stable, staying is the cheaper answer at almost any volume.

What is not on this page

No run of ours backs any of it, and there is no benchmark here. A comparison between a spot EC2 instance you chose and a vendor machine you did not is not a fair fight in either direction: the result would mostly report which instance type we picked and which region it sat in, and would be valid for nobody else.

So the numbers above are published tiers and rates with dates, and the one calculation that matters is left to you because only you have the inputs. For the vendor-by-vendor rate view with free tiers and billing granularity, the full matrix is in GitHub Actions runner alternatives; for the structural view of who runs what, see managed GitHub Actions runners compared.

Frequently asked questions

How much does RunsOn cost?

A licence, plus your own AWS bill. Its published tiers are Starter from EUR 300 a year for under 50,000 runners a month, Growth at EUR 900 under 200,000, Scale at EUR 1,800 under 500,000 and Enterprise at EUR 3,600 above that, with a free tier for nonprofit, open-source, educational and personal non-commercial use. The compute is billed directly by AWS, and RunsOn states that it adds no markup.

Are RunsOn tiers counted in minutes?

No, in runners a month, which is a count of machines started rather than time consumed. A 30-leg matrix consumes 30 runners in one workflow run whatever each leg costs in time. That makes short, wide pipelines cross tiers much sooner than long, narrow ones, and it is the first number to work out when pricing it.

What is the closest alternative to RunsOn that keeps compute in my own cloud?

WarpBuild in bring-your-own-cloud mode, at a flat $0.002 a minute for Linux runners in your AWS, GCP or Azure account, or Actuated at $150 a month for the first server and $125 for each additional on hardware you supply. GitHub's own Actions Runner Controller is the no-licence option and moves the cost into operating a Kubernetes cluster.

Would a managed runner be cheaper than RunsOn on AWS?

Only your own bill answers that. Divide last month's CI-attributable AWS cost, including EC2, EBS and S3 traffic, by last month's job-minutes, and compare the result with published rates: $0.0012 at Ubicloud, $0.0025 at Latchkey, $0.004 at Blacksmith, $0.006 at Depot and GitHub-hosted, all read 2026-09-21. On spot capacity RunsOn usually wins at volume; on on-demand with idle time, often not.