--- 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? 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. Gitea is extremely light weight, with a number of people online running it on Raspberry Pi's. 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 farily straight forward. I've not looked at its resource useage 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's 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 in the national defense field, our customers sort of are supposed to be distrustful of other countries, and their 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. 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'd 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 [^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.