Gitea vs Gogs
Pick Gitea — the same small Go binary on the same 512 MB floor, but with the Actions runner and package registries built in and a contributor base big enough that most questions already have an answer somewhere. Pick Gogs when you want the leanest forge that still does the job: it is the project Gitea was forked from, still maintained, and it gives you repositories, issues, pull requests, a wiki and webhooks with none of the CI machinery attached.
Side by side
These two share a codebase the way a tree shares a trunk with the branch cut from it: Gitea is a fork of Gogs, and years later both are still alive, still written in Go, still shipping as one small binary that wants half a gigabyte of RAM and no database server if you do not want one. Nothing about the install separates them. What separates them is what each project decided to become after the split — and whether the extra surface Gitea grew is something you want on your server or something you would rather not have to think about.
The same starting point
Gogs set out to be "a painless self-hosted Git service", and the shape of that goal is still visible in what it ships: repositories, issues, pull requests, a wiki, webhooks, deploy keys, Git hooks, LDAP and OAuth logins. It runs from a single Go binary or a single container, stores its data in SQLite by default, and speaks PostgreSQL, MySQL and MariaDB when you outgrow that. Upstream is blunt about the hardware: a Raspberry Pi is enough to start, and two CPU cores with 512 MB of RAM is the baseline it names for a team. Memory stays flat as people join — the advice is to add cores, not RAM.
Gitea started from exactly that code and kept the same install story: one binary, one container, SQLite by default, the same 512 MB, the same 2 out of 5 difficulty in our catalogue. If you have deployed one you have deployed the other. The difference is entirely above the install line.
What Gitea added
Two additions do most of the work in this comparison.
A CI runner. Gitea Actions is built into the server, with a workflow syntax close enough to GitHub's that a lot of existing pipelines port with minor edits. You register a runner, drop a workflow file in the repository, and pushes start building. Gogs has no runner and does not want one — it has webhooks (including Slack, Discord and Dingtalk), Git hooks and deploy keys, so it can trigger Jenkins, Woodpecker or anything else that listens, but the building happens somewhere else, in something else you have to run.
A package registry. Gitea hosts container images and language packages alongside the code. Gogs does not, so an internal registry is another service on your list.
Around those sits the less countable difference: a much larger contributor base and a much faster release cadence. That is the one place the table above scores a win, and it is scored deliberately. Gogs having fewer features is a design choice and not a defect; Gogs having fewer maintainers is a real operational consideration when the software in question is where your code lives.
When less is the point
There is a genuine case for Gogs, and it is not nostalgia.
If what you want is a private place to push Git repositories, review the occasional pull request and keep a wiki, then the CI runner and the registry are attack surface, upgrade surface and configuration surface you will never open. Gogs gives you the small half of Gitea with nothing bolted on, in a project that is still maintained and still moving, just quietly. Its documented Docker layout puts the web UI on 10880 and SSH on 10022 precisely so it can sit beside things that already own the normal ports.
Starting small also does not lock you in. Because Gitea grew out of this code, the repository layout and the concepts underneath both are the same, so the stakes of choosing the lean one first are lower here than in most head-to-heads — and the plain fallback, pushing repositories to a new remote, works no matter what.
Which should you self-host?
Pick Gitea if…
- You want builds to run where the code lives, without standing up a separate CI system.
- A container or package registry is on your list, now or soon.
- You value the larger community — more guides, more integrations, more people who have already hit whatever you are about to hit.
Pick Gogs if…
- You want a Git server and nothing else, and every feature you do not use is a feature you have to keep patched.
- The box is genuinely small — a Pi, a shared VPS, a corner of a server already doing something else.
- You already have CI somewhere, and webhooks plus Git hooks are all the integration you need.
Running either on a VPS
Sizing is not the deciding factor here, because there is nothing to decide: both are frugal Go services with a 512 MB floor and a 2 out of 5 setup, and either fits on the smallest instance worth renting with room left for a reverse proxy. Point the container at a data volume, put HTTPS in front of it, and remember that Git over SSH needs a port — the host's own sshd already owns 22, so map the container's SSH port somewhere else and tell users about it. Move from SQLite to PostgreSQL when the team, not the disk, starts to feel it. If you do run Gitea Actions, that is where the sizing changes: builds want CPU and memory of their own, and the honest answer on a small box is to run the runner on a different machine. Setup steps and VPS options are linked below.