US Data Residency for GitHub Actions Runners

WarpBuild gives GitHub Actions two ways to keep build data inside a US region: hosted runners on region-specific infrastructure, available on enterprise plans, and BYOC runners that launch inside your own US cloud account. US and EU are the regions WarpBuild names for hosted runners, and BYOC moves the placement decision into infrastructure you already own and already audit.

This page covers what runs where, which runner labels are available, what the control plane still handles outside the region, and what the in-region minutes cost against GitHub's published list prices.

Answer

Data residency for a runner fleet is a question about four things: the machine that checks out your source, the disk that machine writes to, the store that holds caches and build artifacts between jobs, and the logs that record what happened. A residency commitment is only meaningful when all four have a known location.

WarpBuild answers that in two configurations.

Hosted runners on region-specific infrastructure. WarpBuild operates the runner fleet. On enterprise plans, cloud runners can be deployed on region-specific infrastructure, and any data you choose remains in that specific region. This is the lower-operations path: you keep the one-line runs-on change and add a region constraint underneath it. The cloud runners documentation carries the same callout, and the option is enabled through support rather than through a self-serve toggle.

BYOC runners in your own cloud account. WarpBuild creates and manages runner instances inside your AWS, GCP, or Azure account. BYOC runs on AWS, GCP, and Azure. The instances, the VPC, and the object storage bucket that holds caches, container image layer caches, logs, and other workflow artifacts all live in the region of your account where you created the WarpBuild stack. This is the strongest residency answer because the placement is enforced by your own cloud account boundary, and the evidence for an auditor comes from your own cloud console rather than from a vendor attestation.

Both configurations run the same runner images and the same warp- labels. The choice is about placement and operations; the workflow syntax is identical either way.

One thing sits outside the region in every row: the control plane that talks to GitHub. That boundary is described in full under what stays in region, because it is the part procurement reviews ask about and the part a diagram usually gets wrong.

Regions and Availability

The catalog is the same set of labels regardless of which residency path you take, with one exception worth stating early: region-specific infrastructure does not apply to macOS instances, so a US residency commitment that has to cover Xcode builds needs a separate conversation with [email protected].

The per-size rates below come from the runner catalog. Storage on every runner is ephemeral and is deleted when the runner terminates, which matters for residency because nothing persists on the machine after the job.

A workflow that runs across all four platforms uses the same labels whether or not a residency constraint is attached to the account:

name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  unit-tests:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

  arm-image:
    runs-on: warp-ubuntu-latest-arm64-8x
    steps:
      - uses: actions/checkout@v4
      - run: docker build --platform linux/arm64 -t app:arm64 .

  windows-integration:
    runs-on: warp-windows-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/integration.ps1

  ios-build:
    runs-on: warp-macos-26-arm64-6x
    steps:
      - uses: actions/checkout@v4
      - run: xcodebuild -scheme App -destination 'generic/platform=iOS' build

BYOC placement mechanics

BYOC setup is three steps: connect the cloud account, which creates the IAM role or service account WarpBuild uses; create a stack, which is the region, VPC, subnets, and object storage bucket the runners use; and create a custom runner, which fixes the instance types, disks, and IP configuration. The stack name, the object storage location, and the region cannot be changed after creation, so the residency decision is made once, at stack creation, and is visible in your own account from then on. The full flow is in the BYOC documentation.

Two details matter for a US-only commitment. The import flow, which places runners inside a VPC you already operate, is supported only on AWS, so teams that need runners inside an existing audited network usually start there. Terraform support exists for BYOC on AWS, which is how the placement becomes reviewable code rather than a console click.

What in-region minutes cost

Residency conversations stall on cost more often than on architecture, so here is a worked model for a mid-sized fleet. The GitHub prices come from GitHub's Actions minute multipliers reference and the shapes from GitHub's hosted runner specifications, both checked on 2026-08-13. WarpBuild rates come from the runner catalog above.

Assume a month of 60,000 Linux minutes on a 4 vCPU shape, 8,000 Windows minutes on a 4 vCPU shape, and 3,000 macOS minutes.

The monthly totals are $848.00 on WarpBuild against $1,202.00 on the GitHub-hosted equivalents, a difference of $354.00 per month or $4,248 per year at these volumes. The macOS row compares the nearest ARM64 shape GitHub publishes; the WarpBuild runner in that row carries one more vCPU and 8 GB more RAM.

The BYOC line works differently. BYOC Linux and Windows runners carry a $0.002 per minute WarpBuild fee, and the compute itself lands on your own cloud bill at whatever rates your account already has, including any committed-use or savings-plan discounts you have negotiated. The same 60,000 Linux minutes cost $120.00 in WarpBuild fees, with the instance hours billed to your account. Add-on line items are included in the BYOC fee.

Choose between hosted and BYOC placement from the residency requirements first. For a cost estimate, combine measured job duration with the applicable cloud rates and WarpBuild fees on the pricing page.

For hosted runners, the add-ons bill separately and at published rates: cache storage at $0.20 per GB-month, cache write or restore operations at $0.0001 each, snapshot restore at $0.04 per job, snapshot storage at $0.025 per snapshot-hour, and networking through Tailscale at $0.

What Stays in Region

