GitHub EU Alternative 2026: GDPR, CLOUD Act, and EU-Native Git Hosting

Post #700 in the sota.io EU Compliance Series

GitHub is the world's largest code hosting platform, used by over 100 million developers. Since its acquisition by Microsoft in 2018, GitHub has become part of Microsoft Corporation — a US company headquartered in Redmond, Washington, incorporated in the State of Washington. As a wholly owned subsidiary of Microsoft Corporation, GitHub Inc. is subject to the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713), which allows US law enforcement to compel disclosure of data stored on GitHub's infrastructure regardless of physical server location.

For EU development teams, this creates a specific compliance challenge: the primary coordination layer for software development — source code, issue trackers, CI/CD workflows, container registries, and access credentials — is held by a US entity subject to US surveillance law. This is not a hypothetical risk. Microsoft has a documented history of compliance with government requests, publishing a semi-annual Government Requests Report that shows thousands of requests per year across its services.

This guide covers what GitHub stores under US jurisdiction, the GDPR and NIS2 implications for EU teams, and the EU-native alternatives that provide equivalent development workflows without US-jurisdiction exposure.

What GitHub Stores Under US Jurisdiction

Source code and repository contents. The most obvious data category is source code. Every repository hosted on GitHub.com — public and private — is stored under Microsoft/GitHub Inc. US jurisdiction. This includes: the complete git history (every commit ever pushed), all branches and tags, repository configuration files, CI/CD workflow definitions (.github/workflows/), and any credentials accidentally committed (the reason GitHub maintains its secret scanning service).

For EU software companies, source code is often a core trade secret and competitive asset. Under a CLOUD Act warrant, the US government could compel GitHub to disclose the complete source code history of any repository, including private repositories, without the EU developer's knowledge. The warrant process can include a gag order preventing GitHub from notifying the repository owner.

For repositories containing regulated data — healthcare applications that process patient data, financial software that handles transaction data, legal tech applications that process privileged communications — the source code itself may contain data subject protections, encryption key references, or regulatory logic that constitutes sensitive business information under EU law.

