Forgejo vs Gitea 2026: Which Self-Hosted Git to Pick

If you’re standing up a self-hosted Git server in 2026, the two names you’ll weigh are Forgejo and Gitea — and they’re no longer the same thing wearing different logos. Forgejo began as a friendly fork of Gitea, became a hard fork in early 2024, and has been diverging ever since. So the real question isn’t “which logo do I like,” it’s “which project do I want to run for the next five years.” Here’s how they actually compare in 2026 on the things that decide it — governance, licensing, federation, and migration — verified against each project’s own documentation.

The two at a glance

Both are lightweight, single-binary Git forges that run happily on a mini PC or a small VM, both do issues/PRs/wiki/releases/CI, and both are far lighter than GitLab. The differences below are about who controls the project and where it’s going, not about whether it can host your repos — either one can.

Why Forgejo exists: the governance split

This is the part that started everything. In 2022, the Gitea project’s domain name and trademark were transferred to a newly-formed for-profit company (Gitea Ltd) — by the community’s account, without prior knowledge or approval. A group of maintainers and contributors who wanted the project to stay community-governed responded by creating Forgejo in December 2022, hosted under Codeberg e.V., a registered German non-profit. Forgejo’s stated priority is “the interest of the general public”; its criticism of Gitea is that a for-profit owner makes decisions “to maximize profit rather than favor the interest of the general public.”

In 2026, Forgejo governance is a formal, documented structure — community elections, transparent roadmap, public decision-making. Gitea, by contrast, runs an “Open Core” model: the core is MIT-licensed, but the company also develops non-free components and (per Forgejo’s comparison) requires copyright assignment even for MIT-licensed contributions. Neither model is inherently wrong — a company-backed project can ship features and support that a volunteer non-profit can’t always match — but they pull in different directions, which is exactly why the fork became a hard fork.

Licensing: MIT vs GPLv3+ (and why it probably doesn’t affect you)

Gitea is MIT-licensed — maximally permissive, meaning anyone (including a company) can take the code, modify it, and ship it in a closed product. Forgejo was MIT too, up to and including its v8 series. Starting with its v9.0 release (2024), Forgejo relicensed to GPLv3-or-later — a copyleft license. Every version up to and including the v8 series was MIT.

The stated reason: to keep Forgejo’s code from being pulled back into a commercially-controlled Gitea. So the license divergence is really the governance dispute expressed in legal terms.

For a homelab user, this is invisible. GPLv3 only creates obligations when you distribute a modified version of the software — running Forgejo for yourself, your family, or your team triggers none of them. The license matters if you’re a business planning to build and sell a closed product on top of the code (MIT lets you; GPLv3 doesn’t), or if you have a philosophical preference for copyleft over permissive. Otherwise, both are genuinely Free/Open-Source and you can ignore this section.

Where they actually differ now

Since the hard fork, the codebases have drifted. The concrete, verifiable differences in 2026:

• Forge federation (Forgejo’s flagship bet). Forgejo is actively implementing ActivityPub-based forge federation — the ability for issues, pull requests, and stars to work across independent instances, the way Mastodon federates social posts. Progress is public with monthly reports. Gitea has no federation effort. If a “self-hosted but not isolated” future appeals to you, this is Forgejo’s single biggest differentiator.
• CI/CD. Both ship a GitHub-Actions-compatible runner — Forgejo Actions and Gitea Actions — so your .github/.forgejo workflows and existing actions largely just run. Forgejo notably develops and releases itself using Forgejo Actions (dogfooding); Gitea develops on GitHub.
• Testing and accessibility. Per Forgejo’s own comparison, Forgejo maintains end-to-end tests, upgrade tests, and browser tests that include accessibility checks; Gitea, as of mid-2025, did not have end-to-end or upgrade tests and only an example browser test. For an app you’ll upgrade for years, upgrade-test coverage is a quiet but real reliability signal.
• Development stack. Forgejo is developed on Codeberg (itself Forgejo) with localization via Weblate; Gitea is developed on GitHub with localization via Crowdin. A values signal more than a feature, but it’s real.

What has not meaningfully diverged: the core self-hosting experience. Repo hosting, the web UI, issues, PRs, wiki, packages, and releases are still very similar, because they share the same origin. This is why the choice is about trajectory, not day-one features.

Compatibility and migration — the practical part

Here’s the reassuring news for anyone already on Gitea: Forgejo is still designed to be a drop-in replacement. The projects remain compatible at the database and API level, and Forgejo publishes an official Gitea-migration guide. The supported path is:

