Before diving into the “why”, let’s define the “what”. Both GitLab and Gitea are self-hosted Git services. They allow you to host your source code on your own hardware, manage versions, and collaborate.
While GitLab is a massive “DevSecOps” platform that handles everything from project management to CI/CD and security scanning in a single interface, Gitea focuses on being a lightweight, fast, and painless self-hosted Git service.
In the world of DevOps, there’s a massive trend toward these “All-in-One” platforms. GitLab is the king of that jungle. But it comes with a price that isn’t just financial. It’s about RAM.
The Law of the Jungle: RAM is a Scarce Resource
On a VPS, memory is like water in a desert. There is a permanent shortage, and every process must fight for its survival. If a tool is too greedy without a rock-solid justification, it deserves the OOM Killer treatment.
Running a full GitLab instance just to host some scripts and Dockerfiles is like buying a semi-truck to go get groceries. It’s a tactical error. Giving 4GB+ of RAM to a Git server when you’re trying to build a lean, resilient empire is simply inefficient.
Enter Gitea: The Git with a Cup of Tea
I chose Gitea because it respects the constraints of a self-hosted infrastructure:
- The Footprint: It runs on a potato. We’re talking about 100-200MB of RAM for a standard setup. This leaves more room for actual services, databases, and experiments.
- The “Single Binary” Simplicity: Written in Go, it’s easy to install, update, and back up. No complex “Omnibus” installer that might break OS dependencies during a midnight update.
- The Mirroring Strategy: I host my code on my own metal (Hetzner) for sovereignty, but Gitea automatically mirrors public repos to GitHub. I get the privacy of the lab and the reach of the cloud without the overhead.
Resilience over Hype
Choosing Gitea isn’t about being cheap; it’s about being a minimalist architect. Complexity is the enemy of uptime. By keeping the Git layer thin, the infrastructure stays fast, responsive, and easy to maintain. In the end, true technical maturity is knowing when to say “no” to features you don’t need in exchange for a system you can actually control.
