Your Go Builds Phone Home to Google. Every Single Time.

Every go build sends your organisation's build metadata to Google. Module names, versions, timestamps, your CI runner's IP address. Google retains those IPs for 30 days. A mid-size engineering team runs a hundred Go builds a day — each fetching dozens of modules. That is thousands of requests, every working day, carrying your technology choices to a US corporation subject to FISA Section 702.

What the metadata reveals

A Go build fetches dozens of modules. Each fetch is an HTTP request to proxy.golang.org carrying the module path, the requested version, and the source IP. Aggregate that over weeks and the picture sharpens:

• Technology stack. Module paths reveal your dependencies: which web framework, which database driver, which cloud SDK. A competitor or adversary learns what you build on.
• Release cadence. Version bumps in go.sum trigger fresh fetches. The pattern of fetches over time reveals how often you ship.
• Team structure. Different IP ranges fetching different module sets map to different teams and projects.
• Vendor relationships. Fetching cloud.google.com/go, github.com/aws/aws-sdk-go, or github.com/Azure/azure-sdk-for-go signals which cloud providers you use and when you migrate.

None of this is classified. All of it is commercially sensitive. And all of it lands on infrastructure controlled by a company that the Court of Justice of the European Union ruled cannot guarantee adequate protection under EU law.

The legal problem nobody budgets for

Schrems II (2020) invalidated Privacy Shield because US surveillance law — specifically FISA Section 702 — gives US authorities access to data held by US companies, without meaningful judicial oversight for non-US persons. The fundamental incompatibility between FISA 702 and GDPR Articles 44-49 has not been resolved. The EU-US Data Privacy Framework (2023) faces the same structural challenge.

For most SaaS tools, companies manage this with DPAs and Standard Contractual Clauses. For a build chain, nobody even thinks about it. There is no DPA with Google for proxy.golang.org. There is no contractual basis for the transfer. Your CI pipeline sends metadata to a US company hundreds of times a day and the legal basis is "we didn't notice."

A CTO at a regulated European company — financial services, healthcare, public sector — has a freedom-to-operate problem hiding in plain sight. Not because proxy.golang.org is malicious, but because the data transfer has no legal footing and the exposure is continuous.

The fix is one environment variable

export GOPROXY=https://goproxy.eu,https://proxy.golang.org,direct

goproxy.eu is a free, community-operated Go module proxy running on Scaleway in Paris, Amsterdam, and Warsaw. It caches modules regionally. Once a module is cached, subsequent fetches from that region never reach Google.

What changes:

• Popular modules (the vast majority of fetches) serve from European cache. No request to Google.
• Cold modules fall through to proxy.golang.org on first fetch, then cache regionally for everyone.
• No IP logging. Client IPs are stripped from access logs at the Envoy Gateway level and regex-redacted from all log pipelines before storage. They never reach our observability stack.
• EU jurisdiction only. Scaleway is a French company (Iliad Group). No CLOUD Act exposure, no FISA 702.

The fallback chain means you lose nothing. If goproxy.eu is down, your toolchain falls through to Google's proxy, then to direct VCS access. Builds never break.

For CI/CD at scale

A typical go build fetches 20-80 modules. A hundred builds a day — normal for a team of 15-20 Go developers with CI on every push — means 2,000-8,000 module requests per working day. After a week of cache warming, 90%+ serve from European cache. The remaining cold fetches — new dependencies, version bumps — still fall through to Google, but the metadata exposure drops from "everything, every time" to "occasional new modules."

GitLab CI:

variables:
  GOPROXY: "https://goproxy.eu,https://proxy.golang.org,direct"

GitHub Actions:

env:
  GOPROXY: "https://goproxy.eu,https://proxy.golang.org,direct"

Dockerfile:

ENV GOPROXY=https://goproxy.eu,https://proxy.golang.org,direct

No registration. No API keys. No authentication. One variable, all pipelines.

If this isn't enough, run it yourself

goproxy.eu strips IPs and runs on European infrastructure, but it is still someone else's server. If your threat model requires full control, the entire stack is open source: OpenTofu modules, Flux GitOps manifests, Envoy Gateway configuration, the Alloy log pipeline with IP redaction, alert rules, dashboards. Same code that runs in production.

Source repository | Architecture

The second article in this series covers the full engineering breakdown: architecture, cost per region, operational trade-offs, and what we'd do differently.

---

goproxy.eu is a Clouds of Europe community project.