GitHub Actions workflow logs and run data. GitHub Actions is the CI/CD platform integrated into GitHub repositories. Every Actions workflow run generates detailed logs: the complete output of each job step, environment variable values (including those marked as "secrets," which are redacted from logs but stored in GitHub's secrets management system), timing information, runner execution metadata, and artifact download URLs.

GitHub Actions runner logs are stored under US jurisdiction. For EU development teams using GitHub Actions for deployment pipelines, the workflow logs represent a complete record of deployment operations — which code was deployed, to which environment, at what time, by which user — stored under US law. For applications deploying to EU infrastructure that processes personal data, the deployment workflow logs are operational records that may be considered personal data processing records under GDPR Article 5(2) (accountability).

GitHub Copilot prompts and code completion data. GitHub Copilot is an AI pair programming tool that uses code context to generate completions. When a developer uses GitHub Copilot, the current file context — including surrounding code, comments, variable names, and function signatures — is transmitted to GitHub's AI inference infrastructure for processing.

GitHub Copilot's data processing is particularly sensitive for EU organizations because: the code context submitted to Copilot may include proprietary algorithms, confidential business logic, or data processing code that reveals the architecture of systems handling personal data. Under GitHub's Terms of Service for Copilot Business and Enterprise, code snippets submitted for completion are not used for model training (as of 2024), but they are processed by GitHub's US-jurisdiction infrastructure.

For NIS2 essential entities, the transmission of system code context to a US-jurisdiction AI service raises supply chain security concerns under Article 21(2)(d). The code context submitted to Copilot could reveal security-relevant implementation details of systems classified as critical infrastructure.

GitHub Packages and container registries. GitHub Packages provides package hosting for npm, Maven, RubyGems, Docker, and other package formats. For development teams using GitHub Packages as their container registry, every Docker image, npm package, or Maven artifact is stored under US jurisdiction. Container images for production deployments — containing the compiled application, its dependencies, and its configuration — are stored as GitHub Packages artifacts under US law.

For EU teams building regulated applications, the container images in GitHub Packages may include: compiled application code with embedded configuration, base images with OS-level security patches (revealing patch status), and build artifacts that enable reconstruction of the application logic. Under a CLOUD Act warrant, GitHub could be compelled to disclose container images for specific services.

GitHub Advanced Security — code scanning and secret scanning results. GitHub Advanced Security provides code scanning (SAST), secret scanning, and dependency review. The results of code scanning runs — including vulnerability findings, CVE references, and the code locations of identified vulnerabilities — are stored under US jurisdiction. For EU organizations with security disclosure obligations under NIS2 Article 23, the code scanning results stored in GitHub could reveal unpatched vulnerabilities in critical systems.

Secret scanning results are particularly sensitive: when GitHub's secret scanning identifies a credential in a repository (an API key, database password, or OAuth token), GitHub stores the finding under US jurisdiction, including the credential value itself. The credential may have been revoked by the time it appears in a secret scanning alert, but the historical record of exposed credentials is part of the data stored under CLOUD Act jurisdiction.

Issue trackers, pull requests, and project management data. GitHub Issues, Pull Requests, Projects, and Discussions contain operational information about software development: bug reports that may include user-reported error data, feature requests from customers, security vulnerability discussions, deployment coordination notes, and personnel performance data (commit attribution, review patterns, contribution statistics).

For EU organizations processing personal data in their issue trackers — user bug reports that include account identifiers, error logs that include session tokens, or customer feature requests that include personal information — GitHub Issues constitutes a personal data processing system under US jurisdiction. GDPR Article 30 (Records of Processing Activities) may require organizations to document GitHub as a data processor for this personal data.

GitHub Copilot Enterprise and knowledge bases. GitHub Copilot Enterprise extends Copilot with organization-specific knowledge bases: developers can create knowledge bases from repository content, documentation, and code, enabling Copilot to provide context-aware completions grounded in organization-specific code patterns.

Knowledge bases in GitHub Copilot Enterprise are stored under US jurisdiction. For EU organizations using Copilot Enterprise, the knowledge base may contain: architectural documentation, internal API specifications, security policies, compliance documentation, and proprietary development standards. This institutional knowledge, which may be classified as confidential business information under EU trade secrets law, is held by a US entity.

GDPR Implications of GitHub for EU Development Teams

GitHub as a data processor under GDPR Article 28. When an EU development team uses GitHub.com to host a repository containing personal data (test data with real user identifiers, bug reports with user information, or deployment configurations with user account references), GitHub Inc. acts as a data processor under GDPR Article 28. The team must have a Data Processing Agreement (DPA) with GitHub covering this personal data processing.

GitHub provides a DPA that covers data processing on GitHub.com, incorporating Standard Contractual Clauses (SCCs) for transfers to the US under GDPR Article 46(2)(c). The DPA covers GitHub's processing of personal data in the context of providing its services — including repository contents, workflow logs, and user account data.

Following Schrems II (C-311/18), using GitHub's SCCs requires a Transfer Impact Assessment (TIA) that evaluates whether the SCCs provide adequate protection given US surveillance law. The TIA for GitHub must address: the CLOUD Act risk (compelled disclosure of repository contents and workflow data), FISA Section 702 risk (collection of data transmitted to GitHub's infrastructure for intelligence purposes), and Executive Order 12333 risk (collection of data in transit). For EU organizations processing sensitive personal data in their development workflows, the TIA conclusion may require supplementary measures.

GitHub Actions secrets under GDPR Article 32. GitHub Actions secrets are encrypted values — typically API keys, database credentials, OAuth tokens — used in CI/CD workflows. Under GDPR Article 32, data controllers and processors must implement appropriate technical and organizational measures to protect personal data. For EU organizations that store database credentials (enabling access to EU user databases) or service account keys as GitHub Actions secrets, the secrets are held by a US entity whose access to the secrets is governed by US law.

GitHub's own documentation notes that secrets are encrypted and that GitHub employees do not have access to secret values. However, under a CLOUD Act warrant, GitHub could be compelled to disclose secret values or provide access to the encrypted storage containing them. For EU organizations with strict separation of duties requirements or regulatory obligations around credential management (NIS2 Article 21(2)(i), DORA Article 9), storing production credentials as GitHub Actions secrets may not satisfy their security requirements.

