Data Residency

Data residency is the requirement that a defined set of data is stored and processed inside a named geography, such as a country, an economic area, or a single cloud region. The requirement comes from a statute, a customer contract, or an internal policy, and it covers the machines that process the data as well as the disks that hold it.

For a GitHub Actions workload the question lands on the build itself. A job checks out source code, writes caches, uploads artifacts, and streams logs, and each of those steps puts data somewhere that a reviewer will ask about.

Definition

A residency requirement has three parts, and a requirement missing any of them is ambiguous enough to argue about later.

1. The data in scope. Personal data about customers, regulated records, source code, or everything the company holds. Scope drives everything downstream, because a rule written for customer records may or may not reach a build cache that contains a compiled binary.
2. The geography. A country, an economic area such as the European Economic Area, a list of approved countries, or one named cloud region. Granularity matters: "the EU" and "eu-central-1" are different promises, and only one of them survives a region outage without renegotiation.
3. The operations covered. Storage at rest is the common floor. Stronger requirements add processing, backups, disaster recovery copies, and remote access by staff sitting outside the geography.

The third part is where build systems get caught. A rule that names storage alone is satisfied by a bucket in the right region. A rule that names processing reaches the compute too, which means the virtual machine that untars a repository and runs a compiler has to sit inside the geography as well.

Requirements of this shape usually originate in one of four places. Data protection law is the most cited: the GDPR does not mandate EU-only storage in general terms, and instead restricts transfers of personal data outside the European Economic Area unless a transfer mechanism applies. Many teams answer that restriction by keeping the data in region, which is how a legal transfer question turns into an infrastructure requirement. The other three sources are customer contracts with a data processing addendum that names a region, public sector procurement rules that require in-country hosting, and internal policy written by a security team that wants one answer for every auditor.

Regulatory framework names describe the concept here and carry no statement about any vendor's compliance posture.

Residency, sovereignty, and localization

Buyers use these three words interchangeably, and they mean different things. Getting the distinction straight early saves a review cycle, because the evidence each one wants is different.

Residency is a placement question and it is answered with configuration. Sovereignty is a legal question and it is answered with contracts and corporate structure. A workload can sit entirely on machines inside a geography while the company operating those machines answers to a different jurisdiction, which satisfies residency and leaves sovereignty open. Localization is the strictest of the three, because it can forbid the export that residency merely discourages.

Control plane and data plane

Any managed build platform splits into two halves, and a residency answer has to cover both.

The data plane holds the material a build touches: the source checkout, dependency caches, compiled artifacts, container image layers, and job logs. The control plane holds the records that make scheduling work: which job was queued at what time, which machine claimed it, how long it ran, usage counters for billing, and audit events.

Reviewers accept control plane metadata crossing a boundary far more often than they accept data plane content crossing it, and the two get conflated in vendor answers. Write the answer as two sentences, one per plane, and name what each holds.

Adjacent controls that residency does not replace

Three controls sit next to residency and get substituted for it during reviews.

Encryption limits who can read data. Encrypted bytes in the wrong geography are still in the wrong geography, so encryption answers confidentiality and leaves placement unanswered.

Access control limits who can reach a system. A team in another country with production access is a common finding in residency reviews even when every machine sits in the right region.

Retention limits how long data survives. Short retention shrinks exposure and lowers the stakes of a placement answer without changing it, which is why ephemeral machines make residency conversations easier.

Example

A single GitHub Actions run produces several distinct classes of data, and a residency review asks about each class separately. The table below lists the classes that come up in almost every review, what creates them, and where they typically land.

Here is a workflow that produces four of those classes in five steps. The runs-on label picks the machine, which makes it the one line in the file that decides where the compute half of the answer lands.

name: build
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4
        with:
          path: ~/.cache/go-build
          key: go-build-${{ hashFiles('go.sum') }}
      - run: go build ./...
      - run: go test ./...
      - uses: actions/upload-artifact@v4
        with:
          name: server
          path: bin/server

Read that file top to bottom as a residency reviewer would.

The checkout step writes the full repository to the runner's disk, so the physical location of the runner is the first answer owed. Managed runner labels of this shape encode the operating system, the architecture, and the machine size, and the fleet behind the label decides the region, so the label alone does not tell a reviewer the geography. That answer comes from the fleet configuration.

The cache step writes to a bucket owned by whichever cache backend the fleet is wired to. That bucket is a separate location from the runner and needs its own region answer, and cache entries outlive the job, which is why retention comes up here rather than at checkout.

The upload step writes the compiled binary to an artifact store with its own location and its own retention window. Logs from the two run steps stream to GitHub and are kept with the run record. Secrets, if the workflow used any, would be delivered from the secret store into the job environment.

So one workflow file, five steps, and four storage locations under as many as three operators. Only one of those locations is chosen inside the workflow file, and the rest come from platform and fleet configuration that no reviewer can read off the YAML.

The questions a residency review actually asks

Turning the table above into a review checklist gives seven questions. A complete answer names a place for each one.

1. Scope and geography. Which data classes are in scope, and what is the geography, stated at the granularity the requirement uses.
2. Compute location. Where do runner machines execute, and does that hold for every job, including matrix legs and reusable workflows called from other repositories.
3. Storage locations. Where does each of the cache bucket, artifact store, log store, and container registry sit.
4. Lifetime. How long each of those stores keeps data, and whether the runner disk is destroyed when the job finishes.
5. Access from outside. Who can reach any of those systems from outside the geography, including support staff and automated tooling.
6. Metadata. Which control plane records leave the geography, and whether the requirement covers them.
7. Evidence. What artifact proves each answer: a region setting in a console, an infrastructure definition in version control, a bucket policy, an audit report, or a contract clause.

Question two is the one that changes most often in practice, because it moves with the runner fleet a workflow points at. A job on a hosted pool executes wherever the platform's pool for that label lives. A job on a self-managed fleet executes in the account and region that created the machines, which is why teams with strict requirements often run builds inside their own cloud account and answer questions two through five from their own infrastructure definitions.

Question six catches teams late. A build platform that starts and stops machines has to keep records of what it started, and those records are metadata rather than build content. Deciding early whether the requirement reaches metadata prevents a rewrite of the answer during the review.

Related Terms

• BYOC, the model where runners boot inside your own cloud account: the model that puts compute and storage placement under your own account and region choices.
• EU data residency for GitHub Actions runners: how the paths above apply to an EU footprint, with the evidence a review collects.
• US data residency for GitHub Actions runners: the same walkthrough for a US footprint.
• Where GitHub Actions runners actually run: what decides the machine a job lands on and how to find out.
• WarpBuild BYOC documentation: how a cloud account connection, a stack, and a custom runner fit together, including the region and bucket choices made at stack creation.
• WarpBuild security documentation: compute isolation, storage handling, and the compliance evidence available through the trust center.
• WarpBuild pricing: per minute rates by runner type.