Why Forgejo, Not Gitea, Is 2026's Default Self-Hosted Git Pick

In October 2022, the Gitea project's domain and trademark were quietly transferred to a newly formed for-profit company, without a community vote. No feature shipped, no bug got fixed — ownership just moved. Four years later, most 2026 self-hosted-git comparison guides give the same answer to "which one should I run": not Gitea, the project that transfer happened to, but Forgejo, the fork the community built in response.

That's the deliverable up front, because it's easy to bury under nostalgia for the fork drama: for a team standing up self-hosted git today with no existing Gitea investment, Forgejo is the safer default — non-profit governance, a copyleft license that survives a future ownership change, monthly security patches, and its own Actions CI runner that's now arguably ahead of Gitea's. Gitea still wins for teams that specifically want its Enterprise tier (SAML, audit logs) or are already deep in its ecosystem. What follows is the timeline that produced that recommendation, the parts of it that are still genuinely close, and what the whole split means for a platform whose entire pitch is "push a git repo, get a running service" when which git host that repo lives on is now, in fact, a decision.

The Governance Crisis That Started It​

Gitea launched in 2016 as a lightweight, self-hostable GitHub clone written in Go — small enough to run comfortably on a Raspberry Pi, with none of GitLab's operational weight. It built a loyal self-hosting following for exactly that reason. Then, in October 2022, its domain and trademark were transferred to Gitea Ltd, a newly incorporated for-profit company, without the community being consulted first.

The community's response was fast and specific. On October 25, 2022, a group of maintainers and contributors published an open letter asking the project to instead form a non-profit to hold the domain and trademark on the community's behalf. When that request went nowhere, the same group announced on December 15, 2022 that they'd fork the codebase and place it under Codeberg e.V., a Berlin-based non-profit that already ran a large Gitea-based community git host. That fork became Forgejo.

For its first two years, Forgejo was a soft fork — it tracked Gitea's upstream commits and stayed close to line-for-line compatible, more a governance wrapper than a divergent codebase. That changed in 2024.

The 2024 Hard Fork, and the License Split That Made It Permanent​

Two things happened in 2024 that turned Forgejo from "Gitea with different governance" into a genuinely separate project.

First, Forgejo stopped synchronizing against Gitea's upstream commits and became a hard fork — free to diverge, not obligated to track. Second, and more consequential: in August 2024, Forgejo changed its license from MIT (which it had inherited from Gitea) to GPL-3.0-or-later. Versions up to v8.0 stayed MIT; v9.0 and everything after is GPL.

The reasoning was explicit, not incidental. MIT permits a company to take a project, fork it privately, and ship a closed derivative — which is structurally close to what the community felt happened in October 2022. GPL's copyleft terms mean any distributed modification to Forgejo has to stay open. Gitea remains MIT-licensed today, which means a for-profit company can still build closed extensions on top of it (which is exactly what Gitea Ltd's Enterprise tier is). The license isn't a technical detail here — it's the fork's answer to the event that caused it.

What Each Project Actually Ships in 2026​

The two codebases are still close enough that most feature-by-feature comparisons come out near-even. The interface is nearly identical, and container images are largely interchangeable for anyone running either at small scale. Where they've diverged:

The memory row is there deliberately: at the resource level, this is a wash. Neither project asks for more than a small VPS can give it, and the standard self-hosting anecdote — Gitea or Forgejo running comfortably on a 1 vCPU / 1 GB Raspberry Pi for a small team — holds for both. The decision isn't a performance decision. It's a governance and roadmap decision.

Forgejo Actions has had a genuinely active few months: the April 2026 v15.0 release added the ability to expand reusable workflows (previously a single job could only report one "Set up job" log line no matter how many jobs the reused workflow actually ran), simpler runner registration, ephemeral runners for autoscaled CI, and OpenID Connect support for reaching third-party systems securely from a job. Gitea ships its own Actions runner too, using GitHub Actions-compatible YAML syntax — for a team whose priority is "closest thing to GitHub Actions without leaving self-hosted," that's still a reasonable pull toward Gitea.

Who's Actually Running Which​

Recommendations from blog posts are cheap; adoption is a better signal. Codeberg itself — the non-profit whose e.V. entity Forgejo development is organized under — migrated its own public instance from Gitea to Forgejo in April 2023 and now hosts more than 300,000 repositories on it as of November 2025, making it the largest known Forgejo deployment. The Fedora Linux project is separately replacing Pagure, its long-running forge, with Forgejo. Neither is a small or casual user picking a tool for a weekend project; both are organizations with existing infrastructure investment choosing to move toward Forgejo rather than stay put or move toward Gitea.

That's the adoption evidence behind "Forgejo is the 2026 default," and it's worth being precise about what it does and doesn't prove: it shows large, technically sophisticated non-profits and open-source projects picking Forgejo when they migrate. It doesn't mean Gitea's installed base is shrinking — plenty of self-hosters who set up Gitea years ago have no reason to move, and Gitea Ltd continues shipping releases and courting Enterprise customers on a separate track.

Migration Is Compatible Today, Less So the Longer You Wait​

If you're not choosing fresh — if you already run Gitea — the migration path is real but has a shelf life. Through the 1.x line, Forgejo reads Gitea's app.ini configuration and database schema directly; migrating is close to a binary swap, and issues, pull requests, and webhooks carry over unchanged. That compatibility is why so many comparison guides describe Forgejo as a "drop-in replacement" for Gitea.

It's not indefinite. The two projects' schemas have started to diverge as Forgejo ships features Gitea doesn't track (and vice versa), and later release lines require a one-way migration rather than a direct swap. The practical implication: if you're on Gitea today and expect to eventually move, the cost of migrating grows the longer you wait, because you're migrating across a growing schema gap instead of a near-identical one. There's no forcing function today — Gitea instances aren't breaking — but "migrate now while it's still closest to free" is a genuinely different calculus than "migrate whenever."

What This Means for a Git-Push PaaS​

None of this changes what a deploy platform actually needs from whatever sits underneath it: a webhook fired on push, and an API to read commit SHAs, branches, and repo metadata. Both Forgejo and Gitea speak nearly the same webhook payload shapes and REST API — a platform's webhook receiver doesn't need separate code paths for one versus the other, and neither does a CI runner reacting to that webhook. That's the sense in which "which fork" is a genuinely lower-stakes choice than picking the deploy platform itself: get the webhook contract right once, and it holds for either backend.

That's also exactly the layer bex sits on top of. Bex is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API and AI agents as first-class operators — and its own roadmap includes a webhook-driven activator that turns a push to your git host into a deploy, the same "wake on push" loop Render and Heroku run against GitHub. For a team that doesn't want that git host to be GitHub at all, the choice of what runs underneath is now genuinely a governance question first and a feature question a distant second — and on governance, in 2026, Forgejo is the default answer.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources​

• Forgejo: Comparison with Gitea
• Codeberg launches Forgejo
• Forgejo makes a full break from Gitea — LWN.net
• Forgejo changes license to GPLv3+ — LWN.net
• Forgejo v15.0 is available
• Forgejo monthly report — May 2026
• Gitea vs Forgejo 2026: What's the Difference and Which to Self-Host? — Contabo
• Self-Hosted Git in 2026: Forgejo vs Gitea vs GitLab CE Compared — TechVerdict
• fedora/forgejo — Fedora project fork of Forgejo