DEV Community

RunsOn GitHub Actions runners explained

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. 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-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
Label forms and key descriptions quoted from RunsOn: runner labels, read 21 September 2026. The two bills, and where they cross The licence is metered by runne...

Powered by Readybot.io