Summary of Free Self Hosted Git Options

Introduction

A few years ago I started setting up my own self hosted development stack ¹ 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 shortage 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 defense 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 into the zones we operate in. 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 look radically different. 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?

I currently use gitea for as my personal git forge. Gitea is an open source git forge that heavily borrows from Github’s UI and feature set. Someone who has used GitHub should reasonable be able to “guess” how to do the primary tasks they need to do on Gitea drawing on that experience. Gitea is extremely light weight, with a number of people online running it on Raspberry Pi’s.

A number of different organizations use Gitea in some capacity:

1. OpenStack uses it as a tool to browse code. (They do code reviews with Gerrit.)
2. Blender hosts their main git forge on Gitea.
3. Defense Unicorns puts a Gitea instance in their disconnected K8s clusters that are provisioned with Zarf.

There are two reasons I chose to go with gitea.

1. It is extremely light weight and easy to host. I was able to get a test version running on my laptop in a container running very quickly. Once I decided to fully move to it, setting it up on Kubernetes was fairly straight forward. I’ve not looked at its resource usage on my currenty cluster, but I know pre-Kubernetes I ran it on a Vm with less than 1Gb of RAM.

2. It has the best community support. When looking at other tools that integrate with a git forge, I noticed pretty much all of them natively have support for Github, most of them also supported self hosted Gitlab, and if they support anything else without using SSH directly, it is Gitea.

With that being said, I did have some concerns initially and spent a lot of energy looking for better alternatives. Particularly:

1. Looking at their public Github, I didn’t get the feeling the project was very mature. It’s hard to put a finger on why I felt (and still feel) that, but there is something about building something that is so unbashedly a clone that feels immature to me.
2. The maintainers are mostly in China, which makes it challenging to ever push at work. This may come off as Xenophobic, but our customers are and sort of are supposed to be distrustful of other countries, and those requirements flow down.

Other Options

Gitlab Community Edition

One of the options I really wanted to like was Gitlab, particularly their open source free edition. As I mentioned earlier, outside of Github, Gitlab has the best community support, and I know of a number of Open Source projects that aren’t on Github that use it.

Particularly:

1. Debian Salsa is a “hosted by the Debian project” Gitlab instance.
2. Red Hat uses the Cloud version for some of their projects, most interestingly to me Centos Automotive.

Unfortuntely, Gitlab is fat, requiring an insane amount of RAM to just idle. I tried running it on my laptop in a VM with 4Gb of RAM, and with the system idling, and the only thing happening being me in the admin panel, browsing, the server kept getting OOM killed. Their docs say the minimum amount of RAM is 4Gb and they are not kidding.

Onedev

Onedev is an all in Git forge largely produced by one guy.

I really wanted to like Onedev, and ran it as my primary Git forge before my last install of Gitea. Unfortunately, there were just too many little UI bugs that added up so I couldn’t really suggest anyone else use it at like work, and again its mostly developed by one guy.

It ran great on a VM with very little RAM, though.

Gerrit

Of the git forges I looked at, Gerrit was the only one with a unique workflow that wasn’t the Github Pull Request style. The distinguishing component of Gerrit’s workflow is that a PR will only consist of a single commit at any one point in time, and feedback is implemented by ammending and then replacing that one commit until the PR has been accepted. The workflow basically boils down to:

1. Make a change you want to PR on a branch with all the changes in a single commit.
2. Push the commit to a special URL. It will become a PR.
3. Get feedback.
4. Implement the feedback and ammend it to the one commit for the PR.
5. Force push the new commit, get more feedback, and repeat until the commit gets merged.

Gerrit has some custom tooling built on top of Git which makes this easy to do.

I actually liked the workflow and think that in a fast moving software shop it would have a lot of benefits. It’s pretty similar to merging PRs with squash merges in Gitub style workflows, except for the squash merge is done though the whole development process not just at merge. I think having a commit per PR, even for things in progress, would make managing integration branches that contain multiple in progress PRs easier to manage.

I also like Gerrit’s API, and it was very easy to write custom integrations with it,

The main problem I had was with Gerrit’s UI for code browsing, which is basically nonexistent, and makes Gerrit completely unusable as a code portfolio, which is one of the things my public repos effectively are.

The other issue is that as much as I think the workflow would be nice in a fast moving software shop, my personal projects where I don’t even really do reviews just isn’t that.

Conclusion

When looking to host a git forge I looked at four different options before ultimately going with Gitea, due to it’s ease of host and good community support.

The other options I looked at each have interesting properties, but weren’t suitable for what I’m doing right now.

Footnotes

1. 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.