Quickstart
From zero to a cached, 10x-cheaper GitHub Actions build running in your own AWS account.
This quickstart takes you from nothing to a fast, cached GitHub Actions build running on your own AWS account in about 15 minutes. Three steps: install RunsOn in your AWS account, point a workflow at it, then make it fast with caching.
You’ll need an AWS account (ideally a dedicated sub-account for isolation) and a RunsOn license key — free for non-commercial use, or a 15-day trial.
Most teams start with RunsOn Flex, which gives each job precise control over its runner. Platform teams add RunsOn Fleet on top to publish a small set of standardized runner fleets. The tabs below show both — Flex is the recommended start.
1. Install RunsOn in your AWS account#
Flex installs with a single CloudFormation stack in about 10 minutes:
- Pick your AWS region to open the CloudFormation quick-create screen with the RunsOn template pre-loaded.
- Fill in your GitHub organization name, license key, and a notification email, then submit. RunsOn creates a dedicated, least-privilege IAM role for the service.
- From the stack Outputs, open the
RunsOnEntryPointURL and click Register app — this creates a private GitHub App that lives only in your AWS account.
Fleet installs as infrastructure-as-code with the official Terraform / OpenTofu module:
module "runs_on_fleet" { source = "runs-on/runs-on/aws//modules/fleet" version = "v3.1.3" # github boundary, networking, runner fleets...}2. Run your first job on RunsOn#
Swap GitHub’s hosted label for a RunsOn label — that’s the only required change:
runs-on: ubuntu-latestruns-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64A complete minimal workflow:
jobs: build: runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64 steps: - uses: actions/checkout@v6 - run: echo "Hello from RunsOn"The label is composable — request exactly the machine you want, for example
cpu=4/ram=16/family=c7a+m7a or runner=16cpu-linux-arm64. See all
job labels and Linux runners.
jobs: build: runs-on: runs-on/fleet=linux-small/env=production steps: - uses: actions/checkout@v6 - run: echo "Hello from RunsOn Fleet"With Fleet, the platform team publishes approved runner fleets and workflow authors target them by name. See runner fleets.
3. Cache dependencies to run faster (recommended)#
Turn on Magic Cache by adding extras=s3-cache to your runner label, then keep using
the standard actions/cache action — no other workflow changes. RunsOn transparently
routes the cache to a fast, in-VPC S3 backend:
- 5x faster than the official GitHub Actions cache.
- Unlimited size (items evicted by your stack’s policy, default 10 days).
- Local to your VPC, so it’s fast, reliable, and secure.
jobs: build: runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64/extras=s3-cache steps: - uses: runs-on/action@v2 - uses: actions/cache@v5 with: path: ~/.npm key: npm-${{ runner.os }}-${{ hashFiles('package-lock.json') }}For Fleet, publish runners with Magic Cache enabled from Terraform, then keep using
actions/cache in your workflows:
runners = { linux-cache = { cpu = 4 ram = 8 family = ["c8i"] image = "ubuntu24-full-x64" extras = ["s3-cache"] }}Learn more in the Magic Cache reference.
4. Cache Docker layers (recommended)#
The same extras=s3-cache runner also accelerates Docker builds. Point Buildx at the
type=gha cache backend and RunsOn routes it to S3 transparently:
jobs: docker: runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64/extras=s3-cache steps: - uses: runs-on/action@v2 - uses: docker/setup-buildx-action@v3 - uses: docker/build-push-action@v6 with: cache-to: type=gha,mode=max cache-from: type=gha