StarSling vs RunsOn runners for GitHub Actions

Q: What does runs-on do in a GitHub Actions workflow?

runs-on: is the workflow key that selects the runner a job runs on, by label. RunsOn reads it as a query for an EC2 instance, and a StarSling job uses it to select starsling-ubuntu-24.04.

StarSling is AI-native CI for GitHub Actions: drop-in Ubuntu runners plus agents that open optimization PRs for your workflows.

RunsOn launches ephemeral EC2 runners inside your own AWS account, picked per job by a runs-on label, under a flat annual license with the compute on your AWS bill. StarSling runs managed Ubuntu runners for you, billed per minute, and adds AI agents that open workflow optimization PRs. Choose around where you want the compute to live and how you want to improve the workflow. For new accounts, AI-powered optimization PRs are only available to customers on paid plans and are not enabled by default.

View in Markdown

Selecting a runner

How StarSling works

Last updated 2026-09-27

Head to head

How RunsOn runners work

RunsOn deploys into your AWS account from a CloudFormation template or its Terraform module, which brings up the VPC, cache bucket, IAM roles and scheduler together. A GitHub App on your organization registers an ephemeral runner when a job asks for one, and the instance ends with the job.

A job selects its machine through the runs-on label, which RunsOn treats as a query: constraints such as CPU count, instance family and image are resolved when the instance launches. RunsOn tries spot capacity first and falls back to on-demand.

RunsOn licensing and billing

RunsOn charges a flat annual license per legal entity, covering the GitHub organizations and AWS accounts you own or control. The EC2 instances, S3 cache bucket and EBS volumes are billed by AWS to your account, with compute billed per second. A free license covers nonprofit, open-source, educational and personal non-commercial projects.

StarSling bills per runner minute, from $0.004/min (2 vCPU) to $0.128/min (64 vCPU), with queue time never billed and no seat fees. Use the GitHub Actions pricing guide to model your own workload, and Self-hosted GitHub Actions runners for the cost of running runners in your own cloud.

Try StarSling on one Linux workflow

Choose a representative Ubuntu job with a clear success condition. Keep the same commit, tests and build outputs across the comparison, and record queue time separately from execution time.

Install the StarSling GitHub App for the trial repository, then choose a label from StarSling runner sizes. The default starsling-ubuntu-24.04 selects 4 vCPU; match the size to the RunsOn instance you are comparing.
Prepare a small workflow PR. Where the job uses RunsOn label options such as extras=s3-cache, restore GitHub Actions caching in the same PR. Preserve required check names, permissions and test commands.
Run repeated cold-cache and warm-cache trials. Compare completed work, error rate, queue time, execution time and the full cost: the runner minutes on one side, the license plus the AWS bill on the other.
Keep the original workflow revision available. Roll back the trial by reverting the runner label and any cache edits together.

Workflow optimization you can inspect

Read the public Mastra optimization PRs and results and Better Auth case study to see changes to real workflows, the measured windows and the work behind each result. Use those examples to identify a testable improvement in your own pipeline.

For new accounts, AI-powered optimization PRs are only available to customers on paid plans and are not enabled by default.

Best fit

Choose StarSling if

Teams running Ubuntu GitHub Actions jobs who want managed runners and reviewable PRs that improve the workflow's caching, installs and test execution. For new accounts, AI-powered optimization PRs are only available to customers on paid plans and are not enabled by default.

Choose RunsOn if

Teams that want runners inside their own AWS account, with compute on their AWS bill and a choice of EC2 instance per job, including Windows and GPU instances.

FAQ

What does runs-on do in a GitHub Actions workflow?

runs-on: is the workflow key that selects the runner a job runs on, by label. RunsOn reads it as a query for an EC2 instance, and a StarSling job uses it to select starsling-ubuntu-24.04.

Can I move from RunsOn to StarSling by changing runs-on?

Start with an Ubuntu job and a StarSling label. If the workflow uses RunsOn label options such as extras=s3-cache, restore GitHub Actions caching in the same trial PR. Test the resulting workflow and keep the original revision for rollback.

How should I compare RunsOn, Ubicloud and StarSling?

Start with where the compute should run, the operating systems you need and how each one bills, then run the same job on matched resources. This page covers RunsOn; StarSling vs Ubicloud runners for GitHub Actions covers Ubicloud. Measure runtime and total cost across repeated cold-cache and warm-cache runs before choosing.

Does installing StarSling enable AI optimization PRs?

For new accounts, AI-powered optimization PRs are only available to customers on paid plans and are not enabled by default.

Sources

RunsOn: self-hosted GitHub Actions runners on AWShttps://runs-on.com/
Read 2026-09-28
RunsOn pricinghttps://runs-on.com/pricing/
Read 2026-09-28

Other comparisons

Compare StarSling with the other runner and CI options teams evaluate.

References

Get started

Try the AI-native runner.

One line to install. Faster runs on day one, and agents that keep optimizing your pipeline through reviewable PRs.

Get Started For Free Install the ci-speedup skill