EU Data Residency for GitHub Actions Runners

WarpBuild runs GitHub Actions runners in the EU through two paths: WarpBuild-hosted cloud runners deployed on region-specific infrastructure in the EU on the enterprise tier, and BYOC runners that boot inside an EU region of your own AWS or GCP account. Both paths keep the data a build touches inside the region you pick, while the WarpBuild control plane keeps doing the orchestration work of queueing jobs, starting and destroying runner VMs, and metering usage.

This page states which runner platforms map onto each path, what stays in region and what the control plane holds, what an EU workload costs per month, and which evidence a residency review can collect. Runner labels and rates come from the WarpBuild runner catalog and pricing page, checked on 2026-08-13.

Answer

A residency question about GitHub Actions usually arrives as one sentence from a security reviewer: the build machines that check out our source code have to sit in the EU. Answering it means naming the region, naming what is stored there, and naming who else holds a copy.

WarpBuild names two regions publicly, US and EU. Any statement narrower than that (a country, a specific cloud region code) belongs in a conversation with support rather than on a public page, because the answer depends on which path you take and which cloud account you bring.

Here are the paths, with the honest per-cloud state of each.

BYOC is the strongest residency answer available, because the runner VM, the disk under it, and the object storage bucket that holds caches and artifacts are all resources in your own cloud account, created in a region you chose, visible in your own console and your own bill. BYOC runs on AWS, GCP, and Azure, and the AWS path is the most complete one: see running GitHub Actions runners in your own AWS account for the account connection, the stack, and the Terraform module. The Azure caveat is real and worth stating plainly: the WarpBuild documentation records that BYOC on Azure is currently enabled for East US only, so an Azure-only estate has no EU BYOC path today without talking to support. See BYOC on Azure and its current region limits for that constraint in context.

If you cannot run runners in your own cloud account, the hosted EU region on the enterprise tier is the other answer, and it needs no infrastructure work from your side.

Regions and Availability

The catalog records two regions for the hosted fleet, US and EU. Placement differs by platform, and one platform carries a documented exception.

The macOS exception matters for iOS and Mac teams. Xcode jobs keep running on the shared macOS fleet, which means a residency scope that includes mobile builds needs a decision about those jobs specifically. Most reviews handle this by scoping residency to the repositories that carry regulated data and leaving public or sample-app builds on the shared fleet. Bring that split to [email protected] before signing anything.

Workflow labels do not change when the region does

Region placement happens at the account and stack level, so the workflow file keeps the same warp- labels. A three-platform matrix looks the same before and after an EU move.

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

