Gitea vs Forgejo, which self-hosted Git server to pick

Gitea vs Forgejo comes down to one question: who do you want steering your Git server in five years? The two forge apps still feel like twins for daily work. But the easy one-command switch between them has closed. Forgejo v10.0 was the last release able to read a Gitea database directly, and only up to Gitea 1.22.

What is the difference between Gitea and Forgejo?

Both tools share one ancestor and one daily interface, but they split over who owns the project, and that split is now legal and technical as much as political. Forgejo began as a fork of Gitea in late 2022, after Gitea’s trademarks and operations moved to a for-profit company without community agreement.

For about a year, the fork was soft. Forgejo tracked Gitea line for line and worked as a drop-in replacement. Then, in early 2024, it became a hard fork and dropped the promise to stay compatible.

Today the two still look like siblings. Repositories, issues, pull requests, wikis, packages, webhooks, the web UI, and a GitHub Actions-style CI runner behave the same on both. What differs now is the license, the governance, the release calendar, the database schema, and the roadmap.

Who controls each project

Gitea’s trademarks and commercial operation sit with Gitea Ltd, a for-profit company. Lunny Xiao is the lead maintainer and the company’s founder.

Forgejo’s domains and trademarks are held by Codeberg e.V., a nonprofit association registered in Germany. Its decisions run through public issues and RFCs in an open governance repository . Forgejo also publishes how it takes in and spends money. Gitea does not publish an equivalent ledger.

One practical difference sits underneath the license question. Gitea asks contributors to sign over copyright on their code. Forgejo does not, which is what lets it hold the line on the GPL later.

The two projects even build in different places. By Forgejo’s own account, it develops on its own Forgejo instance with Forgejo Actions, while Gitea develops on GitHub with GitHub Actions (Forgejo’s comparison page ). That is Forgejo’s framing, not a neutral fact, but the security practice is easy to confirm: Forgejo announces every vulnerability publicly, while Gitea gives paying customers advance notice.

When the split was fresh, one observer at LWN.net wondered how it would age.

More than two years on, the answer is clear enough. Forgejo runs the largest community forge in Europe, ships on a steady calendar, and has kept its independence. It has not, however, pulled a wave of developers off GitHub.

Licenses, paid tiers, and where the money comes from

The license split is the same governance argument written in legal language, and it changes what a company can legally do with the code. Gitea is MIT throughout. Forgejo used MIT up to v8.0, then moved to GPL v3 or later from v9.0 onward (Forgejo FAQ ).

MIT lets anyone ship a closed product built on the code. GPL forces changes back out into the open.

That legal line explains the business models. Gitea Ltd sells Gitea Enterprise, which adds SAML single sign-on, audit logs, autoscaling Kubernetes runners, and an SLA. It runs about $9.50 per user per month on an annual plan, and a hosted Gitea Cloud tier sits alongside it (Gitea pricing ). That is an open-core model: the free core is MIT, and the enterprise add-ons are proprietary.

Forgejo has no paid edition at all. It runs on donations and grants, including NLnet funding for its federation work. The consequence for a buyer: if you need single sign-on and audit logs with a contract behind them, only one of these two will sell you that.

Feature divergence between Gitea and Forgejo

Two and a half years after the split, the feature lists have drifted. Gitea has been shipping CI and registry features faster. Forgejo, now on its v15 release line , has spent its budget on federation, testing, and accessibility instead.

Forgejo is the only one building forge federation, using ActivityPub and the ForgeFed vocabulary. Federated repository stars work today. Federated issues and pull requests are still in progress. Gitea has no federation work at all.

Gitea, meanwhile, has poured effort into automation. Its recent releases added Actions concurrency groups, re-running failed jobs, per-runner pause, a Terraform state registry, instance-wide maintenance mode, automatic release notes, and a rebuilt frontend (Gitea 1.26 release notes ).

The two also ship on different rhythms. Forgejo publishes a stable release roughly every quarter with three months of support, plus one long-term release each year supported for 15 months (Forgejo upgrade docs ). Gitea ships larger, less frequent minor versions with no formal long-term track.

For CI itself, the gap barely shows. Both run GitHub Actions-style workflows with their own runner, so most workflow YAML moves between them unchanged. Third-party actions still mostly come from GitHub either way.

Can you still migrate from Gitea to Forgejo?

Not as a drop-in, unless your Gitea is very old. Most comparison articles get this wrong.

Forgejo v10.0 was the last release able to read a Gitea database directly, and only from Gitea v1.22 or lower. Gitea v1.23 shipped in late 2024, and Gitea now sits at 1.26.x. So a normally maintained Gitea instance is already past that cutoff.

If you are on Gitea 1.22 or older, you get two clean hops. First move Gitea 1.22 to Forgejo v10.0.x, then bring that Forgejo up to the current release.

If you are on Gitea 1.23 or newer, there is no supported path, only three workarounds:

• Downgrade the database schema first with a community script such as xlrl/prepare-gitea-migration-to-forgejo , which supports Gitea up to v1.25.2, then take the supported hops above.
• Stand up a fresh Forgejo and pull every repository, issue, and pull request across through the API. You accept rewritten timestamps and lost internal IDs.
• Stay on Gitea. A working forge is worth more than a governance preference.

Going the other way is worse. There is no supported route from a modern Forgejo back to Gitea, and none is planned. Migration is now a one-way door in both directions.

Whichever path you take, back up the full database and data directory before you touch anything, and rehearse the whole run on a copy first. For moving repositories from GitHub into either forge, the process is untouched by all of this, and I walk through it in the batch GitHub to Gitea migration guide .

What I run on my own server and why

I run Gitea, not Forgejo. It sits behind Docker with a self-hosted Gitea Actions runner, I drive it from the terminal with the tea CLI, and this blog’s own issue tracker lives inside it.

The pull toward Forgejo is strong. Governance would be my reason to move; no feature is pushing me. I would rather my forge answer to a nonprofit than to a company that can change its mind.

One thing to flag from running Gitea Actions day to day: it speaks the GitHub Actions workflow syntax, but the third-party actions you call still live on GitHub. Most work fine. A few assume they can reach the github.com API for tokens or releases, and those need a tweak or a local replacement. If you want the full setup, I cover it in the self-hosted CI/CD with Gitea Actions guide and the broader self-hosting Gitea walkthrough .

Which one should you pick

If you are starting fresh with no existing instance, pick Forgejo. The governance is the whole reason the fork exists, the GPL protects it, and starting there costs you nothing.

If you already run Gitea 1.23 or newer and you are happy with it, stay. The migration cost is high, and the everyday feature gap is small.

If you run a company that needs single sign-on, audit logs, and a support contract, choose Gitea, because Gitea Ltd will sell you one and nobody sells a Forgejo SLA.

One rule overrides all three. The switch gets harder with every release, so if you plan to move at all, move now rather than next year. Both projects are excellent, so pick the owner you trust to hold the trademarks in five years.