quickstart →

The story behind runs-on.

Teams on GitHub Actions want faster builds, a smaller bill, and control over where their code and secrets go. RunsOn gives them ephemeral runners in their own AWS account, without a runner platform to babysit.

How it came about

Across years of freelance work I wrote a lot of GitHub Actions workflows. I like Actions, but the same three things kept getting in the way.

The friction

every project
  • slow Workflows over 5 minutes deserved faster runners.
  • expensive Once the free minutes ran out, the bill grew fast.
  • gated Static IPs and Arm runners sat behind higher tiers.

What was out there

none checked every box
  • GitHub-hosted Expensive, and slow.
  • third-party SaaS Someone else's machines handled your code and secrets.
  • ARC Needed Kubernetes, and the expertise to run it.
  • hand-rolled Self-hosted setups needed constant upkeep.
So I built it:

ephemeral EC2 instances that spin up per job, run in your own AWS account, and self-terminate when done. Simple enough to deploy in 10 minutes, scalable enough to handle thousands of jobs per hour.

Where it is now

3M+

jobs a day on RunsOn runners, one ephemeral instance per job.

900+

companies running GitHub Actions in their own AWS accounts.

75

releases since 2023, paid for by customer licenses, not investors.

The code

RunsOn is partly open source and developed in the open. The full server and agent source comes with the Enterprise license.

runs-on/runs-on

Thanks

To the early adopters, and especially Alan, the first sponsor, and CFS, for helping find and fix the early scalability issues, work that got RunsOn ready for everyone else.

Your account. Your bill. ~10 minutes to set up.

Deploy one CloudFormation stack and watch the first job land on a spot instance you own.