Split the system into two halves: the data plane, which is the runner and the storage it touches, and the control plane, which is the coordination layer that talks to GitHub. Residency applies to the first half. The second half handles registration and lifecycle and never becomes the resting place for your build data.

Stays in the region you chose. The runner VM and its encrypted, ephemeral disk. The source checkout, dependency downloads, compiled outputs, and test artifacts written during the job. The cache entries that jobs write and restore. Container image layer caches for Docker builds. Workflow artifacts and logs written to the stack object storage bucket on BYOC, which is created in the stack region and cannot be moved afterward.

Handled by the control plane. Registering runners with GitHub, managing runner lifecycle, and making GitHub API calls on your behalf. Those requests leave from three static egress IPs, documented as 3.13.16.127, 3.141.157.169, and 3.151.226.250, which is the list to add if your organization uses a GitHub IP allow list or restricts inbound traffic to a GitHub Enterprise Server instance. The control plane also holds the job metadata behind the dashboard: repository, job name, runner label, stack, execution time, billed time, and cost per job execution, which is what the Reports page renders.

Held by GitHub. Your repository contents, workflow run logs as GitHub stores them, encrypted secrets, and anything uploaded with actions/upload-artifact sit in GitHub's own systems under GitHub's terms. WarpBuild does not access or store build secrets; secrets live in your repository and are only accessible to your runner environment. A complete residency posture pairs in-region runners with whatever residency GitHub itself offers for the account, which is a GitHub product decision rather than a runner-layer one.

The isolation model underneath all of this is described in the runner security documentation. Each runner runs in its own virtual machine, created on demand and destroyed after each build. Each runner gets its own encrypted storage volume, also created on demand and destroyed after the build. When caching is enabled, the cache is encrypted and stored in a location that is only accessible to your runner. Nothing is reused across builds, so there is no long-lived disk in any region holding a previous customer's or a previous job's data.

On BYOC the whole data plane collapses into your account. A workflow points at the custom runner by its runner ID, which carries the warp-custom- prefix:

name: release
on:
  push:
    tags: ['v*']

jobs:
  build:
    runs-on: warp-custom-us-linux-8x
    steps:
      - uses: actions/checkout@v4
      - name: Build release image
        run: docker build -t "$REGISTRY/app:${GITHUB_REF_NAME}" .
        env:
          REGISTRY: ${{ vars.ECR_REGISTRY }}
      - name: Push to ECR
        run: docker push "$REGISTRY/app:${GITHUB_REF_NAME}"
        env:
          REGISTRY: ${{ vars.ECR_REGISTRY }}

That job runs on an EC2 instance in your VPC, pulls from and pushes to a registry in the same account, and writes its cache to a bucket you own. The network path never leaves your account boundary, which is the property most US residency clauses are actually asking for. Egress costs on the enterprise tier are covered separately on zero egress on the WarpBuild enterprise tier.

One placement caveat repeats here because it decides architectures: region-specific infrastructure does not apply to macOS instances, and BYOC pricing covers Linux and Windows runners. Teams with a strict US-only rule and an iOS pipeline should raise that with support before committing to a design.

Compliance

WarpBuild is SOC 2 Type 2, with trust.warpbuild.com as the linked evidence. The attestation covers three Trust Services Criteria: Security, Availability, and Confidentiality. Security documentation and the report itself are requested through the trust center, and [email protected] handles questionnaire and DPA review.

Regulatory frameworks belong to your compliance program. The runner layer supplies inputs to it. If your obligations come from a customer contract that names US processing, from a HIPAA program, or from GDPR commitments that constrain where processing happens, the useful question to ask a runner vendor is narrow: where does the machine run, where does the storage sit, and what evidence proves it. BYOC answers all three from artifacts you already produce for auditors, because the instances and buckets appear in your own account inventory, your own CloudTrail or equivalent audit log, and your own tagging and cost reports. Region-specific infrastructure on enterprise plans answers them through WarpBuild's own controls plus the SOC 2 Type 2 report.

The rest of the enterprise procurement surface is straightforward. SSO is available for a flat $250 per month, whatever the user count; see the pricing page for the rest of the rates.

For a US residency evaluation, the practical sequence is short: start on hosted runners with $10 free credits from signup, run one real pipeline to confirm the labels and images fit, then decide between region-specific infrastructure and BYOC based on whether the evidence needs to come from your cloud account or from a vendor report. The EU residency page covers the same ground for European placement, and the BYOC setup guides for AWS, GCP, and Azure cover the account connection in detail.

FAQ

Which regions does WarpBuild name for hosted runners?

US and EU. On enterprise plans, cloud runners can be deployed on region-specific infrastructure so the data you choose remains in that region. Region-specific infrastructure does not apply to macOS instances.

What is the strongest US residency answer WarpBuild offers?

BYOC. The runner instances and the stack object storage bucket live in your own AWS, GCP, or Azure account, in the region you select when you create the stack, and the region cannot be changed afterward.

Does the WarpBuild control plane sit inside my region?

No. The control plane registers runners with GitHub, manages their lifecycle, and calls the GitHub API from three static egress IPs. Job data stays on the runner and in your in-region storage.

Can WarpBuild support a US-only audit requirement?

WarpBuild is SOC 2 Type 2 with three Trust Services Criteria, and the report is available at trust.warpbuild.com. Pair it with BYOC placement evidence from your own cloud account.