Compute, cache, logs and metrics — all pinned
EU data residency for CI
Every build, cache object, log line and metric stays in the EU region you choose. Not just the compute — residency that only covers compute is not residency.
CI is an unusually complete data-processing surface. Your source code is checked out onto the runner, your secrets are decrypted into its memory, your build artefacts are written to its disk, and whatever your build prints ends up in a log. A residency claim that covers only the compute leaves three of those four somewhere else.
What is pinned
| Data | Contains | Location | Retention |
|---|---|---|---|
| Job compute | Source code, secrets, artefacts | Your chosen EU region | Destroyed at job end |
| Cache objects | Dependencies, build output | Same region | 14 days, or your policy |
| Job logs | Everything your build prints | Same region | 90 days, configurable |
| Metrics | Repository and workflow names | Same region | 13 months |
| Support access | Whatever an engineer reads | EU-based personnel only | Audit-logged |
How it is enforced
Region is a property of the runner group, not a preference on a job. A workflow using an EU-pinned label cannot be scheduled outside that region even if capacity is available elsewhere — the scheduler has no path to do it. Jobs queue rather than spill.
jobs: build: runs-on: runnerhut-8vcpu-ubuntu-2404-eu-central steps: - uses: actions/checkout@v4Versus GitHub-hosted runners
GitHub is a US-headquartered Microsoft subsidiary and does not publish an EU-only guarantee covering Actions compute, cache and logs on standard plans. If EU residency for build data is a hard requirement for you, that is the gap this exists to fill.
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.