Forgejo vs Gitea

You can run either of these for a year and never notice which one you installed. Same single Go binary, same 150 MB idle, same port 3000, same SQLite-by-default, same GitHub-shaped issues and pull requests. The spec table will show you two rows that are nearly identical and one that is not.

The row that is not identical is the licence, and it is the whole article.

Read the matrix below for license, license_class and first_release. Everything else being equal is the point: when two products are this close on capability, the tiebreaker is structural, not technical. Note also that Forgejo shows as stable and Gitea as mature, which reflects the 2022 fork date rather than any difference in how reliably they run.

What actually happened, in order#

Gitea itself is a fork. It split from Gogs in 2016 over exactly this issue: a single maintainer controlling a project the community depended on.

In October 2022 the Gitea maintainers announced that the domains and trademark had been transferred to Gitea Ltd, a newly formed for-profit company. The transfer happened before it was announced. Community contributors who had spent years on the project found that the name, the website and the trademark now belonged to a company they had no stake in, and that future contributions would carry a copyright assignment.

Within weeks a group of contributors forked the codebase to Codeberg and named it Forgejo. Governance moved to Codeberg e.V., a registered German nonprofit with published statutes and no shareholders. For the first year and a bit Forgejo was a soft fork: it tracked Gitea commit for commit, added a few patches, and functioned as a rebrand with different governance.

Two things ended that.

In February 2024 Forgejo announced it would stop rebasing on Gitea and develop independently. Forgejo v7.0 was the first genuine hard fork release. Then on 22 August 2024, Forgejo v9.0 relicensed from MIT to GPL-3.0-or-later. That second move is the one with teeth. Gitea's MIT licence plus a contributor copyright assignment is precisely the combination that lets CommitGo, Gitea Ltd's subsidiary, build a proprietary Gitea Enterprise on top of the free core. Forgejo's GPL-3.0-or-later makes the same pattern impossible against Forgejo's code, because a derivative work has to ship under the same terms.

So is Forgejo still a soft fork?#

No, and anyone still describing it that way is working from 2023 information.

The practical evidence is the migration path. Forgejo v10.0, released January 2025, was the last release able to read a Gitea v1.22 or older database directly. Forgejo is now on the v16 series while Gitea is on v1.27.x; the version numbers are not even in the same space. Database schemas, configuration keys, the moderation tooling, the code review interface and the Actions implementation have all drifted.

Forgejo still cherry-picks security fixes from Gitea where they apply, and Gitea has taken patches that originated in Forgejo. That is normal fork hygiene, not shared development.

The uncomfortable consequence: the escape hatch is closing in both directions. If you are on Gitea v1.23 or newer today, moving to Forgejo means exporting and re-importing repository by repository, and issue and pull request history does not come along unless you script the API yourself. Decide now rather than in 2029.

Pick Forgejo. Here is the cost of doing so.#

A recommendation with no downside listed is marketing, so here are the real ones.

Copyleft irritates corporate legal reviews. GPL-3.0-or-later on a network service triggers no obligation for you as an operator, but plenty of legal departments have a blanket policy against GPL-3.0 in the estate and will not read the nuance. If yours is one of them, Gitea under MIT is the pragmatic choice and you should take it without guilt.

Fewer eyes, less money. Codeberg e.V. runs on donations. Gitea Ltd has a payroll and enterprise customers. Forgejo has fewer paid full-time contributors, and on any given week the review queue is shorter and slower. The counterargument is that the licence guarantees continuity regardless of who is funding it, which is not something a payroll gives you.

Federation is still not done. ActivityPub federation has been Forgejo's headline differentiator for four years and it remains partial. Do not choose Forgejo for federation. Choose it for governance and take federation as an eventual bonus.

No commercial support contract. If a purchasing process requires a vendor to call, Gitea Ltd sells one and Codeberg e.V. does not.

None of those outweigh the structural argument for a person or team choosing today. You are picking where your entire source history will live for the next decade, and Licence drift exists because "the licence will not change" has been wrong repeatedly across this ecosystem.

Running either one: the parts that bite#

The operational surfaces are close enough to share a section.

Forgejo's official image is codeberg.org/forgejo/forgejo:16 and Gitea's is gitea/gitea:1. Both cover amd64 and arm64. Both mount a single /data volume, serve HTTP on 3000 and want an SSH story on 22. A minimal Forgejo stack:

services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:16
    environment:
      USER_UID: "1000"
      USER_GID: "1000"
      FORGEJO__server__SSH_PORT: "222"
      FORGEJO__server__ROOT_URL: "https://git.example.com/"
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
    ports:
      - "127.0.0.1:3000:3000"
      - "222:22"
    restart: unless-stopped

Four traps that apply identically to both:

1. The first-run installer is unauthenticated. The setup page is served to anyone who reaches it, and the first account created becomes the instance administrator. Publish port 3000 before you finish the wizard and someone can complete it and own your forge. Bind to 127.0.0.1 as above, or pre-write app.ini with INSTALL_LOCK = true and create the admin from the CLI.
2. Clone URLs come from config, not from Docker. The SSH URL in the web UI is built from SSH_DOMAIN and SSH_PORT in app.ini. Map host 222 to container 22 without setting SSH_PORT = 222 and every developer copies a URL that times out. Same for ROOT_URL behind Caddy or Traefik: get it wrong and webhooks, OAuth redirects and avatars all break differently.
3. Git hooks bake in absolute paths. Every repository's hooks reference the absolute path of the binary and its config. Move the install, switch from a package to a container, or restore into a different layout, and pushes fail with an opaque hook error while the web UI looks perfectly healthy. Regenerate hooks from the admin panel after any move, which is a step Moving a service to a new machine will remind you about.
4. Pick your database at install time. Gitea's own docs warn that converting an existing instance from SQLite to PostgreSQL is not well tested. Choose PostgreSQL up front if you expect more than a handful of active users, or accept SQLite permanently.

For backups, both ship a dump command (forgejo dump, gitea dump) that archives config, repositories, the data directory and an SQL dump into one file. The documentation is explicit that the instance should be stopped during the dump, because a live copy can catch the database and the repository files at different instants and you will not find out until a restore. Exclude gitea/indexers and gitea/queues; they rebuild in minutes. Pair it with an off-box target as Backups that actually restore describes.

Both support OIDC and LDAP natively as authentication sources, so wiring either into authentik or Pocket ID is admin-panel work rather than a plugin hunt. Single sign-on for self-hosters covers what to expect from the rest of your stack.

Verdict by situation#

What to do next#

Stand it up on a throwaway VM first with SQLite, push one real repository, and try the thing that actually matters: forgejo dump, destroy the VM, restore into a fresh container, and confirm the pushes still work. That single rehearsal tells you more than any feature matrix, and it is where the hook path problem surfaces before it costs you anything.

If you are moving off GitHub rather than choosing between forks, Replace GitHub covers the parts that are not the git remote: Actions, Pages, releases and the issue import. And if you want the browser editor as well, code-server next to the forge is a lighter answer than anything either project ships.