Gitea vs Gogs

Last reviewed Aug 26, 2026 · 760 words

Gitea is Gogs. In November 2016 a group of Gogs contributors forked the project because every merge went through one maintainer, and that fork is what 57,605 stars, Gitea Actions, and a package registry grew out of. Gogs kept its original author, its 47,771 stars, and a release schedule best described as occasional. This is a choice between the original and the fork that ran off with the community, and the only argument left for the original is that it still fits in 128 MB.

What the fork added that the original never did

Side by side, the first 10 minutes look identical: GitHub-style repo pages, issues, pull requests, wiki, webhooks, SQLite by default, one binary, app.ini for config. Then you look for CI. Gitea Actions runs GitHub Actions-compatible workflows on a separate runner, so most .github/workflows YAML works with a directory rename. Gogs has webhooks and expects you to bring Drone or similar. Gitea has a package registry for npm, PyPI, containers, Maven, and a dozen more formats; Gogs has none. Gitea has pull request review with approvals and required reviewers, an OAuth2 provider for signing other apps in, and a migration tool that imports from GitHub, GitLab, and Gogs itself with issues and PRs intact. Gogs has a basic PR merge button and an issue tracker. For a solo developer mirroring a few repos, that gap may not matter. For a team of 3 it matters within a week.

Both are genuinely tiny

The catalogue puts Gitea at 256 MB minimum and Gogs at 128 MB, and both figures are honest: I have run each on a Raspberry Pi-class board with SQLite and a handful of repos. Gitea idles higher and climbs when Actions runners and the registry are in use, but "fewer features than GitLab" is its catalogue con for a reason: GitLab wants 4 GB before it says hello. The 128 MB difference buys you Actions, packages, and a maintained project. The git forge roundup has the full memory table across the field.

Deployment, and the SSH port trap

The Docker recipe is the same shape for both: web UI on port 3000, SSH on 22 inside the container. The catalogue's deploy card for Gitea uses gitea/gitea:latest, a /data volume, USER_UID and USER_GID set to 1000, and maps container SSH to host port 222 because 22 belongs to the host's own sshd. Its listed gotcha is the one people hit: clone URLs then read ssh://git@host:222/user/repo.git, and forgetting the port on a fresh laptop hands you a permission-denied from the host's sshd instead of Gitea. Set SSH_DOMAIN and SSH_PORT in app.ini so the UI prints the right URL. Gogs has the identical trap with the identical fix.

Governance, since it shaped both projects

Gogs' bus factor is 1 and has been since 2014. Gitea's weakness cuts the other way: in 2022 the maintainers formed a company, Gitea Ltd, and a portion of the community forked again to create Forgejo under a non-profit, which is the "governance concerns spurred a fork" line on Gitea's catalogue card. Gitea remains MIT and actively developed; the fork question is covered in Forgejo vs Gitea. Gitea has enough contributors to survive a fork and keep shipping; Gogs does not.

Moving from Gogs to Gitea is one-way

The direct upgrade path only ever covered Gogs releases from years ago. The realistic route now is Gitea's repository migration screen, which speaks the Gogs API and pulls repos, issues, and labels across one at a time. Going the other direction means losing anything Gogs cannot represent, so treat a move to Gitea as permanent.

Decision table

What I'd do

Gitea, without much thought. It runs in the same container shape on nearly the same hardware, and every feature you might grow into is already there. Keep Gogs if you already run it, it is doing what you need, and you never want CI; it is not broken, just still. Anyone starting fresh in the git hosting category should read the Forgejo comparison too; that choice comes down to governance.