What is Forgejo? The community-owned Git forge, explained
A self-hosted GitHub alternative forked from Gitea in 2022, GPL-licensed and run under a non-profit, and lately the git server people give their AI agents. Origins, vs-Gitea, and setup shapes.
Forgejo is a self-hosted software forge (repositories, issues, pull requests, CI) that you run on your own server from a single binary or container. It forked from Gitea in October 2022 after Gitea’s trademarks moved to a for-profit company, became a fully independent hard fork in early 2024, and since v9.0 is GPL-licensed and developed under the umbrella of the non-profit Codeberg e.V. (Codeberg.org itself runs on it). Lightly resourced, quarterly releases, one LTS per year. And lately it has a second audience: people giving their AI agents a private git server to keep memory and state in.
Where Forgejo came from
The lineage is three generations of “GitHub, but yours”: Gogs begat Gitea (2016), and Gitea begat Forgejo. In October 2022 Gitea’s founder transferred the project’s domains and trademarks to the newly formed Gitea Ltd, in the community’s words “without knowledge or approval of the community.” After an open letter went unanswered, part of that community launched Forgejo (from forĝejo, Esperanto for “forge”) in December 2022. For its first year Forgejo tracked Gitea’s releases; in early 2024 it announced it was “no longer bound to Gitea, and can forge its own path going forward”: a hard fork, diverging since. The governance is the actual differentiator: Forgejo’s domains sit in the custody of Codeberg e.V., a democratic non-profit, while remaining independently governed. There is no company that can take this one home.
Forgejo vs Gitea, practically
- License: Forgejo moved to GPL v3+ with v9.0 (August 2024); Gitea remains MIT. Copyleft here means improvements to the forge itself must stay open.
- Migration has a ceiling: Forgejo documents upgrading from Gitea only up to Gitea 1.22, and via a stepping-stone (Gitea → Forgejo v10.0.x → current). A current Gitea database does not drop into a current Forgejo. If you’re switching, sooner is simpler.
- Feature-for-feature, they remain siblings: both are lightweight single-binary forges with Actions-style CI. Forgejo declines to publish a comparison table (“both… are developed at a pace that would make such a comparison very hard to maintain”), which is about right.
- Releases: quarterly, with one LTS per year (as of August 2026: v16.0 stable, v15.0 LTS supported into mid-2027).
Running it
Deployment is the classic small-forge shape: a single binary per platform or an official container image, SQLite for small installs, and a resource footprint the project describes as “an order of magnitude less” than the big forges. Upstream Gitea’s docs put the class of hardware at “2 CPU cores and 1GB RAM” for small teams, and Forgejo plays in the same league. CI comes from Forgejo Actions (workflows in .forgejo/workflows, GitHub-Actions-like but not identical; jobs execute on a separate Forgejo Runner), and everything is drivable over a REST API under /api/v1.
The agent angle: a private forge as your agents’ memory layer
The reason Forgejo keeps appearing in agent-stack discussions is that practitioners run a private, self-hosted forge as the place their AI agents commit what they learn: memory files, rules, state, one repo per agent or one shared “brain,” with bigger changes going through pull requests. Every change is versioned, reviewable, and reversible, which is precisely what you want for files that shape an autonomous agent’s behavior. And for data that personal, plenty of operators prefer a box they control over a cloud account. It’s the same instinct behind treating agent memory as files under version control. OpenClaw, for instance, auto-initializes its workspace as a git repo and its docs recommend pushing it to a private remote. A Forgejo instance on a small VPS, or tucked inside a tailnet, is that private remote with a UI, an API your agents can use, and no third party in the loop. (The all-in-one take on the same instinct is Block’s Buzz, which fuses chat, git, and agent identity into one self-hosted workspace: younger software, same own-the-server conviction.) Give each agent a scoped account or deploy-key-style access rather than an admin token, and the agents’ shared brain stays both durable and accountable.