RunsOn GitHub Actions runners explained

Q: Is RunsOn a managed runner service?

No, and the distinction matters for the bill. RunsOn installs a control plane into your own AWS account and launches EC2 instances there, so Amazon invoices you for the compute and RunsOn invoices you for a licence. A managed runner vendor gives you one metered line and owns the capacity behind it.

Q: How much does RunsOn cost?

The published Commercial Starter licence is from 300 euros a year and covers fewer than 50,000 runners a month, rising to 3,600 euros a year at the Enterprise tier for 500,000 or more. On top of that you pay AWS directly for spot or on-demand instances, billed per second, with no RunsOn markup. Non-commercial use is free with a public acknowledgement.

Q: Which operating systems can RunsOn launch?

Linux on x64 and arm64, Windows, and GPU instances, all as EC2 instances. The documented platform list does not include macOS. Any job needing Xcode or the iOS simulator therefore stays on GitHub-hosted macOS or on a vendor that sells Mac hardware, and RunsOn takes the rest of the pipeline.

Q: What does the RunsOn CloudFormation stack put in my AWS account?

A control plane, a least-privilege IAM role for the service, and a private GitHub App that exists only in your account. Flex adds the webhook path through API Gateway, Lambda and SQS; Fleet instead runs its control plane on ECS Fargate with a pull-based connection and no inbound webhook. The runners themselves are ordinary ephemeral EC2 instances.

Q: Is RunsOn cheaper than GitHub-hosted runners?

At volume, yes, because the licence is flat and your compute is at spot prices. Ten thousand Linux minutes a month costs $720 a year at GitHub's $0.006 standard rate, which already exceeds the Starter licence before compute. At a few hundred minutes a month the fixed fee makes it more expensive, and the operational time it adds is not on either invoice.

By Kaveh Alemi·Latchkey

RunsOn GitHub Actions runners are ordinary EC2 instances that RunsOn launches inside your own AWS account, so you pay RunsOn a flat annual licence and pay Amazon for every instance-second separately. That split is the whole product decision: the licence does not grow with your minutes, and the compute line does, which makes RunsOn expensive for a small team and hard to beat for a large one.

GitHub bills one metered line; RunsOn splits into a flat yearly licence plus a metered AWS EC2 line — Where each bill comes from. RunsOn prices a licence by runners launched per month and states that the compute is "your AWS bill, not ours", read from runs-on.com/pricing on 21 September 2026.

Almost every other vendor in this area sells you a minute. RunsOn sells you a control plane and leaves the minute on your own cloud bill, which means the comparison against GitHub-hosted runners is not a rate against a rate. It is a fixed cost against a variable one, and the answer flips at a volume you can calculate.

This page covers what the installation actually puts in your account, how a workflow asks for a machine, what the two bills look like, and the operational work you are taking on by moving the runners inside your own perimeter.

What actually gets installed

RunsOn is deployed as infrastructure, not subscribed to as a service. The quickstart describes Flex as installing "with a single CloudFormation stack in about 10 minutes", which creates "a dedicated, least-privilege IAM role for the service" and a GitHub App that the documentation is explicit about: "this creates a private GitHub App that lives only in your AWS account".

That sentence is the reason this page exists. A private GitHub App means no third party holds a token against your organisation, which is the single strongest argument for RunsOn over any hosted runner vendor, and it is also why nobody else can page themselves when your runners stop launching. The trade is stated plainly on both sides.

There are two shapes. Flex provisions one ephemeral EC2 instance per job, driven by workflow_job webhooks that arrive "through API Gateway and Lambda" and queue in SQS. Fleet is the Terraform-defined version, where a fleetd control plane "runs on ECS Fargate and uses a pull-based connection to GitHub", with "no inbound webhook, API Gateway, or SQS queue in the demand path". Flex is for teams whose jobs want different machines; Fleet is for a platform team that wants the runner shape under review.

How a workflow asks for a machine

The migration is a label change, which is the part RunsOn shares with every managed vendor. The documentation gives the Flex form as a single compound label, and the keys inside it are what you would otherwise express in an autoscaler configuration: family for the EC2 type or family, cpu and ram as fixed values or ranges, image for the AMI, volume as size:type:throughput:iops, and extras for features such as s3-cache, ecr-cache, efs, tmpfs and otel.

