---
title: "Summary of Free Self Hosted Git Options"
author: "James Pace"
date: "2024/01/12"
---

# Introduction

A few years ago I set started setting my own self hosted
development stack [^dev-stack-defintion] at home in Kubernetes.
Particularly, I currently self host gitea, a server hosting apt and
rpm repositories, a CI stack built with Tekton, and a container registry.
This article will focus on why I chose to self host anything at all,
why I chose to self host a git forge specifically, and why I chose
Gitea from the different options on the market.

# Why self host a git forge?

Cloud hosted development stacks like Github and Gitlab are extremely popular and
are used by a number of open source projects, individuals, and companies.
Using Github removes a lot of friction from taking community contributions because
it has a well understood workflow and a huge proportion of your potential contributors
already have an account there.
I don't have statistics to back up the claim that a number of companies use the
hosted on the cloud version of both tools, other than the option to buy both exist,
and there is no short of articles proclaiming the awesomeness of using B2B subscription
SaaS products.

I'm not a huge fan of putting components that are integral to our ability to do work
on (and only on) the internet in the defence and "dirty" commercial sectors.
24/7 good internet connectivity is not something we should assume exists in the sectors
we want robots to operate in, and we should build our workflows with that in my mind, picking
tools that we can bring with us.
This neccessitates a very "Edge" focused mentality towards the cloud, which biases my perception
towards picking tools I can self host.
Particularly, tools I can self host on hardware that can be brought with me when I can't assume
24/7 connectivity.
My original goal in setting up my own development stack was to see how far I could reasonably
build my own "Cloud on the Edge" that could be brought with me as part of a disconnected
command center if the need arised.

A git forge specifically is a very important part of a modern development stack.
Git forges are the primary way code is shared between developers, and without
a git forge modern software development in teams would have to radically changed.
Git forges are more and more being used as the single source of truth for things like
configuration management, with modern CD workflows basically boiling down to pull
something from a git repo and do the thing in it.

# Why I chose gitea?

## Other Options

### Gitlab

### Onedev

### Gerrit

[^dev-stack-definition]: I'm going to use *development stack* in this article to refer to the combination
of a place to host git repos, do code reviews, run CI/CD, and host packages, for lack of a better
term.

<!--
Why:
1. All sorts of programming tools support git and using git for versioning.
2. Expecially with gitops being a real thing.
3. But we want to maintain control and be able to still operate completely offline.

Options:
1. Gitea
2. gitlab
3. onedev
4. gerrit

gitea:
1. Lightweight
2. Easy to host, just add a docker container.
3. Not the most mature open source community based on their
   github PRs.
4. They host their development on github...
5. Heavy development in China, which is not great for US Defense
   oriented companies

gitlab:
1. Most feature complete, with really good integrations with all kinds of stuff.
2. Almost every thing I've seen integrates with gitlab.
3. Fat. Hosted on a VM with 4Gb of RAM, the server kept getting OOM killed when I
   was just logged into the admin panel. I currently host all my infrastrture
   apps in a single VM with 4Gb of ram.

Onedev:
1. Has lots of features.
2. LIghtweight
3. Only a single developer doing most of the development, no real open source community.
4. Lots of little bugs that added up.

gerrit:
1. Had the better review process
2. Really easy to write custom integrations with.
3. Felt "powerful" using it.
4. Code display interface sucks.
5. Workflow very different than github.

-->