Can I Run macOS Runners in the EU?

US and EU are the regions WarpBuild names publicly, and region selection applies to the runner fleet your organization is assigned rather than to an individual job or workflow. macOS is the platform that setting does not reach today: the cloud runners documentation records that region-specific infrastructure is an enterprise-tier deployment option and is not applicable to macOS instances, so Xcode and Swift jobs run on the shared macOS fleet.

Answer

Region selection is a fleet-level property. On the enterprise tier, cloud runners can be deployed on region-specific infrastructure so that data you choose stays in that region (cloud runners documentation, checked on 2026-08-13). The assignment is made for your organization by support, and every job that lands on those runners inherits it. Nothing in the workflow file selects a region, and no runs-on label encodes one.

The same documentation carries the exclusion in the same sentence: region-specific infrastructure is not applicable to macOS instances. That single line is the whole answer for an iOS or Mac team, and it is worth reading precisely, because it draws a line through a fleet rather than through the product.

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, and three of those four platforms take a region assignment. If your residency scope covers only the repositories that build server code, that split is usually enough, because the regulated checkout never reaches a Mac.

The compliance path when build data has to stay in one region. Scope the requirement by repository rather than by organization. Put the repositories that carry regulated source and regulated fixtures on Linux and Windows labels served by the assigned fleet, and hold the macOS repositories out of that scope with a written note about where they execute. EU data residency for GitHub Actions runners sets out the paths, the data classes that stay in region, and the classes the control plane holds, which is the structure an Article 28 review expects. Keeping GitHub Actions build data in the EU only covers the narrower version of the question, where nothing at all may leave the region.

The support route for high macOS concurrency in a specific region. Placement beyond what the public catalog states runs through a support conversation. Send [email protected] the peak concurrent macOS job count, the images you need, and the region requirement, and ask what can be committed.

Detail

The macOS catalog is the same wherever the rest of your fleet sits

Five macOS labels register against your GitHub organization, and no label carries a region segment. Rates and specifications come from the cloud runners documentation and the pricing page, checked on 2026-08-13.

The warp-macos-15 labels also answer to the aliases warp-macos-latest-arm64-6x and warp-macos-latest-arm64-12x. The macOS runner catalog carries the full label grammar and the image contents.

What a split workflow looks like

Most teams that hit this question run one repository with both server jobs and app jobs. The server job goes to a label served by the assigned fleet; the macOS job goes to the shared macOS fleet and gets named as such so a later audit does not have to guess.

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

jobs:
  api-tests:
    # Runs on the cloud runner fleet this organization is assigned to
    runs-on: warp-ubuntu-latest-x64-8x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: "1.24"
      - run: go test ./...

  ios-tests:
    # Runs on the shared macOS fleet: region-specific infrastructure
    # is not applicable to macOS instances
    runs-on: warp-macos-26-arm64-12x
    steps:
      - uses: actions/checkout@v4
      - run: xcodebuild -scheme App -destination "platform=iOS Simulator,name=iPhone 17" test

Controls that hold on every runner regardless of placement

Placement is one control and it is not the only one a reviewer counts. Each runner has its own encrypted storage volume, created on demand and destroyed after each build, and cache written during a job is encrypted and stored in a location accessible only to your runner (security documentation, checked on 2026-08-13). If your organization restricts inbound traffic to GitHub with an IP allow list, the same page points to the control plane egress IPs your network team needs.

What a macOS month costs while that conversation happens

Rates below are WarpBuild list prices from the pricing page, checked on 2026-08-13. Take an app team running 250 pull request builds a month at 14 minutes each, which is 3,500 macOS minutes.

• warp-macos-26-arm64-6x at $0.08 per minute: 3,500 x $0.08 = $280 per month.
• warp-macos-26-arm64-12x at $0.16 per minute: 3,500 x $0.16 = $560 per month, before any reduction in minutes from the larger machine.

Related Questions

Which regions can WarpBuild place GitHub Actions runners in?

US and EU are the regions WarpBuild names publicly. Region selection is an enterprise-tier setting applied to the runner fleet your organization is assigned, and the cloud runners documentation records that it is not applicable to macOS instances. EU data residency for GitHub Actions runners walks the paths in full.

Does the region setting change my macOS runner labels or workflow file?

No. The five macOS labels are the same on every account, so a job keeps runs-on set to a label such as warp-macos-26-arm64-6x whatever region the rest of your fleet is assigned to. The macOS runner catalog lists every label with its size and rate.

How do I get high macOS concurrency in a specific region?

Write to [email protected] with the peak job count, the platform mix, and the region requirement.

Price your own macOS minutes on the pricing page, read the label specifications in the macOS runner catalog, and take the residency scope to EU data residency for GitHub Actions runners.