Upgrades to Forgejo are transparently supported up to Gitea v1.22 included, in two steps: (1) upgrade from any Gitea version up to and including v1.22.x to Forgejo v10.0.x, then (2) upgrade from Forgejo v10.0.x to any later Forgejo version.

In practice that means: back up your Gitea database and data directory, run Forgejo v10.0.x pointed at the same data, then upgrade Forgejo the rest of the way to the current release — no re-cloning repositories, no re-creating users. Forgejo v10 is only the doorway, not the destination; the current stable line is v16.x.

The ceiling is the catch, and it has gotten sharper. Forgejo’s supported path still caps at Gitea v1.22, but Gitea has kept shipping — it is on the v1.27.x line as of August 2026. If your Gitea is newer than v1.22, you are past the transparent path, and you cannot get back to it by upgrading Gitea further. Nor can you simply drop back down: Gitea’s own upgrade guide warns that once a newer release has migrated your database, it “can not be used for an old Gitea” — downgrading across a minor version means restoring a pre-upgrade backup, not just running the older binary. Practically, if you did not keep a backup from before you left v1.22, that door is shut. Your options in that case are to stay on Gitea, or to move repositories, issues and users across with Forgejo’s API-based repository migration instead of a drop-in data-directory swap — a real migration with real gaps, not a binary swap. Check your Gitea version before you plan the move, not after.

The honest caveat: this is effectively a one-way door now. Because Forgejo has diverged (and relicensed) since the hard fork, there’s no supported route to migrate a modern Forgejo instance back to Gitea. That’s not a reason to avoid the move — it’s a reason to make the decision deliberately and keep a backup of your pre-migration state. If you’re running Gitea as part of a Docker Compose homelab stack, the swap is mostly a change of image and a data backup.

Which should you run?

• New homelab or small-team forge, no existing instance → Forgejo. You get the same lightweight experience plus non-profit governance, copyleft licensing, upgrade/accessibility testing, and the federation roadmap. It’s the lower-risk long-term bet for a project you don’t want a company to be able to close.
• You specifically need Gitea’s commercial “Enterprise” features, or you’re building a product on top and want the permissive MIT license → Gitea.
• You already run a stable Gitea and nothing hurts → there’s no urgency. Gitea is still open and maintained. Migrate when you next do a major upgrade, or when a Forgejo feature (federation, an Actions improvement) actually pulls you.

Self-hosted Git is one of the highest-value things you can pull off SaaS — it’s a core piece of the self-hosted stack that replaces rented tools, and it runs fine in a container next to everything else. Whichever you pick, you’re keeping your code on infrastructure you control, and deciding whether to run it in a container or a VM is the next call.

The honest verdict

In 2026 this is a good-vs-good decision, not a rescue. Both Forgejo and Gitea are excellent, lightweight, genuinely open self-hosted Git forges, and either will serve a homelab well. The tiebreakers are about governance and direction: Forgejo is the pick if you want a community-controlled, non-profit-governed project with copyleft protection and a federated future, and it’s my default recommendation for anyone starting fresh. Gitea remains the right call if you need its commercial features or the permissive MIT license, or if you’re simply happy where you are.

One thing I won’t fake: resource footprint. Because Forgejo and Gitea share a common Go codebase, their memory and CPU use are effectively identical — both idle in the low hundreds of megabytes and scale with your repo count and CI usage, not with the logo. Anyone quoting a dramatic footprint gap between the two is guessing; run whichever you choose and watch it on your own box.

Sources

• Forgejo — official comparison with Gitea (governance, license, federation, testing): https://forgejo.org/compare-to-gitea/
• Forgejo — upgrade guide, current (“Upgrades to Forgejo are transparently supported up to Gitea v1.22 included, in two steps”): https://forgejo.org/docs/latest/admin/upgrade/
• Forgejo — Gitea migration guide, v10.0 docs (the version-pinned page for the first step): https://forgejo.org/docs/v10.0/admin/gitea-migration/
• Gitea — upgrade guide (“Database already got upgraded and can not be used for an old Gitea, use a backup to downgrade”): https://docs.gitea.com/installation/upgrade-from-gitea
• Forgejo releases (current stable line, v16.x): https://codeberg.org/forgejo/forgejo/releases · Gitea releases (v1.27.x): https://github.com/go-gitea/gitea/releases
• Forgejo relicenses to GPLv3+ (v9.0; rationale): LWN.net · https://forgejo.org/2024-02-forking-forward/
• Forgejo becomes a hard fork of Gitea (governance record): https://codeberg.org/forgejo/governance/issues/58
• Forgejo — Wikipedia (origin December 2022, Codeberg e.V.): https://en.wikipedia.org/wiki/Forgejo