Where Is My Build Data Stored?

Build work happens on the runner, on an encrypted volume created for that job and destroyed with the virtual machine when the build ends (runner security documentation). US and EU are the regions WarpBuild names publicly for that infrastructure, and BYOC moves the runner and its storage bucket into your own cloud account.

Answer

The question has one answer for the job itself and a short list of exceptions. Everything a build produces starts on the runner volume; the bytes that outlive the job are the ones a step deliberately sends somewhere else.

The volume in row one has a published size per platform, which is the number to check when a build writes large intermediate output. The per-job disk differs across them.

Sizes come from the WarpBuild runner catalog, checked on 2026-08-13. Every label in the table resolves to a fresh virtual machine with a fresh volume, so the disk starts empty on each run regardless of size.

Detail

Reading a workflow as a storage map

The clearest way to see placement is to annotate a workflow by destination. Three steps in this file write to three different places.

name: build
on:
  pull_request:

jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v5

      - name: Restore dependency cache
        uses: WarpBuilds/cache@v1
        with:
          path: ~/.npm
          key: npm-${{ hashFiles('**/package-lock.json') }}

      - name: Build
        run: npm ci && npm run build

      - name: Upload the build output
        uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/
          retention-days: 7

actions/checkout writes the repository onto the runner volume. npm ci and npm run build write node_modules/ and dist/ next to it. All of that is inside the per-job virtual machine and goes away when the job ends.

The cache step is the first exit. It copies ~/.npm into cache storage, which is WarpBuild cache storage on hosted runners and the object storage bucket in your own account on BYOC. The upload step is the second exit, and it does not touch WarpBuild at all: artifacts land in GitHub storage under the repository, retained 90 days by default unless retention-days shortens it (GitHub Actions limits, checked on 2026-08-13).

Choosing what goes into path is the whole control surface for the first exit. Naming a package manager download directory keeps registry archives in cache storage and keeps your working tree out of it.

Region control on hosted runners

US and EU are the regions WarpBuild names publicly. On enterprise plans, cloud runners can be deployed on region-specific infrastructure so the data you select stays in that region, and that option does not cover macOS instances. The US data residency page and the EU data residency page carry the wording a written residency clause needs.

The attestation behind the storage model is SOC 2 Type 2 with three Trust Services Criteria: Security, Availability, and Confidentiality. Request the report and the supporting security documentation at trust.warpbuild.com. The security review checklist for GitHub Actions runners puts that evidence next to the four other questions reviewers ask in the same session.

The BYOC path when the data plane has to be yours

BYOC runs on AWS, GCP, and Azure. A WarpBuild Stack creates the VPC, subnets, and one object storage bucket inside your account, and the bucket holds cache, container image layer caches, workflow artifacts the platform writes, and runner logs (BYOC documentation). Runner instances launch in the same account and terminate when the job finishes.

Two properties of that setup matter for a residency answer. The stack name, object storage location, and region cannot be changed after creation, so placement is decided once, before any runner exists. And the bucket sits under your own IAM, your own encryption settings, your own access logging, and your own lifecycle policy, which is where retention becomes a decision you make rather than a setting you read.

What placement costs

A hosted warp-ubuntu-latest-x64-4x job bills at $0.008 per minute, and BYOC Linux and Windows runners carry a WarpBuild fee of $0.002 per minute with the compute billed by your own cloud account (pricing page, checked on 2026-08-13). Every cost number here carries a source link and a checked-on date, and the same numbers appear on the pricing page.

Related Questions

Which regions does WarpBuild name for its own runner infrastructure?

US and EU. Enterprise plans can pin hosted cloud runners to region-specific infrastructure so the data you choose stays in that region, and that option does not apply to macOS instances. Start with the US data residency page or the EU data residency page.

What is stored outside the runner during a normal build?

Three things. Cache entries go to WarpBuild cache storage on hosted runners or to your stack bucket on BYOC, workflow artifacts and run logs go to GitHub storage under your repository at a 90 day default (GitHub Actions limits, checked on 2026-08-13), and snapshot images exist only if you turned snapshot runners on.

How do I keep every stored byte inside an account I control?

Run BYOC. The runner instances and the object storage bucket that holds cache, container image layer caches, and telemetry are created inside your own AWS, GCP, or Azure account, in the region you pick when you create the stack (BYOC documentation). Hand a reviewer the security review checklist alongside your own account evidence, and check per-minute rates on the pricing page.