Your client's source code lives on GitHub — until the repo goes private on a plan you didn't budget for, or legal asks whether US-hosted Git meets their data requirements. GitLab self-hosted is powerful and heavy. You want something in between: real pull requests, issues, and CI — without running a small Kubernetes cluster to host a forge.
Gitea is that middle path. ~56k stars, written in Go, one lightweight binary (or one main Docker container), and a web UI that feels familiar if you've used GitHub. Git hosting, code review, issues, wikis, package registries, and Gitea Actions for CI/CD — self-hosted on your own server.
What it actually does
Gitea is a Git forge — the place your team pushes code, opens pull requests, tracks bugs, and reads README wikis. Organizations, teams, and fine-grained repo permissions work the way you'd expect from a modern Git host.
Gitea Actions (enabled by default since 1.21) runs CI workflows using syntax largely compatible with GitHub Actions. Workflows live in .gitea/workflows/. You register Gitea Runners — separate processes, ideally on another machine — to execute jobs in Docker containers so builds don't eat your Git server's RAM.
Package registry — publish and pull container images and other OCI packages from your own instance, authenticated with personal access tokens.
SSH git clone works on port 22 inside the container (often mapped to 2222 on the host). HTTPS on port 3000. SQLite is fine for solo devs and small teams; Postgres or MySQL when you grow.
Why self-host Git?
Your code stays yours. Proprietary client repos, internal tools, infrastructure-as-code with secrets-adjacent config — self-hosting means no third-party ToS change can lock you out or expose private repos to a vendor breach you didn't choose.
Canadian residency. For businesses answering PIPEDA questions, "our Git server runs on a VPS in Montreal/Toronto" is a cleaner story than "it's on github.com."
Cost at team scale. GitHub Teams and GitLab SaaS add per-user fees. Gitea on a modest VPS costs the same whether you have five developers or fifty — you pay for the box, not seats.
Lightweight ops. Gitea uses roughly 200 MB RAM at idle with SQLite — a fraction of GitLab's appetite. Small agencies and homelabs actually finish the install the same day they start it.
What running it takes
Docker Compose is the common path. Minimal setup: Gitea container + optional Postgres:
docker compose up -dOfficial image: docker.gitea.com/gitea:latest (pin a version tag in production). Mount /data for repositories and config — that's what you back up. Complete the web installer at port 3000: database connection, admin user, site URL.
Sizing: SQLite + a handful of repos runs on 1–2 GB RAM. Teams with Actions, large monorepos, or hundreds of repos want 4 GB+ and Postgres. Run **runners on a separate box** if CI builds compile Docker images — your Git server shouldn't compile and serve HTTP at the same time on a 2 GB instance.
Enable HTTPS with a reverse proxy and real domain — git clone URLs embed the hostname. Disable open registration unless you want a public forge; most business installs invite users manually. Back up the data volume and database; test restore before you need it.
Need GitLab's full DevSecOps suite instead? Heavier, but sometimes the right call — we host that too on GitLab hosting.
Who it's for (and who should skip it)
Good fit: small dev teams, agencies storing client code privately, open-source maintainers wanting their own forge, anyone migrating off GitHub without GitLab's resource footprint.
Maybe skip it: if you're happy on GitHub free for public repos only. If you need enterprise audit logs, advanced compliance modules, and built-in security scanning at GitLab Ultimate depth — Gitea is simpler than that. If nobody will patch the instance, SaaS Git is less work.
Hosting it in Canada
We run Gitea on Canadian Docker hosting — TLS, Postgres, volume backups, and optional runner VMs for Actions. Pair it with Uptime Kuma so you know when git push fails before the team Slack does.
Tell us team size and whether you need CI runners — we'll size the Git server and runners separately so builds don't take down code review.
