It’s the year 2018 and it’s impossible for a software developer to have not heard about (or used) Github, or a variant like Bitbucket. Even self-hosted Git evangelist GitLab is a popular choice.
However, at the start of February 2018, I provisioned a new Cloud VPS to run my website and other apps. I also chose to migrate all my private Git repositories to it and cancelled my paid Github subscription.
There are several reasons why I chose to go with self-hosted Git repositories.
Since creating The Andy Sanc’tree in 2013, and subsequently launching andyheathershaw.uk in 2015, I’ve always paid for a virtual server to run my websites.
For the last couple of years, I’ve also paid for Github to store the code for my own apps.
My server costs me £35 a month; Github approximately £5 (depending on the exchange rate.)
Therefore I save about a fiver each month by self-hosting my own Git repositories on the server I’m paying for anyway. I only use Github now for my open-source projects, which I can do with a free account.
I don’t like not having control over critical elements of my projects. Hosting my source code on Github was fine when it was just my personal website. Since launching my free email and SMS reminder service, Simply Remind Me, which holds personal data, I need to know that my code is safe.
I can enforce firewall rules on my Cloud VPS and backup my server off-site to my cloud storage account.
If a security breach happens, or I lose some code or data because it wasn’t backed up properly, it’s on my watch.
I can handle that; it’s my fault. I can’t handle a third-party provider losing it in some way that’s totally out of my control.
If you think I’m being paranoid, GitLab lost 6 hours of production data in 2017 when a team member accidentally removed almost 300GB of data from a primary database server.
I’m not a typical software developer, who leaves it to the networking and server guys to keep their precious applications running smoothly.
I enjoy all the boring, monotonous system admin tasks – configuring, patching and maintaining my server. I’m comfortable with the command-line, and I have used Ubuntu Linux in some way, shape or form, since it’s release in 2004.
This also goes hand-in-hand with the above point. I have full control over when patches are applied and my server is rebooted.
You could say I enjoy DevOps, but I’m also a traditionalist, and just call it plain-old system admin.
There are several software packages to choose from that allows you to self-host your Git repositories.
GitLab offer a community edition – however it requires 4GB free memory (my server has 4GB in total!) and I’m always nervous of using an enterprise company’s “community” or “open-source” product, as they are free to revoke it at any time.
I chose Gitea – an open-source project, written in Go, which is itself a fork of Gogs (Go Git Service.) Gogs aims to offer equivalent functionality to Github, with a familiar interface. Even the Gogs API attempts to replicate Github’s API like-for-like.
The only issue with Gogs is that it’s maintained in its entirety by one person, which means new releases and bug fixes are sometimes a long time in coming. If the maintainer does not agree with a suggestion, it is not implemented.
The open-source community forked Gogs to create Gitea. The project team release new updates quicker than Gogs’ maintainer and Gitea’s functionality now surpasses that of Gogs. In fact, Gitea is now a successful project based off its own merits.
Both Gogs and Gitea have a significantly smaller footprint than most other systems. My Gitea instance is currently running with a footprint of just 37MB, and a total of 176MB allocated since its launch.
Using Gitea, I mirror my open-source Github repositories to my own server, and directly host my private repositories just on my server.
You can check out my own Gitea instance at apps.andyheathershaw.uk.
The irony is not lost on me that both Gogs and Gitea manage their respective projects and source code on Github. I don’t know why either.