Self-hosted GitHub Actions runners for AWS
- 400k+
- daily jobs
- Zero
- k8s headaches
- 90%
- cost savings
Faster build times, shocking cost savings
Section titled “Faster build times, shocking cost savings”Easy to setup. 85% cheaper than GitHub Actions.
Used and supported by great companies
Section titled “Used and supported by great companies”I've been testing Kubernetes with ARC: more complex, each runner takes ~25 seconds to boot (on an existing node), far less attractive than the simplicity of RunsOn.
With RunsOn, we have increased CI/CD performance and reliability at a fraction of the cost of official or private hosted runners – it's a no-brainer for any DevOps team using GitHub actions at scale.
The only self-hosted solution that just works
Section titled “The only self-hosted solution that just works”We’ve all been there: not satisfied with the slow and pricey managed GitHub Actions runners, we start spawning our own self-hosted runners on dedicated machines.
Then we realize it requires maintenance for patching, disks filling up, secrets exposed across jobs, so we spend engineering time on building a solution for spawning ephemeral runners on demand, or setting up one of the many projects that promise to solve this. But those projects are not built with simplicity in mind, image compatibility with official runners is lacking, and they do not handle all corner cases of GitHub and AWS, so now we’re back to spending engineering time fiddling with infrastructure, terraform, kubernetes, lambdas, etc.
There is a better way: RunsOn is the result of thousands of hours spent debugging GitHub Actions and making sure it is perfectly integrated with AWS. Fast machines are great, but it’s a very minimal part of what makes a great CI/CD nowadays: network speed, caching capabilities, ephemeral registries, static IPs, etc. are things you didn’t think you would need, but your developers are craving for.
RunsOn is the only self-hosted solution that can be installed and upgraded in one click, with built-in observability, multi-datacenter reliability, flexible runner sizing, and unlimited concurrency.
⚡️ Blazing fast builds
- Native x64 & ARM64 runners
- At least 30% faster than GitHub-hosted
- Windows & GPU support
- Optimized boot time under 30s
💰 Maximum cost savings
- Up to 90% cheaper with AWS Spot instances
- Automatic fallback to on-demand instances
- Can use your existing AWS credits
📈 Scales with your needs
- Hundreds of concurrent jobs at once
- 400k+ daily jobs across users
- Multi-AZ for high availability
- Only limited by your AWS quotas
✨ Supercharged caching
- VPC-local S3 cache backend
- Up to 5x faster transfers
- Unlimited storage for caching
- EFS for storing large data files
- Ephemeral registry for storing docker images
🔒 Enterprise-ready
- Can bring your own networking stack
- Static IPs for firewall rules
- Custom images, SSH or SSM access
☸️ Complete control
- 100% self-hosted in your AWS account
- No third-party dependencies
- Full audit capabilities
🛡️ Secure
- Real EC2 VMs for complete isolation
- Ephemeral, recycled after each job
- Regularly maintained and patched
- Security taken seriously
🔄 Best alternative to
- GitHub-hosted runners
- Actions Runner Controller (ARC) for Kubernetes
- Philips terraform-aws-github-runner
- Homegrown solutions
We're in the process of moving from CircleCI to Github Actions. We've been using Actions Runner Controller on EKS, but hit a number of scaling issues, job pickup delays, and job cancellations.
We started trialing RunsOn to see how other options might fair compared to ARC and have been thoroughly impressed.
Simple pricing that won’t break the bank
Section titled “Simple pricing that won’t break the bank”Spawning VMs on AWS is not exactly rocket science, as AWS is doing all the hard work. So the pricing for RunsOn is simple: you pay a yearly license fee for the software that sets up the infrastructure and orchestrates job launches, and you pay for your EC2 usage directly to AWS. Have free credits on AWS? Even better, your CI is now free.
No middleman, no markup, no surprises.
To get started, simply use the 15-day demo license, no credit card required.
Evaluate for free for 15 days.
Per-second billing
No middleman markup
Use your AWS credits
Been using RunsOn for a quarter. We saved around 75% our costs, and our tests now run around 5x faster because we can use gigantic spot instances cost-effectively.
Stop wasting money on oversized runners, use RunsOn flexible runner configuration
Section titled “Stop wasting money on oversized runners, use RunsOn flexible runner configuration”Nobody wants to pay for a 2CPU/8GiB runner when your workflow can run with 4GiB, or a single CPU. Or it needs a lot of CPUs, but not much RAM, etc.
With RunsOn you can take advantage of the wide inventory of AWS instances to get even more savings and stop wasting resources. Specify RAM, CPU, GPU, DISK size, instance type, static IP support, and more at runtime:
runs-on: ubuntu-latest # ⤵️ replace withA compatible 2-CPU x64 runner:
runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64A 2-CPU ARM64 runner:
runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-arm64A 16-CPU x64 runner with a custom image:
runs-on: runs-on=${{ github.run_id }}/family=c7a+c7i/cpu=16/image=custom-image-x64c7gd instance (950GB of NVMe local storage), using Ubuntu24 for ARM64:
runs-on: runs-on=${{ github.run_id }}/family=c7gd.4xlarge/image=ubuntu24-full-arm64A runner with a static egress IP, and SSH disabled:
runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64/private=true/ssh=falseA runner targetting a specific environment:
runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64/env=stagingLess than 10 min to test, install and use the product. You can finetune any workflow (CPU, RAM, machine type/size..) depending on your needs. The cache download speed is blazing fast thanks to amazon s3 endpoint. Pricing is transparent, pay only what you use with no overage.
Battle-tested CloudFormation stack
Section titled “Battle-tested CloudFormation stack”CloudFormation is a simple way to declaratively describe an entire infrastructure on AWS, and get it up and running in a few minutes. It comes with integrated drift detection, changeset previews, and is available through the AWS CLI or AWS Console. Installation and upgrades are just a few clicks.
It is generally a no-frill experience to setup, which helps to get started without any other tool dependency. If you prefer to use CDK or Terraform, you can also use the native constructs of those tools to import and customize the template resources.
Available in 10 AWS regions. Install now in 10 minutes or watch the demo:
10x cheaper, for 10 minutes of work
You can always switch back to official runners at any time.
Is RunsOn for me?
Most likely YES: If you spend more than $100/month on GitHub Actions, or find yourself constantly babysitting your own self-hosted runners, then you will definitely get a meaningful return on investment by switching to RunsOn. You also get access to custom ARM runners and GPUs, irrespective of your GitHub plan, even on the free tier.
Is this better than Action Runner Controller (ARC)?
If you are already heavily invested into Kubernetes, then ARC might not be too much work for you to setup and operate. However, RunsOn is much simpler to install, requires zero maintenance, and has a much better feature set than ARC: flexible runner types, 1-1 compatible images, integrated caching, real VMs, static IPs, fast boot times.
Is this better than the Philips Terraform AWS GitHub Runner?
Philips Terraform module is entirely Open-Source and free, contrary to RunsOn where you pay a small license fee for commercial use (non-commercial use is free). The terraform module is harder to setup and operate, and has a more limited feature set: no image compatibility with GitHub, slower boot times in ephemeral mode, fixed runner types, no integrated caching, hard to debug failure modes due to extensive use of lambdas.
Is this better than [other 3rd-party provider]?
There are great 3rd-party providers for self-hosted GitHub Actions runners (benchmarked here). However they are 3rd-parties, so you must be aware of the security implications of using them. RunsOn is fully self-hosted, does not depend on third-parties, has the best pricing, and features you won’t find over there at the same price point (unlimited concurrency, SSH access, static IPs, fast and consistent boot times, the widest choice of instance types, etc).
What about security?
RunsOn is fully self-hosted, and does not depend on third-parties. You can deploy it in your own AWS account, and have a look at our dedicated security page for more details.