Can I Keep Builds in the EU Only?

Answer

Yes for the data a build touches, and the two paths that get you there are a hosted EU region on the enterprise tier or BYOC runners in an EU region of your own cloud account. US and EU are the regions WarpBuild names publicly, and BYOC gives the strongest version of the answer, because the runner instance, the disk under it, and the object storage bucket holding caches, logs, and artifacts are all resources in your own account, in a region fixed before any runner existed.

An EU-only requirement decomposes into three separate questions once a reviewer writes it down: where the runner virtual machine executes, where build data comes to rest, and what keeps running outside that region. The table below answers the first two for each path. Every row comes from the BYOC setup documentation or the WarpBuild runner catalog, checked on 2026-08-13.

BYOC runs on AWS, GCP, and Azure, so two of the three clouds carry an EU placement today. One documented exception belongs in the scope statement: region-specific infrastructure does not apply to macOS instances, so Xcode jobs keep running on the shared macOS fleet. Teams usually resolve that by scoping the EU commitment to the repositories that carry regulated data, and by keeping macOS work in repositories outside that scope. The security review checklist for GitHub Actions runners is where the rest of the questionnaire gets answered.

Detail

The hosted EU region

On enterprise plans, cloud runners can be deployed on region-specific infrastructure, and the data you choose remains in that specific region. Nothing changes in the workflow file, because placement is configured at the account level rather than per job. The same warp- labels keep resolving, and the fleet behind them sits in the EU region your org was deployed on. The page on EU data residency for GitHub Actions runners covers the path-by-path detail for that setup.

BYOC pins the region at stack creation

BYOC is three steps in the BYOC setup documentation. Connect the cloud account, which creates the IAM role or service account WarpBuild uses. Create a stack, which is a group of infrastructure components in one region of your account: VPC, subnets, and the object storage bucket used for cache storage, container image layer cache, logs, and other workflow artifacts. Then create custom runners with the instance types, disks, and IP configuration you want.

The documentation states that the stack name, object storage location, and region cannot be changed after creation. For a reviewer, that sentence carries more weight than a policy statement, because the placement becomes a property of created infrastructure rather than a toggle somebody can flip later. Two artifacts you generate yourself close the question: the stack region and bucket location read out of your own cloud console, and the workflow files showing which labels each repository uses. If you need EU and US footprints side by side, each one is a separate stack, and running BYOC runners across multiple regions covers how those stacks and labels are organized.

One caveat stays plain. BYOC on Azure is currently enabled for East US only, and additional regions go through [email protected], so an Azure-only estate has no EU BYOC placement today without that conversation.

What still runs outside the region you pick

Two things sit outside the EU boundary in every path, and naming them up front is what keeps a review short.

• The WarpBuild control plane. It queues jobs, starts and destroys runner VMs, and meters usage. The data it holds is orchestration metadata: which job is queued, which label it asked for, when a VM started, when it terminated, and the counters behind your invoice.
• GitHub. The repository, the workflow definitions, and the secrets stay with GitHub, because a runner is a machine that polls GitHub and streams results back to it.

The term itself is worth agreeing on before the meeting, since residency and processing get used interchangeably in questionnaires. See data residency, defined for GitHub Actions for the vendor-neutral version.

What the workflow file looks like

Hosted jobs keep the labels they already have. A BYOC job uses the runner ID from the custom runners page, always prefixed with warp-custom-, which makes the placement readable straight out of the workflow file.

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

jobs:
  test:
    runs-on: warp-ubuntu-latest-x64-8x
    steps:
      - uses: actions/checkout@v4
      - run: make test

  regulated-build:
    runs-on: warp-custom-eu-release-16x
    steps:
      - uses: actions/checkout@v4
      - name: Build release artifacts
        run: make release

Naming stacks and runners after their region and purpose, as eu-release does above, turns the workflow file into the record an auditor asks for.

What the EU path costs

Rates come from the WarpBuild pricing page and runner catalog, checked on 2026-08-13.

On BYOC, instance time, disks, and object storage land on your own cloud bill at your account rates, and the WarpBuild fee is the $0.002 per minute above. A 20,000 minute month on warp-ubuntu-latest-x64-4x therefore costs $160 hosted, or $40 in WarpBuild fees on BYOC plus whatever your EU region charges for the equivalent instance hours and storage.

Evidence a reviewer can collect

Request the report and the supporting security documentation there.

Three controls from the WarpBuild security documentation usually get quoted alongside the region answer, because a reviewer asking about the EU is also asking how long build data lives anywhere. Each runner runs in its own virtual machine, created on demand and destroyed after each build. Each runner has its own encrypted storage volume created and destroyed the same way, and cache storage is encrypted and reachable only by your runner. WarpBuild does not access or store any build secrets, which stay in your source code repository and reach only the runner environment.

Related Questions

Can I keep GitHub Actions builds in the EU only?

Yes for the data a build touches. US and EU are the regions WarpBuild names publicly. On the enterprise tier, hosted cloud runners can be deployed on region-specific infrastructure so the data you choose stays in the EU, and on BYOC the runner instance and the object storage bucket sit in an EU region of your own AWS or GCP account. The EU data residency page covers both paths in detail.

Which EU path holds up best in a security review?

BYOC. The instance, the disk under it, and the bucket holding caches, container image layers, logs, and workflow artifacts are resources in your own cloud account, in a region fixed when the stack was created, visible in your own console and on your own bill. The BYOC setup documentation records the region constraint, and running BYOC runners across multiple regions covers estates that need more than one.

What still runs outside the EU region I pick?

The WarpBuild control plane, which queues jobs, starts and destroys runner VMs, and meters usage, plus GitHub, which holds the repository, the workflow files, and the secrets. Region-specific infrastructure also does not apply to macOS instances. Walk both boundaries with the security review checklist for GitHub Actions runners.