jobs:
  unit-tests:
    strategy:
      fail-fast: false
      matrix:
        include:
          - platform: linux-x64
            runner: warp-ubuntu-latest-x64-8x
          - platform: linux-arm64
            runner: warp-ubuntu-latest-arm64-8x
          - platform: windows
            runner: warp-windows-latest-x64-8x
    runs-on: ${{ matrix.runner }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

BYOC changes the label, because a custom runner registers under the runner ID shown on the custom runners page, always prefixed with warp-custom-. Name the stack after its purpose so the workflow file reads as documentation of where the job runs.

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

jobs:
  build:
    runs-on: warp-custom-eu-release-16x
    steps:
      - uses: actions/checkout@v4
      - name: Build release artifacts
        run: make release
      - name: Push image to the in-region registry
        run: |
          docker build -t "$REGISTRY/app:${GITHUB_REF_NAME}" .
          docker push "$REGISTRY/app:${GITHUB_REF_NAME}"
        env:
          REGISTRY: ${{ secrets.CONTAINER_REGISTRY }}

A stack pins the region, the VPC, and the object storage bucket that holds cache, container image layer cache, logs, and workflow artifacts. The stack name, the storage location, and the region cannot be changed after creation, so pick the region during the review rather than after it. The BYOC setup documentation walks the three steps: connect the cloud account, create the stack, create the custom runner.

Cost model for an EU workload

Take a team running 300,000 Linux minutes and 40,000 Windows minutes a month, with 200 GB of cache in storage. Rates below are WarpBuild list prices from the pricing page, checked on 2026-08-13.

The same volumes on GitHub-hosted larger runners come to $4,480 per month at GitHub list prices: 300,000 minutes on the 4-core Linux larger runner at $0.012 per minute is $3,600, and 40,000 minutes on the 4-core Windows larger runner at $0.022 per minute is $880 (GitHub billing reference, checked on 2026-08-13). Per runner, warp-ubuntu-latest-x64-4x at $0.008 per minute against $0.012 is 33 percent lower list price, and warp-windows-latest-x64-4x at $0.016 per minute against $0.022 is 27 percent lower list price.

On the BYOC path the WarpBuild fee is $0.002 per minute for both Linux and Windows runners, so the same 340,000 minutes carry $680 in WarpBuild fees, and the EC2 or Compute Engine time lands on your own cloud bill at whatever rates your account already has. BYOC pricing includes the add-ons.

Choose between hosted and BYOC placement from the residency requirements first, then estimate cost from measured job duration and the applicable runner or cloud rates.

Full rates by runner type are on the WarpBuild pricing page.

What Stays in Region

A residency review needs the data classes named one at a time. Here is the split.

Stays in the region you pick. The source checkout on the runner disk. The dependency and build cache. Workflow artifacts written during the job. Job logs collected by the runner. Container image layer cache. On BYOC, all of this lives in the object storage bucket that belongs to your stack, in your account, in the stack region. On the hosted EU region, the enterprise deployment keeps the data you choose inside that region.

Handled by the control plane. Scheduling and runner lifecycle. The control plane sees which job is queued, which runner label it asked for, when a VM starts, and when it terminates. It records usage counters for billing, plus the configuration you set in the dashboard: runner definitions, stack settings, org and repository connections. This is the orchestration metadata that makes a managed runner fleet work, and it is what the enterprise conversation should scope explicitly.

Held by GitHub. GitHub stores your repository, the workflow definitions, the secrets, and the log stream the runner sends back. A runner is a machine that polls GitHub and streams results to GitHub, so a residency posture for GitHub Actions is always two decisions: where the runner executes, and where your GitHub plan puts the repository. Teams on GitHub Enterprise data residency pair that with in-region runners to close the loop.

Never stored by WarpBuild. Build secrets. Secrets live in your source code repository and reach only the runner environment. Each runner runs in its own virtual machine, created on demand and destroyed after the build, and each runner gets its own encrypted storage volume that is destroyed with it. Caches are encrypted and stored in a location accessible only to your runner. The security documentation states these controls and lists the control plane egress IPs, which is the list to hand your network team if a GitHub IP allow list or a GitHub Enterprise Server instance restricts inbound traffic.

Egress charges from your cloud during deploy-heavy jobs are handled separately on the enterprise tier; see zero egress on the WarpBuild enterprise tier.

If your workloads sit in the US instead, the same structure applies with the region flipped: see US data residency for GitHub Actions runners.

Compliance

WarpBuild holds SOC 2 Type 2, with trust.warpbuild.com as the linked evidence. The attestation covers three Trust Services Criteria: Security, Availability, and Confidentiality. Request the report and the supporting security documentation through the trust center, or write to [email protected] to work through a specific control question.

Data residency and GDPR are separate questions that arrive together. Your Article 28 review asks where personal data in a build (commit authors in git history, email addresses in test fixtures, customer records in seed data) is processed and stored. Answering it needs a named region for the runner and its storage, a named holder for each remaining data class, and a signed agreement covering the processing. The first two are what this page gives you. Bring the third to [email protected], because the terms depend on which path you take.

A practical checklist for the review:

• Name the path. Hosted EU region on the enterprise tier, or BYOC in your own EU account on AWS or GCP.
• Name the platforms in scope. Linux x64, Linux ARM64, and Windows map onto EU placement; macOS jobs need a separate decision, since region-specific infrastructure does not apply to macOS instances.
• Pin the stack region before creation. The stack name, storage location, and region are fixed once the stack exists.
• Collect the SOC 2 Type 2 report from the trust center.
• Get the control plane egress IPs into your allow list if GitHub access is restricted.
• Capture the configuration as code where you can. Terraform support exists for BYOC on AWS, which turns the residency configuration into a reviewable pull request.

Two operational items usually close out the process. SSO is available for a flat $250 per month, whatever the user count, listed with the rest of the rates on the pricing page.

The customers page carries the case studies behind those names.

FAQ

Can WarpBuild run GitHub Actions runners in the EU?

Yes. Two paths exist. On the enterprise tier, WarpBuild-hosted cloud runners can be deployed on region-specific infrastructure in the EU. With BYOC, runners start in an EU region of your own AWS or GCP account, and the cache bucket sits in that same region. US and EU are the regions WarpBuild names publicly.

Which runner platforms can I place in the EU?

Linux x64, Linux ARM64, and Windows labels are the ones that map onto EU placement. The cloud runners documentation states that region-specific infrastructure does not apply to macOS instances, so macOS jobs stay on the shared macOS fleet.

Does BYOC give me EU data residency on Azure?

Not today. The WarpBuild documentation states that BYOC on Azure is currently enabled for East US only, and points teams that need other regions to [email protected]. For an EU BYOC footprint right now, use AWS or GCP.

What compliance evidence can I hand my auditor?

WarpBuild holds SOC 2 Type 2, with trust.warpbuild.com as the linked evidence, covering Security, Availability, and Confidentiality. Request the report and the supporting security documentation through the trust center.