Run your GitHub Actions jobs in the AWS region you choose

RunsOn runs your GitHub Actions jobs in your own AWS account, in the region you deploy it to. You pick the region, not us. In the last seven days (15–21 October), RunsOn customers ran 24.4 million jobs across 16 AWS regions:

N. Virginia alone ran 40% of them, and the US regions 74%. Europe ran 22%, with Frankfurt ahead of Ireland. The rest is spread across Sydney, Singapore, Tokyo, Mumbai and Seoul.

That spread is the point. Teams don’t run CI in Frankfurt or Sydney by accident: they run it there because their data has to stay there, or because the rest of their infrastructure lives there.

Keep CI where your data has to stay#

If your compliance team wants builds to stay in the EU, deploy the RunsOn stack in eu-central-1 and they do. Everything a job touches on the AWS side is created in your account, in that region:

• the EC2 instance the job runs on, terminated when the job ends;
• the cache bucket, sticky disks and their snapshots;
• the runner and control-plane logs in CloudWatch;
• the queues, and the webhook endpoint GitHub calls to start a job.

Two requests leave your account for runs-on.com: a license check, and one event per job with the instance type, region and version. Neither carries code, secrets or logs. The security page lists every field.

This goes beyond the standard regions. Last week, jobs also ran in AWS GovCloud (US-East) and in the AWS European Sovereign Cloud. The stack handles their separate AWS partitions, but our public runner images aren’t published there: you bring your own image.

One thing a runner can’t change: your code comes from GitHub and job logs go back to GitHub, whoever hosts the machine. What you control is where the build runs and where its caches and artifacts are stored.

Keep CI next to your infrastructure#

The other reason is distance. A runner in the same region as your ECR registry, your S3 buckets and your databases pulls images and pushes artifacts without leaving the region. That’s faster, and AWS bills cross-region traffic per GB, while same-region S3 traffic through a gateway endpoint costs nothing.

It also matters for deploy jobs that need private resources. The Terraform module deploys runners into your existing VPC and subnets, so a job reaches your internal services like any other machine there. A CloudFormation stack gets its own VPC, which you peer with yours.

More than one region#

One stack runs in one region. For several, deploy a stack in each and pick the region per job with the region label:

jobs:
  build-eu:
    runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64/region=eu-central-1
  build-us:
    runs-on: runs-on=${{ github.run_id }}/runner=2cpu-linux-x64/region=us-east-1

Each stack only takes the jobs labelled with its own region. Give every job a region label once you have more than one stack: a job without one matches every stack. That’s for Flex; with Fleet, give each regional deployment its own fleet name and target that. Environments explain how to split stacks by region, account or team.

The volume, for the record#

Last week (12–18 October), RunsOn ran 22.7 million GitHub Actions jobs, against 3.5 million in the same week last year:

The daily record moved too: 4.71 million jobs on Tuesday 20 October, up from the 3.21 million we wrote about five weeks ago.

Run GitHub Actions in your own AWS account, in the region you pick.