Gogs

Last reviewed Aug 26, 2026 · 829 words

Gogs is the original, not the imitation, and that is exactly why most people should skip it. Gitea forked from Gogs in 2016 and Forgejo forked from Gitea in 2022; both have spent years adding CI, package registries, and code review that Gogs still doesn't have. What Gogs kept is the thing the forks gave up: a single Go binary that idles at well under 128 MB of RAM and has not asked me to think about it in years. Pick it when the hardware is the constraint or when "will never surprise me" is the feature you want most.

The fork history tells you the whole trade-off

Gogs is effectively a one-maintainer project with a release cadence measured in years, which is the catalogue's "slower feature development than forks" put politely. The upside is that every release is conservative and upgrades are a binary swap. The downside is a feature list frozen somewhere around 2019: repositories, issues, milestones, labels, wikis, basic pull requests, webhooks, organisations, and an API. If any of the following is on your list, go straight to Forgejo and read the Gitea vs Gogs comparison for the rest of the story:

• Built-in CI (Actions-style workflows)
• A package or container registry
• Project boards
• Formal code review with approvals and required reviewers

Webhooks are the escape hatch for the first item. Gogs will happily fire a POST at Woodpecker CI on every push, so "no built-in CI" is a missing convenience rather than a wall.

Install: one archive, one command, one web page

The bare-metal route is genuinely three steps. Download the tarball for your platform from gogs.io, unpack it, and run ./gogs web. It listens on port 3000 and serves an install page on first visit that asks for the database, the domain, and an admin account. Choose SQLite unless you already run PostgreSQL or MySQL for something else; for a personal server or a team under about 10 people, SQLite is the right answer and the file lives next to the binary. Everything the installer writes goes into custom/conf/app.ini, which is the only file you edit afterwards.

For a machine that stays up, run it as a service under a dedicated git user. The repository provides systemd and supervisor units in scripts/, and pointing the unit at the binary is the whole job.

Docker: the SSH port is the one thing to plan

The official image bundles an SSH daemon so clone-over-SSH works without touching the host's sshd. That means the container wants port 22, which the host already owns, so map it elsewhere:

services:
  gogs:
    image: gogs/gogs
    ports:
      - "3000:3000"
      - "10022:22"
    volumes:
      - ./gogs-data:/data
    restart: unless-stopped

On the install page, set the SSH port to 10022 and the domain to the hostname clients will use, otherwise the clone URLs Gogs displays will point at a port nobody can reach. Every persistent thing, including repositories, the SQLite file, and app.ini, sits under /data, so the bind mount is your entire state. Put a reverse proxy such as Caddy in front of port 3000 for TLS; Gogs itself is happy speaking plain HTTP on the LAN side.

Backup is a folder, or one command if you prefer

Because state is a single directory, tar of that directory with Gogs stopped is a complete backup. If you would rather not stop it, the binary has its own command:

./gogs backup --target /backups

That produces a zip containing the repositories, the database dump, and the config, and ./gogs restore --from <file> rebuilds a server from it. Ship the result off the machine nightly and you are done; there is no Redis, no queue, and no object store to remember.

Where it actually fits

Raspberry Pi and other low-power boards, where a Rails or Java forge would eat the whole machine. A private mirror of your GitHub repositories on a NAS. A classroom or small-team server run by someone who does not want to become its administrator. The broader self-hosted git forges post ranks the options; Gogs sits at the "least to operate" end, with GitLab at the other. It is a poor fit for anything where developers will expect GitHub-style workflows, because the gap in pull request tooling is the first thing they notice.

What I'd do

If the machine has a spare gigabyte of RAM, run Forgejo; the extra features cost little and the community is active. If the machine is a Pi, a router-class box, or a VPS you also use for other things, run Gogs with SQLite, the compose file above, Caddy in front, and a nightly gogs backup to somewhere else. Set it up in an afternoon, then forget it exists, which is the highest compliment I can pay a Git server.