Two defaults are worth knowing before the first run. Spot is on by default, documented as "whether to attempt to use spot pricing (default: true)", which is where the low compute cost comes from and also where the interruptions come from. SSH access is off by default. The runs-on=${{ github.run_id }} prefix is not decoration: it namespaces the runner to the run that asked for it.

Platform coverage is Linux on x64 and arm64, Windows, and GPU instances. There is no macOS, which rules RunsOn out of an iOS pipeline entirely and is the clearest single filter on whether this product fits your repository.

.github/workflows/ci.yml

# GitHub-hosted
jobs:
  test:
    runs-on: ubuntu-latest

# RunsOn Flex: the compound label is the whole migration
jobs:
  test:
    runs-on: runs-on=${{ github.run_id }}/cpu=4/ram=16/family=m7a+m7i-flex/image=ubuntu22-full-x64

# RunsOn Fleet: the workflow names a fleet, Terraform owns the shape
jobs:
  test:
    runs-on: runs-on/fleet=linux-small/env=production

The two bills, and where they cross

The licence is metered by runners launched per month, not by minutes. The published Commercial Starter tier is "from 300 euros / year" and covers "< 50k runners / month"; the Enterprise tier is "3,600 euros / year" for "500k+ runners / mo". Non-commercial use is free, described as "the full product, at no cost", in exchange for a public acknowledgement linking back to the vendor. A commercial trial runs 15 days with payment details collected at checkout.

The compute is separate and RunsOn does not touch it: the pricing page describes "spot or on-demand instances, billed per second by AWS" and says the compute line is "your AWS bill, not ours". So the total is a flat number plus a number you already know how to forecast, and neither half is a per-CI-minute rate you can quote in a comparison table.

Do the arithmetic on your own volume rather than on a headline. Ten thousand Linux minutes a month at GitHub's standard 2-core rate of $0.006 is $60 a month, or $720 a year, and that single line already exceeds the Starter licence before a single instance-hour is added. Run a hundred thousand minutes and GitHub bills $7,200 a year while the licence has not moved. The flat fee is the entire argument, and it is an argument that gets stronger the more CI you run.

What you are taking on

Everything the stack cannot do for itself becomes yours. EC2 service quotas in the region, spot capacity when a family runs short, AMI currency, the VPC and its egress path, and the pager at three in the morning when a workflow queues because an account limit was reached rather than because anything is broken. None of that appears on either bill and all of it appears on somebody's week.

That is the honest line between this product and a managed runner. Latchkey sells the opposite trade: nothing to own in your cloud, a published $0.0025 a minute at 2 vCPU with 8 GB, and no EC2 account of your own in the path between a push and a build. RunsOn genuinely wins on cost at volume, because a flat licence plus spot compute beats any metered rate once the minutes are large enough, and it wins outright when the requirement is that no third party holds credentials against your repositories.

Pick on that axis and not on the rate card. If your constraint is the AWS account you are not allowed to have, or the operations time you do not have, the cheaper line on paper is not the cheaper line in practice. Self-hosted versus managed runners works through the same decision without a vendor attached, and RunsOn against Blacksmith is the head-to-head.

Key takeaways

RunsOn runs jobs on EC2 inside your own AWS account, so there are two bills: a flat licence and your own compute.
The licence is metered by runners launched per month, from 300 euros a year at the Starter tier.
Installation is one CloudFormation stack and a private GitHub App that never leaves your account.
Spot is on by default, and there is no macOS runner at any tier.

Frequently asked questions

Is RunsOn a managed runner service?

No, and the distinction matters for the bill. RunsOn installs a control plane into your own AWS account and launches EC2 instances there, so Amazon invoices you for the compute and RunsOn invoices you for a licence. A managed runner vendor gives you one metered line and owns the capacity behind it.

How much does RunsOn cost?

The published Commercial Starter licence is from 300 euros a year and covers fewer than 50,000 runners a month, rising to 3,600 euros a year at the Enterprise tier for 500,000 or more. On top of that you pay AWS directly for spot or on-demand instances, billed per second, with no RunsOn markup. Non-commercial use is free with a public acknowledgement.

Which operating systems can RunsOn launch?