Can I Run BYOC in More Than One Region?
Yes. Create one BYOC stack per region under the same cloud connection, add custom runners to each stack, and the runs-on label picks the region a job lands in.
Answer
Yes. You run BYOC in more than one region by creating one stack per region inside the same cloud connection and then defining custom runner configurations against each stack, so a GitHub Actions job picks its region through the warp-custom- label in runs-on (BYOC setup documentation). BYOC runs on AWS, GCP, and Azure, and on the WarpBuild-hosted fleet US and EU are the regions WarpBuild names publicly.
The shape follows from how the three BYOC objects nest. The BYOC setup documentation describes a cloud connection that grants WarpBuild the IAM role or service account it needs, a stack that is the group of infrastructure in one region, and custom runners that carry instance types, disks, and IP configuration. Only the middle object is pinned to a region.
| Object | What it holds | Region bound | What a second region needs |
|---|---|---|---|
| Cloud connection | The IAM role or service account WarpBuild uses in your account | No | Nothing. One connection serves every region |
| Stack | Region, VPC, subnets, and the object storage bucket for cache, image layer cache, logs, and artifacts | Yes, fixed at creation | A second stack |
| Custom runner | Instance types in priority order, disk size, IP configuration, standby disk pool, instance profile on AWS | Inherits the stack region | A second set of runner configurations |
| Runner ID | The label a workflow puts in runs-on, prefixed warp-custom- | Through its stack | A second label per runner class |
The documentation is explicit that the stack name, object storage location, and region cannot be changed after creation, which is why a region is added rather than moved. It also recommends naming stacks after their product and region, with twitch-use1 and alexa-use2 as the worked examples, and that convention is what makes a multi-region workflow file readable later.
Pricing does not change with the count. BYOC Linux runners and BYOC Windows runners each carry a WarpBuild fee of $0.002 per runner minute wherever the stack sits (pricing page, checked on 2026-08-13).
Detail
What a second stack actually creates
Each stack builds its own network and its own bucket in its own region, and the AWS BYOC configuration guide sets the prerequisites you have to satisfy again per region rather than once per account.
| Prerequisite | Per-region requirement |
|---|---|
| VPC and subnets | At least one public and one private subnet with internet connectivity, three of each across availability zones recommended |
| Address headroom | Enough addresses per subnet for peak concurrent runners in that region, 250 per subnet recommended |
| Object storage | A bucket in the same region as the stack, holding the artifact cache and runner telemetry under that stack |
| Private route to the bucket | A network path from the VPC to the bucket so runners reach it without incurring data transfer charges |
| Quotas | vCPU, EBS volume, and address capacity for the selected instance types in that region |
Instance type availability is the one that surprises teams. A machine family you rely on in one region can be short in another, which is what the fallback instance list on a custom runner configuration is for: several instance types in priority order, chosen with roughly similar performance so that a fallback does not change job timings.
How labels map to regions
Region selection is a workflow-file decision because each custom runner belongs to exactly one stack.
name: ci
on: [push]
jobs:
unit-tests:
strategy:
matrix:
region: [use1, euw1]
runs-on: warp-custom-app-${{ matrix.region }}-8x
steps:
- uses: actions/checkout@v4
- run: make test
eu-release:
needs: unit-tests
runs-on: warp-custom-app-euw1-16x
steps:
- uses: actions/checkout@v4
- run: make releaseThe matrix job runs the same test suite in both regions. The release job is pinned to the EU stack, so the checkout, the build workspace, and everything the job writes to cache stay inside that region's account footprint.
Keeping build data in the region that has to hold it
Multi-region BYOC is usually a residency requirement rather than a capacity one. The bucket the stack creates holds the artifact cache, the container image layer cache, runner logs, and other workflow artifacts, and it lives in the stack region (BYOC setup documentation). Because the region is fixed at creation, the placement is enforced by the stack rather than by a setting someone can change later, which is the property a reviewer wants to see. The macOS labels stay on WarpBuild-hosted capacity, so an EU-pinned estate keeps Xcode jobs on the hosted fleet. The vocabulary a review will use is set out in data residency, defined, and the EU-specific paths are on EU data residency for GitHub Actions runners.
One per-cloud limit belongs in any plan. BYOC on Azure is currently enabled for East US only, and additional regions go through [email protected], so an Azure-only estate has no second-region option today without that conversation. AWS and GCP stacks are created in whichever region you configure.
What crossing a region costs
A runner and the bucket it reads should sit in the same region. When they do, the private route to the bucket keeps that traffic off the data transfer meter, which is why the configuration guide asks for that route and for the bucket to be in the stack region. When they do not, every cache restore and every artifact upload becomes billable inter-region transfer on your own cloud bill.
Take 2,000 jobs a month, each moving 5 GB of cache and image layers, with runners in one region and the bucket in another. AWS lists data transferred out from Amazon S3 in US East (N. Virginia) to another AWS Region at $0.02 per GB (Amazon S3 pricing, checked on 2026-08-13); rates differ by source region, so read your own.
| Layout | Transfer per month | Rate | Monthly transfer charge |
|---|---|---|---|
| Runners and bucket in the same region, private route in place | 10,000 GB, in region | No transfer charge | $0.00 |
| Runners in one region, bucket in another | 10,000 GB, cross region | $0.02 per GB | $200.00 |
The WarpBuild fee is $40.00 either way at 20,000 runner minutes, so the split layout adds $200.00 a month against a $40.00 platform fee, before any EC2 or storage line. One stack per region, each with its own bucket, is the arrangement that keeps that meter at zero. Deploy-heavy workflows that pull large images and artifacts from ECR, S3, and similar stores generate no egress charges on the WarpBuild enterprise tier, on BYOC and on WarpBuild-hosted runners; see zero egress on the WarpBuild enterprise tier.
The full AWS setup, including the stack creation flow you repeat per region, is on the BYOC on AWS page, and the operating detail for a running multi-region fleet is on running BYOC runners in several regions.
Related Questions
How many stacks do I need to cover two regions?
One stack per region. A stack is the group of infrastructure in a single region of your cloud account, and the BYOC setup documentation states that the stack name, object storage location, and region cannot be changed after creation. The cloud connection above it is shared, so a second region reuses the IAM role or service account you already granted. On AWS and GCP you pick any region you configure, and BYOC on Azure is currently enabled for East US only. The AWS walkthrough is on the BYOC on AWS page.
Can one workflow run jobs in two regions at once?
Yes. Region selection lives in the runs-on label, because a custom runner belongs to exactly one stack and the label is the runner ID with the warp-custom- prefix. Point one job at a runner in the EU stack and another at a runner in the US stack in the same workflow file, or drive both from a matrix as in the example above. The operating patterns are covered in running BYOC runners in several regions.
Does a second region change what I pay WarpBuild?
No. Your own cloud account bills the per-region compute, storage, and any transfer between regions.
Start with $10 in free credits
Change the runner label in your workflow and keep the rest of your GitHub Actions setup. Runner time is billed per minute.