---
title: "GitHub Actions data residency: where CI data goes"
description: "Trace source code, caches, artifacts, logs, and control-plane data separately from runner location, with a practical CI residency review."
url: https://9apes.com/blog/github-actions-data-residency/
---

# GitHub Actions data residency: where CI data goes

Putting a GitHub Actions runner in a particular region controls where the job
executes. It does not automatically move the repository, remote caches, artifacts,
logs or backups into that region.

To assess residency, trace the whole workflow: where data is processed, where
copies are stored, and who can access or transfer them. This is an architecture
review guide, not a tested residency guarantee for any provider.

## Map the data leaving each job

Choose a representative workflow and inspect both successful and failed runs.
A failed test may print sensitive data or upload a workspace that successful
runs never expose. Use this inventory to identify the evidence you need:

| Data | Potential copies to inventory | Evidence to collect |
| --- | --- | --- |
| Source code | Git repository, checkout, build context, image layers | Repository service, runner location, builder endpoint, Dockerfile |
| Dependency and build caches | Package cache, local builder disk, remote cache | Cache action inputs, build cache backend, storage contract |
| Artifacts | Test reports, bundles, images, release attachments | Upload steps, destination accounts, replication and retention rules |
| Logs and summaries | Actions job logs, runner diagnostics, observability exports | Log sinks, workflow output, retention settings, access policies |
| Control-plane data | Job assignment, run status, identity, API calls | GitHub deployment type, integrations, provider data commitments |
| Operational copies | Backups, support attachments, engineer downloads | Backup configuration, support process, approved access locations |

For each row, record execution location, storage location and access conditions
separately. Include remote builders: sending a Docker build context creates
another copy, and copying source into the final image makes the registry a
source-code destination too. Inspect intermediate cache exports independently.

## Check remote caches separately

GitHub documents that dependency caches from self-hosted workflows use
GitHub-owned cloud storage. Customer-owned storage for this feature is a GitHub
Enterprise Server capability. A self-hosted runner on GitHub.com does not redirect
`actions/cache` into your cloud account.
[GitHub dependency caching](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching)

BuildKit's `type=gha` backend adds a separate path to the Actions cache service.
The builder's location does not select the cache's physical storage location.
[Docker GitHub Actions cache backend](https://docs.docker.com/build/cache/backends/gha/)

Distinguish runner-local files, package caches, builder-local caches and exported
build caches. Inspect their selected paths: a broad cache directory can include
private packages, generated source and configuration. Do not store secrets in it.
If a destination conflicts with policy, change or disable that cache backend and
check the effect on build reliability and performance.

## Follow artifacts, logs and replicas

Give each uploaded report, image, screenshot and crash dump a destination,
retention period and owner. Review whole-workspace uploads carefully. Deleting
the runner does not delete previously uploaded artifacts or logs.

Check replication as well as the first destination. [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html)
supports cross-Region and cross-account replication; [S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
also supports replication to other Regions. Backups and disaster-recovery
locations belong in the inventory even if normal builds never use them.

Treat logs as build output. Request bodies, source snippets and database rows can
appear in diagnostics; secret masking does not classify every sensitive value.
Review Actions logs, runner diagnostics, controller logs and observability
exports separately. GitHub recommends preserving ephemeral runner application
logs externally, creating another destination to assess.
[Ephemeral runner guidance](https://docs.github.com/en/actions/reference/runners/self-hosted-runners#ephemeral-runners-for-autoscaling)

## Check your GitHub deployment's commitments

Self-hosted runners still communicate with GitHub for job coordination and the
services their workflows use. An endpoint list helps define network policy,
but it does not prove storage or backup locations.
[Runner communication requirements](https://docs.github.com/en/actions/reference/runners/self-hosted-runners#communication)

GitHub Enterprise Cloud with data residency is a distinct offering on `GHE.com`.
Its regional storage commitments cover specified customer content and Actions
data, while exceptions include certain telemetry, billing and support data.
Read both the commitments and exceptions for your deployment. Do not apply these
terms to an ordinary GitHub.com organization.
[GitHub data residency boundaries](https://docs.github.com/en/enterprise-cloud@latest/admin/data-residency/about-storage-of-your-data-with-data-residency)

A regional IP address or low latency cannot establish where a provider keeps
replicas or processes support requests. Pair configuration and network evidence
with the provider's applicable terms.

## Review one workflow end to end

Search for likely transfer points:

```bash
rg -n --hidden \
  'uses:|cache-(from|to):|upload-artifact|download-artifact|aws s3|docker push|buildx|curl|wget' \
  .github/workflows
```

Follow reusable workflows, composite actions, invoked scripts and package hooks.
The workflow YAML alone may not show every external connection.

For each destination, keep a compact record:

```text
Workflow revision and step:
Data classes sent:
Service and destination account:
Execution and primary storage locations:
Replica and backup destinations:
Retention and deletion owner:
Access, support and subprocessor conditions:
Configuration or contract evidence:
Unresolved questions and responsible owner:
```

Validate with synthetic data in a disposable environment:

1. Run success and failure paths, including an empty cache and configured fallbacks.
2. Inspect uploaded files, caches, job summaries and diagnostic logs.
3. Compare observed destinations with the approved inventory.
4. Check replication, retention, deletion and access settings at each destination.

A distinctive harmless marker can help track where output appears. It cannot
reveal a provider's unobserved internal replicas. Keep newly discovered or
unverified destinations open as review items rather than assuming they are
in-region.

## Map legal requirements to the inventory

Residency evidence supplies facts for legal review; it does not determine
whether processing or a transfer is lawful. GDPR permits international transfers
under conditions such as adequacy decisions or appropriate safeguards. It is not
a blanket requirement to keep every CI byte in the EU.
[EU international-transfer guidance](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/rules-international-data-transfers_en)

For India's DPDP framework, review section 16 alongside applicable commencement
notifications, rules and sector requirements. Have the legal owner map the data
classes, destinations and access conditions to the obligations currently in force.
[DPDP Act](https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf)

## Ask providers for a specific commitment

Replace “CI stays in-region” with a requirement naming the data and services:

> Build execution and the approved image registry must remain in the selected
> region. Repository hosting, logs, remote caches, backups and support access
> each need separately reviewed destinations and terms.

This is an example requirement, not a guarantee from 9apes or another provider.
Ask about execution regions, disk lifecycle, cache and log destinations,
subprocessors, support access and regional failover. Assign an owner to every
exception and revisit the inventory when a workflow, provider or recovery plan
changes.