Forgejo review: the community-governed Git forge born from Gitea's corporate split

Why Forgejo exists: the Gitea governance split

In October 2022, Gitea's lead maintainer Lunny Xiao quietly transferred the project's trademarks and domains to Gitea Limited, a newly incorporated for-profit company, without prior consultation with the broader contributor community. An open letter signed by 48 community contributors demanded that control be returned to a non-profit, the company be renamed to avoid confusion, and community governance be restored. When Gitea Ltd declined those requests in a blog post days later, contributors forked the project as Forgejo under Codeberg e.V., a German registered non-profit.

Forgejo initially tracked Gitea closely as a soft fork, but in early 2024 it became a hard fork—its codebase now diverges freely rather than mirroring Gitea line-by-line. The split reflects a fundamental disagreement over control: Gitea Ltd can offer commercial services and make decisions driven by revenue, while Forgejo's governance is transparent, decisions are made in public, and development priorities are set by community vote rather than a sales roadmap. Codeberg itself migrated from Gitea to Forgejo in April 2023 and now battle-tests every release at scale.

For self-hosters choosing in 2026, the governance question is the real differentiator. Both projects ship comparable features, but Forgejo's non-profit stewardship, copyleft GPL license since version 9.0, and exclusively FOSS development toolchain position it as the safer long-term bet for teams concerned about vendor lock-in or open-core drift.

Core features and what you actually get

Forgejo ships as a single Go binary with the Vue.js frontend compiled in, requiring no separate Node process. Out of the box it provides Git repository hosting with pull requests, inline code review, issue tracking with labels and milestones, kanban boards, wikis, a package registry supporting Docker, npm, PyPI, Maven, and other formats, and Forgejo Actions—a GitHub Actions-compatible CI/CD system. SQLite is the default database for small deployments, but PostgreSQL, MySQL, and MariaDB are supported for larger installations.

Forgejo Actions deserves specific attention because it eliminates the need for external CI tools. Workflows use GitHub Actions YAML syntax, so migrations from GitHub are often a matter of copying workflow files with minimal edits. Runners can be ephemeral for security—they register, execute a single job, then delete their credentials to minimize risk in autoscaling environments. Repository-specific access tokens were added in version 15.0, allowing finer-grained API security. OpenID Connect support in the same release enables secure federated authentication to third-party systems without static tokens.

The experimental federation work via ActivityPub is Forgejo's most ambitious long-term feature. The goal is to let users on different Forgejo instances follow repositories, star projects, and collaborate across forges without creating accounts on every instance—a Mastodon-like model for code hosting. As of mid-2026 the ability to federate stars has shipped, but the feature remains opt-in and not recommended for production use. For teams evaluating Forgejo today, federation is a signal of direction rather than a reason to deploy.

Installation and resource requirements

Forgejo runs on remarkably modest hardware. The documented minimum is 512 MB of RAM and a single CPU core, though 1 to 2 GB is recommended for small teams and 4 GB for deployments with many concurrent users or heavy CI workloads. Storage needs scale with repository count and LFS object size; 10 GB is a reasonable starting point. Because Forgejo is a single binary with SQLite as the default database, installations on Raspberry Pi, low-end VPS instances, and NAS devices are common and well-documented.

Installation options include a binary download with manual systemd service setup, Docker Compose for containerized deployments, or native packages for distributions like Debian, Fedora, Arch, and NixOS. The initial configuration screen prompts for database choice, admin account creation, SSH and HTTP ports, and email settings. First-time setup takes 15 to 30 minutes for someone comfortable with the command line. Upgrades are typically a matter of swapping the binary or container image, with automatic database migrations on first boot, though the official guidance emphasizes testing on a staging copy before touching production.

The Forgejo Runner—the separate daemon that executes Actions workflows—needs to be installed on one or more machines and registered with the main instance. Runners can use Docker, Podman, or LXC containers for isolation. For security-conscious deployments, runners should not share the same host as the main Forgejo instance, though homelab and single-machine setups often ignore this advice for convenience.

Migration paths and lock-in considerations

Moving from Gitea to Forgejo is straightforward because Forgejo began as a Gitea fork. The migration is treated as an in-place upgrade: stop Gitea, back up the database and repository storage, swap the binary or container image for the Forgejo equivalent, then start the service. Forgejo runs automatic database migrations on first boot. The official documentation cautions that while this works reliably, you should test on a staging copy first—especially verifying that LFS objects, SSH keys, webhooks, and user permissions survive intact.

The reverse migration—Forgejo back to Gitea—is not supported. This asymmetry is worth weighing if you are undecided. Once you move to Forgejo, you are committing to its ecosystem and governance model. Migrating outward to GitHub or GitLab from either Gitea or Forgejo is less clean; repositories mirror easily, but issue history, pull request threads, and wiki content require custom export scripts or manual work.

From a data-sovereignty perspective, Forgejo scores exceptionally well. Repositories are plain Git, the database schema is documented PostgreSQL or SQLite, and there are no proprietary blob formats. If Forgejo and Gitea both disappeared tomorrow, your data would remain accessible and migratable to the next fork or a different forge with weeks of effort rather than months. This is the opposite of GitHub's lock-in, where Actions secrets, CODEOWNERS workflows, and issue metadata live in formats only GitHub understands.

Community health and long-term outlook

Forgejo ships a new major release every three months, with patch releases as needed for security and critical bugs. Long-term support versions are published annually; version 15.0, released in April 2026, is supported until July 2027. Codeberg runs production Forgejo at scale, which provides real-world stress testing that smaller projects lack. The project accepts donations via Liberapay and receives funding from NLnet for federation development work, creating a financial base that does not depend on a single corporate sponsor.

The self-hosting community has visibly shifted toward Forgejo as the default recommendation for new Git forge deployments. The r/selfhosted community, Awesome-Selfhosted list, and comparison articles consistently name Forgejo over Gitea for teams prioritizing governance and long-term independence. Fedora is evaluating a move to Forgejo for dist-git, citing its lighter resource profile compared to GitLab. The momentum is real, though the ecosystem of third-party tutorials, Terraform providers, and backup scripts still lags behind Gitea's decade of accumulated tooling.

The risk of Forgejo fading or fragmenting is low but not zero. Non-profit governance protects against a single actor taking control, but it also means development velocity depends on volunteer energy and sporadic grant funding rather than predictable payroll. For a team deploying in 2026, Forgejo's trajectory looks stable—active releases, transparent governance, and a flagship public instance proving it works at scale. The real question is whether federation will mature into a compelling feature or remain a niche experiment.