Why I'm Leaving GitHub for Forgejo

The problem: ownership and control

GitHub’s recent history reads like a checklist of red flags for anyone who cares about who ultimately decides what happens to their code.

• 257 incidents (48 major) between May 2025 – April 2026, with the CTO admitting the platform needs 30× more capacity to handle AI‑driven load.
• In August 2025 GitHub lost its CEO and was folded into Microsoft’s CoreAI division, the same group that builds Copilot.
• On 24 April 2026 the default for Copilot data collection switched to opt‑out, meaning every interaction on a public repo becomes training material unless each user manually disables it.
• Because GitHub (and its parent Microsoft) are US‑based, FISA Section 702 and the CLOUD Act apply regardless of where the data physically lives.

These points are not isolated glitches; they are symptoms of a platform that is no longer an independent service but a data‑harvesting component of a larger AI business.

The Dutch Ministry of the Interior reached the same conclusion. On 27 April 2026 it soft‑launched code.overheid.nl, a self‑hosted Forgejo instance that gives the government full legal control over its open‑source releases. The decision was driven by the same concerns: licensing freedom, governance transparency, and jurisdictional safety.

Funding and traction of Forgejo

Forgejo is a community‑run fork of Gitea, now governed by the non‑profit Codeberg e.V.. The project’s recent milestones illustrate growing momentum:

• v15.0 LTS released on 16 April 2026, marking the 100th release and guaranteeing support until 15 July 2027.
• The Forgejo Actions framework reached production‑ready maturity in v15, offering OpenID Connect, reusable workflows, and ephemeral runners.
• Over 300 000 repositories are hosted on the public Codeberg instance, showing real‑world scalability.
• Commercial managed services exist (e.g., Codey by VSHN, CHF 19 / month), proving a nascent ecosystem for enterprises that need vendor support.

While there is no Red Hat‑style support contract, the transparent governance and GPLv3+ licensing make the codebase impossible to close off, a key factor for public‑sector adoption.

My deployment: code.jorijn.com

Below is a concise diagram of the stack I run on a single Intel NUC (64 GB RAM) in my home office:

• Forgejo v15 LTS – core Git hosting.
• PostgreSQL 17 – reliable relational store.
• Traefik – reverse‑proxy handling TLS termination.
• Incus‑managed KVM VM – isolates the CI runner from the host kernel.
• Forgejo Actions runner – runs inside the VM using gVisor (runsc) as the Docker runtime.

Runner hardening layers (from softest to hardest)

1. Persistent KVM VM – a full virtual machine isolates the job’s kernel from the NUC’s host kernel.
2. gVisor – user‑space syscall interception adds a second barrier; a container escape must break both gVisor and the VM.
3. Weekly destructive rebuild – every Monday the VM is destroyed and recreated from a freshly baked Ubuntu image, ensuring no long‑lived state can be compromised.
4. nftables egress filter – the VM can only reach the public internet on ports 80/443, DNS, and SSH to my own Forgejo hostname; internal LAN ranges are blocked.
5. Scope‑bound runner tokens – tokens are limited to a single user or organization, never admin‑scoped, limiting the blast radius of a leaked credential.

These layers are not novel individually, but wiring them together for a single‑user homelab that fits on a NUC is where the work lies. The result is a perimeter with depth: a failure in one layer is caught by the next.

Why the move matters beyond outages

Outages are a symptom, not the root cause. The capacity crunch GitHub attributes to “agentic AI workflow growth” is a direct consequence of its integration with Microsoft’s AI stack. When the platform’s business model pivots toward data collection, reliability inevitably suffers because the system is being stretched to feed a different product (Copilot) rather than to serve developers.

The loss of independent leadership means product decisions are now filtered through Microsoft’s AI priorities. For developers who value a platform that can be steered by its own community, this is a deal‑breaker.

The training‑data default flip creates a legal exposure that cannot be mitigated on a per‑repository basis. Even private repos are not immune because Copilot records snippets generated during editing. Unless every contributor opts out, the code becomes part of Microsoft’s training corpus.

Finally, the jurisdictional risk is immutable: any data stored by a US‑incorporated service is subject to US surveillance powers. The Dutch government’s decision to own its forge sidesteps this risk entirely.

Comparing Forgejo to GitLab (the other popular self‑hosted option)

Criterion	Forgejo	GitLab CE
License	GPLv3+ (copyleft, no open‑core)	MIT for CE, many features behind Enterprise license
Governance	Non‑profit Codeberg e.V., elected board, transparent budget	Private company, commercial roadmap, dual‑licensing
Feature set	Core Git hosting, Actions, OIDC, basic CI	More polished UI, larger ecosystem, but many CI features require paid tiers
Commercial support	Thin (Codey, VSHN)	Mature (GitLab Enterprise)
Community size	300 k+ repos on Codeberg, growing	Millions of users, but with a commercial gate

The licensing and governance differences were the decisive factors for both the Dutch ministry and my own migration.

What I gave up

Area	Impact
Discoverability	GitHub’s social graph drives contributions. I mitigate this by archiving each public repo on GitHub and adding a README link to code.jorijn.com. The migration is gradual, not instantaneous.
GitHub‑specific Actions features	Some workflows needed tweaks (e.g., pinning actions/checkout to v5, using Forgejo‑specific forks for actions/upload-artifact). Most friction is manageable, but heavy reliance on GitHub‑only features would raise the migration cost.
Dependabot	Not available on Forgejo. I replaced it with Renovate, which runs on the same self‑hosted runner and offers comparable automation after a day of configuration.
Enterprise support	No 24/7 phone SLA. I rely on the open‑source issue tracker and community chat. For a solo operation this is acceptable; larger teams may need a managed provider or internal support staff.

When a self‑hosted Forgejo makes sense

• You need full legal ownership of the platform and the data it stores.
• Jurisdictional exposure to US law is unacceptable for your organization.
• You are comfortable (or can outsource) running a modest amount of infrastructure – a single NUC is enough for low‑to‑moderate traffic.
• Your CI pipelines can be expressed with the core Actions features; you can tolerate some friction when porting GitHub‑only steps.
• You are willing to accept a lighter support model or pay for a managed Forgejo service.

If any of those conditions are false—especially if you lack the capacity to maintain the runner isolation stack—staying on GitHub (or a managed GitLab) may be the pragmatic choice.

Key takeaways

1. GitHub is now a unit of Microsoft’s CoreAI division, not an independent service.
2. Outages, the Copilot data‑opt‑out, and US jurisdiction are all downstream effects of that structural shift.
3. The Dutch government’s adoption of Forgejo validates the move from fringe to mainstream for sovereign code hosting.
4. A production‑grade Forgejo deployment can live on a single NUC, provided you invest in a hardened runner stack (KVM + gVisor + weekly rebuild + nftables + scoped tokens).
5. Migration friction is real—you’ll need to rewrite some CI steps, replace Dependabot, and manage discoverability—but a phased archive‑and‑redirect strategy keeps the community link alive.

---

If you’re interested in the exact configuration files, the Docker Compose setup, and the Incus VM definition, they are available in the public repository linked from the article.