Builds that stay where you put them
Region-specific infrastructure
Pin every job, cache object and log line to a named region. EU-only, US-only, or a specific data centre.
Job pinning
A workflow labelled for eu-central runs nowhere else, ever.
Cache locality
Cache objects are written and read in-region only.
Log residency
Job logs and metrics stay in the same boundary as the compute.
Data residency for CI is often overlooked, and it should not be: your source code, your secrets and your build artefacts all pass through the runner. Regional pinning covers compute, cache and logs together — pinning only one of the three is not residency.
Common questions
- What exactly gets pinned to a region?
- Compute, cache objects, job logs, metrics and support access. Pinning only compute is not data residency — three of the four places your code appears would still be elsewhere.
- What happens if the region is at capacity?
- Jobs queue. A region-pinned label has no code path to schedule elsewhere, which is precisely what makes the guarantee enforceable rather than advisory.
- Can different teams use different regions?
- Yes. Region is a property of the runner group, so labels route workloads independently and the choice is visible in code review.
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.