Self-hosted Git in 2026 means choosing between a project and its hard fork: Forgejo split from Gitea in late 2022 when Gitea's trademark and repos moved into a for-profit company, and what began as a rename has become genuine divergence — different licenses, different release cadences, drifting databases. The good news: both remain excellent, absurdly light GitHub replacements. The choice is now about governance and trajectory more than features, and it is worth making deliberately because switching later is no longer free.
Where they actually differ in 2026
| Gitea | Forgejo | |
|---|---|---|
| Governance | Gitea Ltd (commercial) + community | Codeberg e.V. (non-profit), community-owned |
| License | MIT | GPL v3+ (since v9) |
| CI | Gitea Actions (GitHub-Actions-compatible) | Forgejo Actions (same ancestry, drifting) |
| Federation | not a priority | ActivityPub work ongoing (Codeberg driving) |
| Enterprise path | Gitea Enterprise, paid support | none — community support only |
| Interchangeable? | no longer — hard fork since 2024, migration needs version-path care | |
The case for each
Pick Gitea if you want MIT licensing, the option of paid support behind you, and the fastest lane for enterprise-flavored features (SAML, audit, scaling work funded by customers). It remains the pragmatic, boring-in-a-good-way choice for companies.
Pick Forgejo if the 2022 lesson matters to you: a code forge you self-host to escape platform risk should itself be immune to platform risk. Codeberg's non-profit ownership makes a rug-pull structurally impossible, GPL keeps improvements public, and the federation roadmap points at a future where forges talk to each other. The FOSS ecosystem has largely voted this way — Codeberg itself runs Forgejo for hundreds of thousands of repos.
Feature-checklist users will find daily life nearly identical in both: repositories with LFS, pull requests with reviews, issues, wikis, project boards, package registries (npm, container, PyPI and more), and mirror sync from GitHub.
Actions: the part that changed self-hosted Git
Both ship a CI system compatible with the GitHub Actions workflow syntax — most .github/workflows/*.yml files run with minor or no edits, and the runner is a separate binary you register like a GitHub self-hosted runner. Two practical notes: compatibility is high but not total (marketplace actions relying on GitHub APIs may need substitutes), and runners, not the forge, eat your hardware — a Node or Rust build swallows cores and RAM the 512 MB forge never needed.
Looking for a server that just works?
Valebyte VPS — NVMe, 24/7 support, deploy in 60 seconds.
Sizing: the forge is free, the runners are not
- Solo / small team, no CI: 1 vCPU / 1 GB VPS runs either forge with SQLite comfortably. Truly.
- Team + Postgres + light CI: 2 vCPU / 4 GB — forge plus one modest runner.
- Real CI load (builds on every PR): put runners on their own machine. This is where a cheap dedicated box shines: a 6-core Xeon-E 2136 / 32 GB ECC / NVMe at $59/mo hosts the forge and parallel runners — the same consolidation logic as our PaaS sizing guide.
- Disks: repos are small, LFS and container registries are not — put
data/on NVMe and watch registry retention.
Bottom line
You cannot pick badly here — both forges are mature, light and actively developed. Pick Forgejo when values and federation matter; pick Gitea when MIT and commercial backing matter. Just pick once: the fork has diverged far enough that hopping between them is a migration project, not a config change. Facts checked July 8, 2026.