The EU developer's dilemma with GitHub. The practical reality is that GitHub has network effects that make alternatives difficult to adopt. The npm ecosystem, GitHub Marketplace integrations, GitHub Copilot, and GitHub Actions have created a development workflow that is deeply integrated with GitHub.com's infrastructure. An EU development team seeking to move off GitHub.com faces:

• Migration of git history, issues, and pull requests to a new platform
• Reconfiguration of CI/CD pipelines from GitHub Actions to a platform-native CI/CD
• Loss of GitHub Marketplace integrations
• Developer familiarity and onboarding costs

This migration complexity is real and should be factored into any EU compliance migration plan. For organizations with genuine data sovereignty requirements, the migration effort is a one-time cost; the ongoing GDPR risk from GitHub's US jurisdiction is a continuous cost.

EU-Native Alternatives to GitHub

Forgejo — EU-hosting compatible open-source git. Forgejo is an open-source, community-managed fork of Gitea (which itself is a Go implementation of a self-hosted git service). Forgejo provides: git repository hosting, issue tracking, pull request workflows, project management (kanban boards), package registries (npm, Docker, Maven, PyPI), and Actions-compatible CI/CD (Forgejo Actions is compatible with GitHub Actions YAML syntax).

Forgejo is not a hosted service — it is self-hosted software. Deployed on EU-jurisdiction infrastructure (Hetzner, OVHcloud, Scaleway), Forgejo provides a fully EU-sovereign development workflow. The Forgejo organization is a community nonprofit without a US corporate parent. For EU development teams requiring EU jurisdiction, self-hosted Forgejo on EU infrastructure is the most complete equivalent to GitHub.com functionality.

Gitea — self-hosted git on EU infrastructure. Gitea (the upstream project from which Forgejo was forked) is a lightweight, self-hostable git service written in Go. Gitea provides: repository hosting, issue tracking, pull requests, project boards, package registry, and Actions-compatible CI/CD. Like Forgejo, Gitea is self-hosted software; its jurisdictional properties depend entirely on where it is hosted.

For teams choosing between Forgejo and Gitea, Forgejo is the community-recommended choice for EU sovereignty: Forgejo is governed by a community process without a corporate parent, while Gitea Inc. (the company behind Gitea) is US-incorporated. The software itself is functionally equivalent; the governance and corporate structure differ.

GitLab — EU-region SaaS with US parent. GitLab Inc. is a US-incorporated company (San Francisco, California). GitLab.com (the SaaS offering) stores EU customer data in US-region infrastructure, though GitLab is gradually expanding EU regional options. GitLab also offers GitLab Dedicated (single-tenant, EU-region deployment) for enterprise customers.

The EU-region GitLab deployment reduces data residency concerns for repository contents stored in the EU region, but GitLab Inc. remains a US entity subject to CLOUD Act. The management plane — the GitLab.com authentication, user management, and billing infrastructure — is US-jurisdiction. For EU organizations requiring full jurisdictional clarity, GitLab's EU region reduces but does not eliminate the CLOUD Act exposure.

Self-hosted GitLab (Community Edition or Enterprise Edition) on EU-jurisdiction infrastructure provides full EU sovereignty: the installation is controlled by the EU organization, and no US entity has access to the self-hosted instance.

Codeberg — EU-native hosted git. Codeberg.org is a hosted git service run by Codeberg e.V., a German nonprofit association incorporated in Berlin. Codeberg provides hosted Forgejo repositories, issues, pull requests, and CI/CD (Woodpecker CI integration). Codeberg is free for open-source projects and small teams; paid tiers are available for organizations.

For EU open-source projects or small development teams that need a hosted git platform without self-hosting overhead, Codeberg provides EU-native hosting (servers in Germany, EU nonprofit governance) at no cost for public repositories. Codeberg does not provide the same enterprise feature set as GitHub (no Copilot equivalent, limited Actions ecosystem), but for core git hosting and collaboration, Codeberg is a fully EU-sovereign alternative.

