Where Do GitHub Actions Runners Run?

Answer

WarpBuild runs every GitHub Actions job on an ephemeral virtual machine, created for that job either in WarpBuild-operated infrastructure or inside your own cloud account on BYOC. US and EU are the regions WarpBuild names for the hosted fleet, and on BYOC the machine starts in whichever region of your AWS, GCP, or Azure account you pinned when the stack was created.

That answer splits into three placements. A security or procurement review normally needs all three named, because the machine, the storage under it, and the bill land in different places.

Every label in that catalog resolves to a machine under one of those three rows.

Two boundaries stay fixed no matter which row you pick. GitHub still holds the repository, the workflow definitions, and the secrets, because a runner is a machine that polls GitHub and streams results back to it. The WarpBuild control plane still queues jobs, starts and destroys runner VMs, and meters usage, which it does from outside the runner region. The BYOC setup documentation covers the account connection side, and the pricing page carries the per-minute rate for every label.

Detail

The machine a job gets, and how long it lives

Each runner runs in its own virtual machine. The VMs are created on demand and destroyed after each build, so nothing survives from one job into the next. Each runner also gets its own encrypted storage volume, created on demand and destroyed after the build, and when caching is enabled the cache is encrypted and stored in a location that only your runner can reach. WarpBuild does not access or store any build secrets; secrets live in your source code repository and reach only the runner environment. The WarpBuild security documentation is the reference for all four of those controls.

For a security review, that turns into four recorded facts:

• Isolation unit. One virtual machine per job, with no shared tenancy between builds.
• Machine lifetime. Created at job start, destroyed at job end. There is no long-lived registered runner accumulating state across pull requests.
• Storage lifetime. The volume is encrypted, is created with the machine, and is destroyed with it. Cache storage sits behind the same boundary.
• Secret handling. Build secrets pass from GitHub into the runner environment and are never stored by WarpBuild.

Those four answers are the ones a reviewer writes down, and the security review checklist for GitHub Actions runners walks the rest of the questionnaire.

Where each class of build data sits

"Where does it run" is really a question about five data classes with five different holders. Naming them one at a time is what closes a review.

The fourth row is the one enterprise conversations spend the most time on, because it is the part that stays outside the region you pinned. It carries orchestration metadata: which job is queued, which label it asked for, when a VM started, when it terminated, and the counters that produce your invoice. If a GitHub IP allow list or a GitHub Enterprise Server instance restricts inbound traffic, the control plane egress IPs listed in the security documentation are what your network team needs.

The hosted fleet, by platform

Hosted runners execute in WarpBuild infrastructure across four platforms. Labels, sizes, and rates below come from the WarpBuild runner catalog and the pricing page, checked on 2026-08-13.

On the enterprise tier, hosted cloud runners can be deployed on region-specific infrastructure so that the data you choose stays in the US or the EU region you asked for. One documented exception belongs in any residency scope: 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 residency commitment to the repositories carrying regulated data. The full path-by-path breakdown lives on US data residency for GitHub Actions runners and EU data residency for GitHub Actions runners.

BYOC is the strongest residency answer

BYOC moves the placement decision inside a boundary you already own and already audit. The runner instance, the disk under it, and the object storage bucket that holds cache, container image layer cache, logs, and workflow artifacts are all resources in your own cloud account, in a region you selected, visible in your own console and on your own bill. Evidence for an auditor comes from your infrastructure rather than from a vendor statement.

Setup is three steps in the BYOC setup documentation: connect the cloud account, which creates the role or service account WarpBuild uses; create a stack, which fixes the region, the VPC, and the object storage location; then create custom runners with the instance types, disks, and IP configuration you want. The stack name, storage location, and region cannot be changed after creation, so the region decision happens before any runner exists. That property is useful during a review, because the constraint is enforced by the stack rather than by a setting somebody can flip later. The AWS path is documented end to end at run GitHub Actions runners in your own AWS account.

One per-cloud caveat is worth stating plainly. BYOC on Azure is currently enabled for East US only, and additional regions go through [email protected]. An Azure-only estate therefore has no EU BYOC placement today without that conversation, while AWS and GCP stacks can be created in an EU region directly.

The workflow file barely changes

Placement is configured at the account and stack level, so hosted jobs keep the same warp- labels wherever the fleet sits. BYOC jobs change the label, because a custom runner registers under the runner ID shown on the custom runners page, always prefixed with warp-custom-.

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

jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        runner:
          - warp-ubuntu-latest-x64-8x
          - warp-ubuntu-latest-arm64-8x
          - warp-windows-latest-x64-8x
    runs-on: ${{ matrix.runner }}
    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

The test job runs on the hosted fleet. The regulated-build job runs on an instance in the account and region behind the eu-release stack. Naming stacks after their purpose keeps the workflow file readable as a record of where each job executes, which is what a reviewer will ask you to show.

What each placement costs

Rates come from the pricing page, checked on 2026-08-13.

Every cost claim here carries a number, a source, and a date, which is the standard the rest of the site holds to. For the hosted column: warp-ubuntu-latest-x64-4x costs $0.008 per minute against $0.012 per minute for the 4-core Linux larger runner at the same 4 vCPU and 16 GB shape, which is 33 percent lower list price (GitHub billing reference, checked on 2026-08-13). For the BYOC column the arithmetic depends on your own rate card, since WarpBuild charges the $0.002 per minute fee and the instance time lands on your cloud bill.

Evidence a reviewer can collect

Request the report and the supporting security documentation there. Pair it with two artifacts you generate yourself: the stack region and bucket location from your own cloud console on BYOC, and the workflow files showing which labels each repository uses. Those three pieces answer where the runners run in a form an auditor can keep.

Related Questions

Where do WarpBuild GitHub Actions runners run?

On ephemeral virtual machines. Hosted runners execute in WarpBuild-operated infrastructure, and US and EU are the regions WarpBuild names publicly. BYOC runners execute on instances inside your own AWS, GCP, or Azure account, in the region you pinned when you created the stack. The BYOC setup documentation covers the account connection and the stack.

Is a runner machine reused between jobs?

No. Each runner runs in its own virtual machine, the VMs are created on demand and destroyed after each build, and each runner gets its own encrypted storage volume that is created and destroyed the same way. WarpBuild does not access or store any build secrets. The security documentation states each of those controls.

Can I pin GitHub Actions runners to the US or the EU?

Yes. On the enterprise tier, hosted cloud runners can be deployed on region-specific infrastructure in the US or the EU. On BYOC the region is fixed when the stack is created and cannot be changed afterward, so the placement decision happens before any runner exists. See US data residency for GitHub Actions runners and EU data residency for GitHub Actions runners.

Which placement answers a data residency review most directly?

BYOC. The instance, the disk under it, and the object storage bucket holding caches, artifacts, and logs are all resources in your own cloud account, in a region you chose, visible in your own console and your own bill. BYOC on Azure is currently enabled for East US only. The AWS BYOC page walks the full setup, and the security review checklist for GitHub Actions runners covers the questionnaire around it.