When people see this title, a few questions usually come to mind: Why? What for? How? In this article I'll share my experience of building a self-hosted Git server, what pushed me to do it, and how you can set one up yourself.

Plenty of homelab owners run a Git server, but not everyone does. It isn't about complexity, it's about need. I work across development, cybersecurity, and DevOps, and I build many tools around my lab's needs. In that process, I built my own self-hosted Git server.

Why I Did It

I didn't do this because GitHub or GitLab are bad. I ran into a few practical problems:

  • Uptime
  • Privacy
  • Internet dependency

You might think: "Is that really enough reason to run your own server?" Fair question. For most people, occasional downtime is a minor annoyance. But if you need an uninterrupted connection, it's genuinely frustrating.

I experienced this firsthand. During a GitHub outage, I needed to pull and push a specific file for a project, and I couldn't reach my own code. That was the moment I started looking for redundancy.

Alternatives I Tried

  • GitLab: One of the best options out there, but it ships with a huge feature set I would never use. It felt too heavy and tricky for my needs.
  • Codeberg: Clean, simple, and privacy-friendly, which fit my requirements well. But it still depends on the internet. If a government shuts down internet access in an area for a period of time, there's no way to reach your repositories or the applications that depend on them.

That last point made me think seriously about building my own. I put it off for a while, but as I learned more about DevOps, cybersecurity, and homelabbing, the idea made sense: an isolated environment for experiments, plus a central server that shares my codebase between my development machine and my experimental machines.

I also tinker with both Windows and Linux when building tools, so a central server made working across operating systems much smoother.

Benefits of a Self-Hosted Git Server

  • Always available: Works on your local network even when the internet or a hosted provider is down.
  • Privacy and control: Your code stays on your hardware.
  • Central hub for your lab: Sync code between development and experimental machines.
  • Learning: Hands-on practice with Linux, networking, DevOps, and security.
  • Customization: Configure access, users, and integrations the way you want.

Requirements

You need very little to get started:

Resource Minimum
CPU 2 cores
RAM 2 GB
Storage 20 GB

Choosing an OS

Many Linux distributions work well, such as Debian, Alpine, and Void Linux. My pick is Debian: it's stable and easy to install and set up. You can run it headless (no GUI) or with a desktop environment of your choice.

Choosing Git Server Software

You can use any of these to host your own Git service:

  • Gitea
  • Forgejo
  • GitLab
  • Gogs

I went with Gitea. It runs well on low resources and does everything I need. Pick whichever fits your requirements.

Installation

Follow the official documentation for your chosen software. You can also use an AI agent to speed things up, but you'll need to give it the full picture of your lab setup (OS, network, storage, users, ports), and gathering that context takes time too.

Running It with Docker

Docker is optional, but it makes setup, upgrades, and migration much simpler, because everything lives in one compose file and one data folder. Here is a minimal docker-compose.yml for Gitea:

 * sample file services: gitea: image: docker.gitea.com/gitea:latest container_name: gitea restart: unless-stopped environment: - USER_UID=1000 - USER_GID=1000 volumes: - ./gitea-data:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro ports: - "3000:3000" # Web UI  - "2222:22" # Git over SSH

Start it with docker compose up -d, then open http://<server-ip>:3000 to finish the setup wizard. For production use, pin the image to a specific version instead of latest, so an update never surprises you.

Backups

A self-hosted server is only as safe as its backups. If the disk dies and you have no copy, your code is gone.

  • Back up the whole data folder (gitea-data in the Docker setup above), which holds repositories, the database, and configuration.
  • Use Gitea's built-in dump for a consistent snapshot: docker exec -u git gitea gitea dump -c /data/gitea/conf/app.ini
  • Automate it with a cron job or systemd timer.
  • Follow the 3-2-1 rule: three copies, on two different media, with one stored off the server.
  • Test your restores. A backup you've never restored is only a hope.

Security Hardening

Running a server means you are now the security team. A few basics go a long way:

  • Use SSH keys and disable password login in /etc/ssh/sshd_config.
  • Enable a firewall (for example ufw) and open only the ports you actually need.
  • Keep everything updated: the OS, Docker, and the Git software.
  • Disable open registration in Gitea so strangers can't create accounts.
  • Enable 2FA for all user accounts.
  • Use HTTPS through a reverse proxy such as Nginx or Caddy if the server is reachable beyond your LAN.
  • Run fail2ban to block brute-force login attempts.
  • Avoid exposing the server directly to the internet. For remote access, use a VPN like WireGuard or Tailscale instead.

Trade-offs

Self-hosting is not free. Be honest with yourself about what you're taking on:

  • You own the maintenance: updates, security patches, and troubleshooting are on you.
  • You own the uptime: if your server or your power goes down, there's no status page and no support team.
  • You own the backups: nobody else is keeping a copy of your code.
  • It takes time: the initial setup is quick, but ongoing care is real work.

For a lab, the trade is worth it for me. If you need collaboration at scale or zero maintenance, a hosted service may be the better choice. A good middle ground is to mirror your repositories to GitHub or Codeberg, so you get offsite redundancy while keeping your own server as the primary.

Conclusion

Self-hosting a Git server isn't about replacing GitHub or GitLab. It's about independence, reliability, and a great learning project. If you work in development, DevOps, or security, I recommend trying it at least once. It takes very little hardware, and you'll learn a lot along the way.

If you've built your own, I'd love to hear what setup you chose and why.