Origins and Philosophy

Origins and Philosophy

After this page you can say what problem a single-binary forge is built to solve, and which project solved it first.

Two forks, one shape

Gogs was a lightweight Git server in Go. Development sat behind one maintainer. In 2016 contributors forked it and called the result Gitea: the same idea, with a group that could review and release.

The idea is small on purpose.

one Go process
  ├── Git repositories as bare repos on disk
  ├── issues, pull requests, users  →  one database
  └── HTTP on port 3000, and SSH for the Git remote

Default database is SQLite, a file next to the repositories. Postgres and MySQL are configuration, not a requirement. There is no separate Rails app, no Gitaly, no search cluster. Chapter 23 named those boxes. This product leaves most of them empty until you opt in.

What you get on the first afternoon

A Gitea or Forgejo instance gives a small team:

• repositories, with SSH and HTTP remotes (chapter 11)
• issues and pull requests
• a web UI to browse files and diffs
• organizations, teams, and repository permissions
• webhooks, when you want an outside CI to notice a push (chapter 32)

Packages, Actions, and a container registry exist. They are extra processes and extra disks. The core stays the binary plus the data directory.

What this shape refuses to be

GitLab’s theory is one application for the whole lifecycle (chapter 24): Git, CI, registry, and security scanning in one product. Gitea’s theory is the opposite budget. A desk, a lab, or a small company can run it on a machine that would struggle to boot GitLab Omnibus.

That budget is the point. The moment the database, the Git files, and CI runners all need to scale independently, you have left the afternoon install and entered chapter 36. The binary does not stop you. It also does not hide the work.

The next page is why Forgejo exists as a second project with this same shape.