Woodpecker CI — EU-compatible CI/CD. For teams migrating from GitHub Actions to self-hosted CI/CD, Woodpecker CI is an open-source pipeline engine that integrates with Forgejo, Gitea, and GitLab. Woodpecker CI uses a pipeline syntax similar to GitHub Actions (YAML-based, step-by-step jobs) and can execute on EU-jurisdiction infrastructure. Combined with self-hosted Forgejo or Gitea, Woodpecker CI provides a complete EU-sovereign GitHub Actions equivalent.

Deployment: From EU Git to EU Application Hosting

Migrating from GitHub.com to EU-native git hosting is the first step in building a fully EU-sovereign software development lifecycle. The second step is ensuring that the deployment target for applications built in the EU git workflow is also EU-sovereign.

For EU development teams hosting their code on Forgejo or Codeberg, the natural deployment target for web applications is an EU-native PaaS that integrates with the git workflow:

sota.io git-connect for EU deployments. sota.io connects to git repositories (including self-hosted Forgejo and Gitea instances) and provides the same git-push-to-deploy workflow as Vercel or Render — but on EU-sovereign infrastructure. When code is pushed to a branch in Forgejo, a webhook triggers a sota.io build, produces a Docker container, and deploys to the EU-sovereign sota.io runtime.

The complete workflow — from code commit to deployed application — stays within EU jurisdiction: Forgejo (EU-hosted) → sota.io build (EU infrastructure) → sota.io runtime (EU-sovereign containers) → application serving EU users. No US-incorporated entity processes the code, build artifacts, deployment configuration, or application runtime.

For teams that use GitHub Packages as their container registry, sota.io's container registry integration provides an equivalent EU-sovereign artifact store: build the container in Woodpecker CI or a Forgejo-integrated pipeline, push to sota.io's registry, and deploy from the registry to the sota.io runtime.

GitHub vs. EU-Native Git: Compliance Comparison

Migration Path from GitHub to EU-Native Git Hosting

Phase 1: Repository migration. GitHub's repository export tools produce a git bundle that can be imported directly into Forgejo, Gitea, or GitLab. The migration preserves git history, branches, and tags. Issue trackers and pull requests require separate migration (Forgejo provides a GitHub importer that migrates issues, comments, and labels via the GitHub API). Start with a single low-traffic repository to validate the migration process before migrating critical repositories.

Phase 2: CI/CD pipeline migration. GitHub Actions workflow YAML files are partially compatible with Forgejo Actions and Woodpecker CI, but platform-specific actions (actions/checkout, actions/setup-node from GitHub Marketplace) require equivalent alternatives. Forgejo Actions supports a subset of GitHub Actions syntax; Woodpecker CI uses a different but similar pipeline syntax. Plan for 1-3 days of pipeline migration effort per complex repository.

Phase 3: Secrets and credentials migration. Audit all GitHub Actions secrets and repository secrets. Migrate secrets to the equivalent secrets management on the target platform (Forgejo repository secrets, Woodpecker CI secrets, or an external vault). Rotate any credentials that were stored as GitHub secrets during the migration.

Phase 4: Dependency on GitHub ecosystem. Identify GitHub-specific integrations: npm packages published to GitHub Packages, GitHub Apps installed in repositories, GitHub OAuth applications in use by the team. Each requires a migration path — npm packages to npmjs.com or a private EU registry, GitHub Apps to equivalent integrations on the target platform, OAuth applications to the target platform's OAuth.

Phase 5: Cut over and monitoring. Update git remote URLs on developer workstations, CI/CD runners, and deployment triggers. Monitor for missed webhooks or pipeline failures during the transition period. Maintain read-only GitHub mirror access for 30-60 days to catch any remaining dependencies.

See Also

• Vercel EU Alternative 2026 — Deployment platform jurisdiction: Vercel's US entity exposure
• AWS CodePipeline EU Alternative 2026 — CI/CD pipeline jurisdiction in AWS
• AWS CodeCommit EU Alternative 2026 — AWS-native git hosting under US jurisdiction
• AWS ECR EU Alternative 2026 — Container registry jurisdiction