Forge Joe? For Gee Yo? Git Tea?
Let’s take a quick sidebar to talk about Git servers (and version control in general)
My preferred self-hosted Git server is currently Forgejo. Forgejo (pronounced for-JAY-oh) is a fork of Gitea (which itself started as a fork of Gogs). All of these are aimed at being lightweight-but-powerful Git servers with all of the features one would come to expect from modern Git software, and I’ve used each of these (and more!) at various points in time in the past.
I was going to do a quick rundown of what Forgejo is and why I like it in my upcoming sequel to Dockerize’ing my website, but because it was overly long-winded (what? me? never.) I decided to split it out into its own blog post.
Here’s a quick story about my VCS journey.
The beginning - hg
The first lines of code I ever wanted to keep in version control were actually dotfiles for various programs I was using at the time. This was back in the early 2010’s, when I was in university and thus experimenting with all sorts of softwares and configurations. Window managers, terminal-based apps for things like email and web browsing, etc. The usual.
At the behest of a friend (who may or may not be reading this blog, and knows who he is…), I decided to set up Mercurial as a central repository for my various files. I don’t actually recall which Mercurial server I was running - which should tell you all you need to know about how importantly I treated this server (and the data inside of it… I don’t actually think I have any data remaining from this phase of my VCS journey).
s/hg/git/
Time passed, and Git took the VCS world by storm. For a while I wasn’t self-hosting any version control repository at all, and instead elected to use GitHub - I was eligible for an Education Account through my university, so I used that to host a few private repositories (this was back when private repos cost extra money to host). I wasn’t hosting anything critically important (or sensitive) on GitHub, even in my private repos, and I didn’t have quite as strong of a sense of desire for data control as I do now.
A few more years went by, and when I got my first adult job out of university in 2014 I was exposed to the wonderful world of Gitlab. This made my brain explode a little bit… a full-on Git server that you can run locally? I was hooked. I installed it into my fledgling homelab and was off to the races - happy as a clam!
Even back then, GitLab was a little bit more heavy that I really wanted - even back in the 2015-ish timeframe GitLab had contained within it a fairly fully-featured CI functionality, wiki/issues, etc… which I wasn’t taking advantage of in my lab. I just wanted a place to put code.
Rip-n-replace, rinse-n-repeat
From here, the details and timelines start to get a little bit fuzzy, as this was a point in my homelabbing career that I was prone to changing my setup on a whim. Because of this, I’m going to speed through this next part.
Towards the end of 2018 I decided that GitLab was too heavy and wanted to try out some alternatives. I investigated Gogs for a short period, but wound up discounting it in favor of a Gogs fork, Gitea. This was a git server which wasn’t trying to be anything other than a git server, with basic functionality and modest hardware requirements - which for me at the time was perfect!
In 2021, after the migration of my homelab from a bunch of desktop-class machines to a single enterprise-grade Dell R720, I decided that I wanted to lean back into GitLab. I finally had the horsepower in my lab to run some “big boy” services, and I think I was wanting to learn more about IaC and having things build automagically - using GitlabCI and its built-in Docker image registry. Then life got in the way and I never really got down to CI/CD’ing my lab.
A cup of Tea, a cup of Jo
I remember once again having a sour taste in my mouth with the resource requirements for GitLab, which I believe at the time was 4 cores worth of CPU and 8GB of RAM at a minimum (I’ve since learned that the minimum requirements have increased again to 8 cores and 16GB of memory!). I only had a dozen or so repositories, with no artifact storage and no CI/CD. Even with my beefier horsepower, did I really need to dedicate 10% of it just to a git repository?
In 2022, I had finally had enough and decided to switch again, this time back to Gitea. It was small, but becoming more fully featured all the time (towards the end of 2022 Gitea introduced experimental support for Github-type actions!) and felt like the right move. So I migrated all dozen-or-so repositories to a smaller Gitea VM.
From there, I was a happy Gitea user - up until the middle of last year. I had seen Gitea in the news a couple of times over the preceeding year, largely for bad reasons (details here), but the straw that broke that camel’s back was the discovery that the for-profit company which had taken control of Gitea in mid-to-late 2022 was keeping advanced notice of security releases for its paying customers only, which bothers me greatly. Forgejo had recently hard-forked from Gitea, so it seemed like as good of a time as any to switch. I was luckily running an early enough version of Gitea to where I could simply download the corresponding version of Forgejo and replace the binary, and everything worked properly.
The nice thing about Gitea/Forgejo is that they do now fully support their equivalent of GitHub Actions, along with their equivalent runners (blog post about this coming soon!), and they also support a built-in Docker image registry - so I not only get a relatively slim git server, I also get some of the more advanced functionality that I wanted out of GitLab in the first place!
Win-win.
Conclusion
So, this is where we are now. I’m running Forgejo v10, with a couple of VMs for runners and also using Forgejo as my custom Docker image repository. I’m happy as can be with this setup, and I hope to continue using Forgejo for many years to come!
Disagree with my methodology or my decisions? Have suggestions or ideas that I didn’t think of? Leave them in a comment below!