|Too Long; Didn’t Read|
|I deployed a VPS and set up Gitea on it.|
|I now have an alternate, fully independent remote for my Git-based projects.|
|If Github or GitLab ever go down, my projects will still be available to me on my instance.|
Introduction - The Rise Of Git (And Github)
Git had overtaken Subversion in popularity (in general) around 2010. 〈git-vs-svn〉 It has a slew of features that makes it a better choice for open source, community-backed software projects. Github grew in popularity because it offerred an easy-to-use interface for experienced Git users who wanted convenient remote source-code storage. In addition to that, it enticed novice programmers to get acquainted with Git. It was a positive feedback loop. Eventually, Github became the Instagram for developers and Git became a relatively low-skill prerequisite.
Note that it’s definitely possible to be skilled in the use of Git. Here, I’m calling it low-skill because developers simply need to do the following:
- Initialize a repository before or after writing code with
- Stage changes with
git add <path>
- Commit the changes with
git commit -m "<commit message>"
- Set up a remote with
git remote add <remote name> <remote SSH/HTTPS path>(once per remote)
- Push the changes to the remote repository with
git push -u <remote name> <master or main>
Git is obviously a thousandfold more nuanced than that. 〈pro-git-book〉 These, however, are the steps that every developer must take when they want to publish their code on Github. In my humble opinion, it’s not that complicated. It practically becomes muscle memory after pushing a few dozen commits.
If Github is so popular, why am I looking for an alternative? There are a few reasons for that. I’d like to discuss at length.
Monopoly Isn’t Good
Before Github, there were several project hosting sites (many of them are still functional) like Google Code Project Hosting (2006-2016), SourceForge (active as of 2020). With the advent of Github, people flocked to it for its updated UI and pleasant UX. And there were no good competitors for Github for a long while, until GitLab arrived.
And you know that happens when you’re the most popular service in a market and there are no competition to keep you honest; you start gatekeeping features for pro users, and provide only the bare minimum to the free users. You make sure that the subscribed users receive preferential treatment because they’re the ones covering the cost of the free users while also paying your salaries. Note that this is not a wrong thing to do. It’s business 101. It’s the “technically correct” solution. To Github’s credit, they were pioneers and downright generous towards free users. Their strategy was to nag the free and well-earning users just enough to nudge them towards loosening their pursestrings for a Pro subscription.
“technically correct” – The best way of being correct. 🙃
GitLab knew it was a monumental task to try and compete with Github for marketshare. So they didn’t. At least that was not their primary objective. They set out to build a product, not a website. From the very beginning, they targetted the Enterprise market by offerring a streamlined, feature-packed, self-hosted alternative to Github. Github was initially only available as the freemium website. Moreover, while Github deferred CI/CD tasks to third parties, GitLab incorporated it in its entirety and provided it as a feature from the start. DevOps folks were really into it.
GitLab’s plan worked. Github finally had worthy competition. GitLab even proceeded to allow free users to create an unlimited number of private repositories as opposed to Github who initially allowed private repositories only to subscribed users. Does this mean problem solved? Not really. GitLab is also a for-profit organisation. There will be certain restrictions applied to their product as well. One of those is that the self-hosted version of GitLab requires a minimum of 4 GB of random access memory with the recommended amount being 8 GB. That turns out to be quite the amount for a person like me who can only comfortably afford a VPS with 1 GB of RAM.
The World Of Self-Hosting
My progress in learning about web technologies is painfully slow. I found out about the things I can do with a VPS only recently after I set up a VPN on one. 〈ltt-diy-vpn〉 Gradually, I’m warming up to the idea of putting things on a server. I now have a general idea of what’s worth running on a remote server and what needs to be delegated to the client device. Briefly, I can summarise my observations as:
- Low-risk, lightweight computations without access to personal user data can be delegated to the client. This is where PWAs shine. Even if the app gets reverse engineered, there is no sensitive information to be exploited.
- Proprietary implementations, authentication tokens, user-data and other sensitive information must be protected at all costs and the client should only have a secure interface to use the system. These use cases require a backend. It is significantly harder to gain access to a remote server where the user data is kept. If best practices are followed like ensuring updated backups are created and kept redundant, using end-to-end encryption, etc. then the system can be relatively secure against external attacks.
I wanted a service where I could store my source code (a remote repository), and fully control who has access to the said code (full user management). Gitea 〈gitea〉 seemed like a good choice and I decided to roll with that. This is why I decided to have it as my self-hosted Github alternative.
The documentation for Gitea, unfortunately, is not the most inviting piece of literature ever written. It also expects users to be proficient at managing remote servers and setting up databases so it does not bother to cover the basics. It is detailed, but not very useful; at least I didn’t find it to be so but it could be blamed on my general incompetence.
The guides and tutorials available didn’t turn out to be too helpful either. I was about to give up due to the frustration. Eventually, I came across Ralph’s bogpost 〈ralph-gitea-post〉 on this topic. It was the most accessible and complete resource I could find for Gitea. I even made sure to follow his previous tutorial 〈vps-first-steps〉 on setting up a remote VPS to make sure that I had a solid foundation to build on. Barring a few mistakes on my part, the process went on fairly smoothly. After a few hours of effort, I finally had a (almost fully) working self-hosted instance of Gitea! Thank you, Ralph! 😄
I Forgot About Cloudflare - Again!
I say “almost-fully working” because I was having some trouble pointing my sub-domain at the IP address of my Gitea instance. The instructions were simple: add an A record that maps my requested sub-domain to the IP address of my VPS. I tried that on my webhosting provider’s panel. Nothing happenned. I waited for a few hours. Again, no success. I tried it a couple of times but was beginning to get frustrated again. So I sent a tech-support request to my provider about this issue, seeking advice. The timing couldn’t have been worse. Because soon after that, I had an epiphany: my website is managed by Cloudflare! I dashed over to the Cloudflare dashboard, added the appropriate record for the sub-domain, and then the website seems to be working. I was excited! I tried SSH-ing into the server and… nothing.
Cloudflare is overprotective - it proxies the contents of the website to a CDN, which is exposed to the public. Or at least that’s what I understood from what I’ve read. Hence, users can request for pages and resources from the CDN, but they cannot SSH into it. The solution is to turn off proxy-ing for the sub-domain concerned and only allow DNS. 〈cloudflare-ssh〉 After that, I was finally able to access my remote VPS through the sub-domain address.
Oh, and also, I thanked my web-hosting provider for their quick reply and informed them that I had managed to solve my problem.
After a few more configuration tweaks and learning a couple extra tricks, I am now in possession of an independent Git remote where I can store my Git-based projects and not have to worry about Github or GitLab going down. Additionally, only I can create new user accounts on this instance, thereby restricting access to the projects meant for my Patreon supporters. Specifically, in the Red Apple tier, I’ve promised access to the source code related to my writings that I have not shared publicly. I had been wondering about the best way to implement this, and now I finally have a solution to this requirement!
I feel I’ve learned quite a lot thorugh this little excursion. I have a better understanding of web infrastructure and have a greater appreciation for well-written and complete tutorials. On the whole, I’ve noticed that the amount of frustration I’m facing everytime seems to be lessening. I hope that this is a good thing; that I’m able to understand the system better, and that it’s not just me accepting defeat and moderating my emotional attachment to these projects.
Thoughts on this post?
If you have something to say about this post like expressing thanks, pointing out errors or seeking further clarification, feel free to contact me!
I try to reply within a week. You can find other ways to contact me in the contact page.