When Gitea or Forgejo Fits

Updated

October 30, 2026

When Gitea or Forgejo Fits

After this page you can decide whether this shape is the forge for the job in front of you.

Choose it when

The requirement is Git hosting for a desk, a course, or a company that can name every user. You want issues and pull requests, you can live with CI as a webhook or a separate runner, and you would rather administer one data directory than a platform of services.

Forgejo is the default in this book for that job:

  • the steward is a non-profit, and the license from v9 on is GPL-3.0-or-later
  • 15.0 is a long-term line (security support through 15 July 2027)
  • Codeberg is the same software, operated by someone else, when you do not want a server (chapter 29)

Gitea is the right lightweight forge when MIT is the constraint, or when a support contract with Gitea Ltd is the constraint. The operator experience is the sibling of Forgejo, not a different architecture.

Run it yourself when the repositories must stay on a machine you control. Use Codeberg when the code can live on a public community forge and you only need an account.

Choose something else when

  • You need merge trains, a built-in registry, dependency scanning, and GitLab CI on day one. That is chapter 24, and it is a larger machine.
  • Review must be a stack of patchsets with a Change-Id. That is Gerrit (chapter 27), not a pull-request UI with a different coat of paint.
  • The company standard is already GitHub or GitLab.com and the lock-in discussion in chapter 22 has been accepted. A second forge “for practice” is this lab. A second forge “for production beside the real one” is two metadata stores and one confused team.
  • You expect two nodes to share one SQLite file and call it high availability. Stop at the previous page and read chapter 37 before you draw that diagram.

A decision you can write down

small team, self-hosted, free-software forge  →  Forgejo 15 LTS
small team, MIT or a Gitea contract           →  Gitea 1.27
hosted community, no server to patch          →  Codeberg
CI and registry inside the installer          →  GitLab

Whichever line you pick, the developer workflow does not restart. desk-api is still a repository, the remote is still a URL, and force-push rules from chapter 11 still apply on main. Part V is what changes when you are the operator of that URL for other people: identity, branch protection, and backups. The binary will not do those for you.