Keeping Your Build Pipeline in the EU When GitHub Actions Won’t

Your production environment is in the EU. Your database is in the EU. Your contracts say the data stays in the EU. And every time a pull request triggers a build, your source code, your dependencies, and your build artifacts run through infrastructure that isn’t.

That’s a gap a lot of teams don’t notice until someone in legal or security asks about it directly, because production residency and CI/CD residency are two separate questions that get treated as one.

What GitHub Actions Actually Offers EU Teams Today

To be fair to GitHub, this isn’t a completely unaddressed problem on their end anymore. GitHub launched EU data residency for GitHub Enterprise Cloud customers in October 2024, and Enterprise accounts can also configure “larger runners” tied to specific Azure regions, including a small number of EU locations, through Azure VNET integration.

The catch is that both of those options are Enterprise Cloud features, requiring the higher-tier plan plus additional networking configuration most teams haven’t set up. For everyone on GitHub Team or standard Actions without that configuration, which is the majority of organizations using GitHub Actions, hosted runner location is simply not disclosed and not selectable. GitHub’s own community forums are full of teams asking for regional runner control and being told, as recently as the past couple of years, that standard hosted runners don’t support it. If your build pipeline runs on GitHub-hosted runners without Enterprise-tier residency configuration, your code is very likely executing on US-based infrastructure by default, regardless of where your production systems live.

Why This Matters Even When Production Is Already Compliant

It’s tempting to treat this as a technicality once the systems that actually hold customer data are EU-resident. That’s not quite right, for a few reasons that come up in real compliance reviews.

Source code itself is often the asset an organization cares most about keeping under EU jurisdiction, particularly for regulated software vendors, defense-adjacent suppliers, or any company where the codebase is the actual intellectual property at stake, not just the data flowing through it. Build artifacts, container images, and dependency caches can also carry real customer data if your test suites use production-like fixtures or if secrets management isn’t airtight, meaning your CI pipeline may be processing more sensitive material than “it’s just running tests” suggests.

And for regulated industries specifically, DORA and similar frameworks are pushing financial entities to document their full technology supply chain, not just where production data sits, which puts CI/CD infrastructure squarely in scope for the kind of infrastructure mapping we’ve covered in our look at DORA’s concentration risk and exit strategy requirements.

Self-Hosting on Amsterdam Hardware Closes the Gap Directly

Self-hosted GitHub Actions runners solve the location question cleanly, regardless of your GitHub plan tier, because the runner is a machine you control. Point it at hardware in Amsterdam, and the location question has a straightforward, verifiable answer, without needing Enterprise Cloud licensing or Azure VNET configuration to get there.

We’ve covered the general economics of self-hosted runners against GitHub’s hosted per-minute pricing in detail in our breakdown of the real cost math behind self-hosted GitHub Actions runners, including the specific crossover point where fixed infrastructure costs beat metered billing. That math holds the same way in Amsterdam as anywhere else. What changes for an EU-focused team is the reason for self-hosting in the first place: it’s not purely a cost decision, it’s the direct way to guarantee your build pipeline never leaves EU jurisdiction, on hardware that’s currently sitting available rather than waiting on procurement.

A Medium v4 or Large v4 configuration in Amsterdam, both currently in stock, gives a team enough parallel capacity for a real CI workload without a custom build-out. Every server ships with dual 10Gbps private networking as standard, keeping runner-to-artifact-storage traffic fast without competing with public bandwidth.

What This Doesn’t Solve on Its Own

Self-hosting the runners fixes where the compute executes. It doesn’t automatically fix everything upstream of that. If your source repository itself is hosted on GitHub.com without Enterprise Cloud’s EU data residency configuration, your code still lives on US infrastructure at rest, even if every build now executes in Amsterdam. Self-hosted runners solve the execution location problem specifically; repository hosting location is a separate question worth checking alongside it, since the two are easy to conflate and only one is addressed by moving your runners.

Getting Started

Current Amsterdam configurations suitable for self-hosted CI, including Medium v4 and Large v4, are available now rather than on a procurement timeline. For the general case on running DevOps workloads with full root access, see our pieces on optimizing CI/CD pipelines with OpenStack-powered private cloud and full root access for DevOps teams, and for the broader EU data residency picture beyond CI/CD specifically, see our breakdown of EU data residency versus data sovereignty.

FAQ

Does GitHub Actions offer EU-only hosted runners?

Only for GitHub Enterprise Cloud customers, through EU data residency (available since October 2024) or Azure VNET-based “larger runners” tied to specific EU regions. Standard GitHub Actions plans don’t disclose or allow selection of hosted runner location.

If my production data is already EU-resident, does that cover my CI/CD pipeline too?

Not automatically. Production data residency and CI/CD execution location are separate infrastructure questions. Source code, build artifacts, and dependency caches can run through non-EU infrastructure even when your production database and application servers are fully EU-based.

Does self-hosting a runner in Amsterdam also move my GitHub repository to the EU?

No. Self-hosted runners control where your build jobs execute, not where your source repository is stored at rest. If repository storage location matters for your compliance requirements, that’s a separate consideration involving GitHub Enterprise Cloud’s data residency feature or an alternative git hosting setup.

What hardware is actually available now for EU-based CI/CD self-hosting?

Medium v4 and Large v4 configurations are currently in stock in OpenMetal’s Amsterdam data center, available for immediate deployment rather than a multi-week procurement wait.