Gitea vs Forgejo

Open one and then the other and you would struggle to tell them apart: the same repository view, the same pull requests and issues, the same lightweight Git server that boots from a single binary. That is not a coincidence — one is a hard fork of the other, and day to day they remain near-twins. So the decision is not about features or speed; it is about which stewardship model you want to trust with the place your code lives — and, since the two projects stopped sharing a licence and a migration path, it is a decision you should expect to live with.

The same application, forked

Both are Go applications that ship as a single self-contained binary (plus an official Docker image), and both give you repos, pull requests, issues, a package registry, and a built-in CI runner. They no longer share a licence: Gitea is MIT, while Forgejo moved to GPL-3.0-or-later at v9.0 in October 2024, so a copyleft obligation now attaches to modified Forgejo code you distribute. For simply running either server in-house, neither licence asks anything of you. Forgejo began as a hard fork of Gitea after Gitea's project and trademark moved under a company structure. A group of contributors who wanted the project to stay in community hands took the codebase and continued it independently under the umbrella of the Codeberg nonprofit. Because it started from the same source, everything you know about running one transfers directly to the other.

For a while Forgejo tracked Gitea closely, essentially a governance-driven mirror with patches on top. That window has closed. Forgejo now states that Gitea v1.22 is the last version with a transparent upgrade path, taken via Forgejo v10.0.x as an intermediate step; from Gitea v1.23 onward there is no supported migration, only manual database surgery on a best-effort basis. Gitea is at v1.27 as we write this. There has never been a supported route in the other direction. Day to day the two still feel like the same application — but the decision is now harder to reverse than it looks.

The difference that actually matters: governance — and now licence

Governance is why the fork exists, and it is still the reason most people pick one over the other — but it is no longer the only split. The licences have diverged, and so has the migration path.

• Gitea is backed by a company. That brings resources, a long track record as the original project, and the larger surrounding ecosystem of guides, integrations, and third-party tooling built up over years.
• Forgejo is stewarded by the Codeberg e.V. nonprofit and run as a community-first project. Its promise is that no single commercial entity controls the software or its trademark — decisions are made in the open by the people who maintain and use it.

If you have no strong feelings about who holds the reins, Gitea's maturity and ecosystem are genuine advantages. If independent, community-owned governance is something you actively want to support — the same instinct that leads people to Codeberg over a commercial forge — Forgejo is the project built around exactly that principle, and that is our pick.

Features and compatibility

Feature-wise this is close to a tie, and honestly so. You get the same core on either side:

• Repositories and collaboration — pull requests, issues, code review, branch protection, and wikis, essentially identical between the two.
• Automation — a bundled Actions-style CI runner with a workflow syntax close enough to GitHub's that many pipelines port with minor edits.
• Package registry — container and language package hosting built in.
• Federation — Forgejo has invested in ActivityPub-based federation as a longer-term differentiator, fitting its community ethos; treat it as evolving rather than a finished headline feature.

Because the data model is shared, the two remain easy to learn in either direction. Moving data between them is the part that is no longer realistic — see the compatibility cut-off above — so pick with the expectation of staying.

Resources and performance

There is nothing to separate them here, and the table reflects it: both are frugal Go services with a 512 MB floor and the same easy 2/5 difficulty to stand up. A single small server runs either without strain, SQLite keeps the simplest setup to one container, and you can move up to Postgres or MySQL when a team grows. Whichever you choose, expect the same light footprint — this is not a resource decision.

Which should you self-host?

Pick Gitea if…

• You want the original project with the longest track record and the largest surrounding ecosystem of guides and integrations.
• Company backing reads as stability and resources to you, not a red flag.
• You would rather follow the most well-trodden path, with the most existing answers when you hit a question.

Pick Forgejo if…

• Independent, community-first governance under a nonprofit is something you actively want to back with your choice of tooling.
• You like where the community roadmap is heading — including its bet on federation — and want to grow with it.
• You want a GitHub-shaped forge with a stewardship model that cannot be quietly steered by a single commercial owner, and copyleft suits you.
• You are starting fresh, or migrating from Gitea v1.22 or older — past that version the supported upgrade path is gone.

Running either on a VPS

Both run comfortably on the smallest servers worth renting — same Go binary, same 512 MB floor, same one-container start with SQLite — so there is no performance penalty for choosing on principle. Point either at a data volume, front it with HTTPS, and add a Postgres or MySQL database only when a team outgrows SQLite. The step-by-step setups are linked below, and any of the VPS options here has plenty of room for the app plus its database. What you cannot count on any more is starting on one and moving to the other later: Forgejo supports upgrades only from Gitea v1.22 and earlier, and Gitea does not accept Forgejo instances at all. Choose on governance and licence up front.