Beyond the Outages: Why Digital Autonomy is Driving a Migration to Forgejo

For many developers, the decision to leave GitHub is often framed as a reaction to service instability. However, a growing movement of engineers and even national governments is realizing that outages are merely symptoms of a deeper structural issue: the loss of digital autonomy. When the platform you rely on for your primary source of truth is no longer an independent entity but a unit of a larger AI-driven corporate machine, the risk profile shifts from "technical reliability" to "existential control."

This shift is exemplified by the recent launch of code.overheid.nl, a self-hosted Forgejo instance for the Dutch government, and a broader trend of developers migrating their canonical repositories to sovereign infrastructure.

The Structural Shift: From GitHub to CoreAI

To understand why developers are leaving, one must look past the downtime. While GitHub logged 257 incidents between May 2025 and April 2026, the more telling detail is the reason for the instability. GitHub's CTO, Vlad Fedorov, attributed the load to "agentic AI workflow growth," noting that capacity needs to scale 30x to keep up. The outages are a direct byproduct of GitHub doubling down on AI features at the expense of core stability.

More critical is the change in governance. In August 2025, Thomas Dohmke stepped down as CEO, and GitHub was absorbed into Microsoft's CoreAI division. This effectively ended the era where GitHub operated at arm's length from Microsoft. Today, pushing code to GitHub means pushing it to a unit of Microsoft's AI organization, where product decisions are driven by the mission to build an end-to-end Copilot stack.

The AI Training Default and the "Opt-Out" Trap

One of the most contentious changes occurred in April 2026, when GitHub flipped the default for user-interaction data (inputs, outputs, and code snippets) to opt-in for AI training for Copilot Free, Pro, and Pro+ users.

This change introduces three significant risks for maintainers:

1. Default Contribution: Users are now contributing to model training by default unless they manually opt out.
2. Lack of Repository Control: There is no repository-level switch. A maintainer cannot prevent their codebase from becoming training material if a contributor using Copilot interacts with it.
3. Blurry Privacy Lines: While GitHub claims not to use private repositories "at rest" for training, it still collects interaction context generated while using Copilot inside those private repos.

For those who value the integrity of their intellectual property and the specific terms of their licenses, this "opt-out" model is an unacceptable compromise.

The Jurisdictional Reality: FISA and the CLOUD Act

Beyond corporate policy lies the immutable reality of US law. Because GitHub and Microsoft are US-domiciled companies, all data they hold is subject to FISA Section 702 and the CLOUD Act of 2018.

Despite the introduction of EU data residency for Enterprise Cloud, the legal jurisdiction follows corporate control, not physical geography. As a Microsoft attorney testified under oath to the French Senate in 2025, there is no guarantee that European data stored in European datacenters is safe from silent US government access. For sovereign entities like the Dutch government, this jurisdictional risk makes self-hosting not just a preference, but a legal necessity for digital autonomy.

Why Forgejo?

When seeking an alternative, the choice often comes down to GitLab versus Forgejo. While GitLab is a powerful industry standard, Forgejo offers a different philosophy of freedom:

• Licensing: Unlike GitLab's open-core model, Forgejo is fully open source (GPLv3+), resisting the commercial capture of its codebase.
• Governance: Forgejo is managed by Codeberg e.V., a non-profit registered in Berlin with a member-elected board and public budgets, providing a level of community governance that commercial entities cannot match.
• Lightweight Footprint: Forgejo is significantly less resource-intensive than GitLab, making it viable for home-lab deployments on hardware as simple as an Intel NUC.

Engineering a Defensible Self-Hosted Forge

Self-hosting the forge is the easy part; securing the CI/CD runner is where the real engineering challenge lies. Because runners execute lifecycle scripts (like npm install), they are prime targets for supply-chain attacks.

To mitigate this, a hardened runner architecture should employ a "defense in depth" strategy:

1. KVM Isolation: Run the runner in a dedicated Virtual Machine rather than a container to ensure the host kernel is not shared.
2. gVisor Runtime: Use runsc inside the VM to intercept system calls in user space, adding a layer between the job container and the VM kernel.
3. Destructive Rebuilds: Implement weekly destructive rebuilds of the VM from a fresh image to ensure persistent state cannot survive long-term.
4. Egress Filtering: Use nftables to block the runner from accessing the local network (LAN), preventing a compromised job from scanning internal infrastructure.
5. Scope-Bound Tokens: Use tokens limited to specific user or organization scopes rather than admin-scoped PATs.

The Cost of Migration

Moving away from GitHub is not without friction. The most significant losses are:

• The Social Graph: GitHub is the primary discovery engine for open source. To mitigate this, many migrate their canonical home to Forgejo while maintaining an archived GitHub mirror that points to the new location.
• Ecosystem Fragility: Forgejo Actions aim for familiarity, not 1:1 compatibility. Some GitHub-specific actions may require pinning to older versions or using Forgejo-hosted forks.
• Tooling Gaps: Features like Dependabot must be replaced with alternatives like Renovate, which requires additional configuration time.

Final Thoughts

As the industry moves toward "agentic" workflows and AI-driven development, the concentration of power in a few US-based platforms becomes a systemic risk. Whether it is a national government seeking legal sovereignty or an individual developer seeking control over their data, the move toward federated or self-hosted forges is a move toward a more resilient and decentralized future for software development.