Skip to content

Features

Your GitHub CI costs are ballooning, or you are fed up with slow build times, so you try self-hosting GitHub Actions runners. But after some setup time, you quickly realize it’s not easy to keep them running at scale, and now jobs are queuing up or building slowly.

Now you try third-party hosted runners, but your security team is concerned about exposing your code and secrets to a third-party, and you’re not sure what to do.

Enter RunsOn, the best way to run GitHub Actions runners on your own AWS infrastructure.

📦

Wait, there's S3-based caching?

5x faster with Magic Cache

RunsOn includes a transparent S3 caching backend that works seamlessly with actions/cache. No code changes needed — just enable it and watch your cache restore times drop dramatically.

  • ✓ Unlimited storage in your VPC
  • ✓ 5x faster than GitHub’s cache
  • ✓ Works with existing cache actions
  • Learn more →
🐳

And Docker builds get their own registry?

Ephemeral ECR registry

Stop pulling base images from Docker Hub on every build. RunsOn sets up a shared ECR registry in your VPC with automatic cleanup — your Docker builds stay fast and your bandwidth costs stay low.

  • ✓ Shared registry across all runners
  • ✓ Auto-cleanup of old images
  • ✓ No Docker Hub rate limits
  • Learn more →
💾

Block-level snapshotting too??

EBS snapshots for instant restore

This changes everything. Snapshot your entire /var/lib/docker directory and restore it in seconds, not minutes. Block-level efficiency means you only transfer what changed.

  • ✓ Restore entire Docker state instantly
  • ✓ Block-level deduplication
  • ✓ Perfect for large monorepos
  • Learn more →

But this must be hard to configure...

It's just a label away

Nope. All these features are enabled with a simple label change. One line in your workflow file unlocks everything.

# Enable S3 caching + tmpfs for maximum speed

runs-on: runs-on/runner=2cpu-linux-x64/extras=s3-cache+tmpfs


# Use EBS snapshots for Docker layer caching

- uses: runs-on/snapshot@v1
  with:
    path: /var/lib/docker

📊

SaaS providers show me fancy dashboards though...

Full observability included

About that… RunsOn integrates with OpenTelemetry and provides visibility into your CI/CD pipelines. Per-job or per-repository metrics, and dashboards — all built-in.

RunsOn OpenTelemetry dashboard showing job metrics and traces
OpenTelemetry dashboard with job traces and metrics
🔒

And it's all in my AWS account?

100% self-hosted observability

Remember? Everything runs in your AWS account. Alarms, cost reports, job metrics. Your data, your dashboards, your control. No vendor lock-in, no data leaving your infrastructure.

  • ✓ CloudWatch dashboards included
  • ✓ Automatic cost attribution per workflow
  • ✓ SNS alerts for failures and anomalies
  • ✓ Full audit trail in your account

Using self-hosted runners with RunsOn can be useful if:

  • your developers are frustrated with long wait times for test suites or compilations;
  • your bill for GitHub runners starts to trigger enquiries from finance;
  • you need runners with a higher number of CPUs / RAM / Disk / Architecture / GPU support, than what GitHub offers.
  • you want runners running in your own AWS account with specific public IPs so that you can whitelist them in external services;
  • you already use a self-hosted runner solution, but need something simpler and maintenance-free.

Tried and tested across hundreds of companies

Section titled “Tried and tested across hundreds of companies”

RunsOn is in production at hundreds of companies, and has been battle-tested in production since January 2024. It now routinely handles more than 500k jobs per business day across all users.

RunsOn runners per day
Runners launched by users over 5 business days.

RunsOn code source is partly open, with the full source code being available if you buy a sponsorship license. With a Sponsorship license you are allowed to modify the source code for your own internal use if you want to.

⚡️ Use any AWS instance

  • From 1 to 896 vCPUs
  • x64, ARM64, GPU support
  • Linux, Windows
  • Spot instances with auto-fallback

⏱️ 10-minute setup

  • One CloudFormation click
  • Works with or without existing VPC
  • No Kubernetes knowledge needed
  • Automatic GitHub App setup

✨ Easy maintenance

  • One-click updates
  • Auto-healing infrastructure
  • No VM patching needed
  • CloudWatch monitoring included

🔒 Best security

  • Runs in your VPC
  • Fully ephemeral VMs
  • Static IPs available
  • Full audit trail

📊 Complete observability

  • Per-job performance metrics
  • Automatic cost attribution
  • CloudWatch dashboard
  • SSH or SSM debug access

☸️ Full control

  • 100% self-hosted in your AWS account
  • No third-party dependencies
  • Full audit capabilities
  • Source code available

🐳 Docker builds

  • Ephemeral ECR registry in your VPC
  • EBS snapshots for block-level caching
  • S3 cache for unlimited layer storage

📦 Dependency caching

  • Magic Cache: transparent S3 backend, 5x faster
  • EFS mounting for persistent caches
  • tmpfs for RAM-speed caching

🎨 Custom images

  • Bring your own AMI with pre-installed tools
  • Automatic updates with wildcard naming
  • Pre-install scripts before every job