I Said Goodbye to GitHub...

Contents

• Why Leave, and Why Now?
• Searching for Alternatives
• Self-Hosting Forgejo & Code Migration
• Farewell, GitHub

Why Leave, and Why Now?

So yeah, I’ve succeeded in a near complete migration away from GitHub after 14 years of usage. I started learning to code in 2011, and first joined GitHub in February of 2012… since then, it has been the central repository for all of my development work. I’ve used it for every single professional and side project, and as my life and career continued to grow and evolve, I still used GitHub. That is, until last week.

A few clarifying points, since I’ve encountered some of this already or anticipate some misunderstandings:

• I am not stopping my usage of git, but the website and hosting platform known as GitHub. My actual version control process isn’t changing, just where and how it is hosted.
• I am not advocating that you or anyone else should do the same.
• I will not be completely deactivating my account. The vast majority of open source software still lives there, and if I need to open up an issue or interact with maintainers, it’s going to be the best way to do so. Unfortunately, there is a lot of momentum and staying power.

With that in mind, why did I choose to leave GitHub, and why now?

Back when I was in grad school (~2018), Microsoft moved to acquire GitHub. This was during a time where Microsoft was generally trying to improve public perception of its support of open source, and was marketed and editorialized as their commitment to open source continuing. I remember at the time expressing a cautious optimism. I grew up in an Apple household, but aside from not liking the Windows operating system, I didn’t have much experience or reason to outright dislike Microsoft. My advisor, on the other hand, was far more skeptical. I don’t remember his exact words, but the expressed sentiment was clearly that this would eventually go wrong. It took some time, but unsurprisingly, my advisor was correct.

GitHub has become unstable at best. Lots of down time for various services, but the worst offender was GitHub breaking the sacred promise: we won’t break your code, and we don’t break git. On April 23rd, there was a bug with merge queues and squash commits on pull requests. In short: it erroneously and silently overwrote people’s code by merging the wrong commits without notifying the user. You can read more in GitHub’s official writeup of the incident, but regardless of the cause or the efforts to prevent it again, the trust has been breached.

Now, consider the GitHub breach of trust within the context of the broader issues facing Microsoft and the current technological landscape. Windows 11 sucks and is absolutely stuffed with borderline spyware, always-online account functionality, and just terrible user experience. They tried to force the absolute worst of the current AI industry into their products and operating system with Copilot. They tried to create a spyware system that screenshots your computer every 30 seconds and stores it for LLM access, initially doing so in an unencrypted and insecure way that was a security and privacy nightmare. I had ditched Windows for my home desktop and been daily driving Fedora Linux for years now, but I wasn’t going to miss an opportunity to further de-Microsoft my life. These incidents were really just an excuse I barely needed.

Beyond the general loathing of Microsoft, there is also the ever growing hunger for corporations to greedily harvest and devour every ounce of data they can scrape from you and eventually sell or use to train an LLM. In this landscape, I am increasingly interested in self-hosting and owning my own data (even if it still ultimately gets scraped by the mere act of being online). I created this blog as a replacement for social media, wishing to further unplug from platforms like Twitter and Facebook. The code was written from-scratch and uses server architecture in a way that I am not beholden to any one hosting provider and can migrate effortlessly. Why not do the same for my software infrastructure as a whole? Besides, I am a tinkerer at heart, and self hosting a GitHub alternative sounded like a great project that fulfills many personal goals. So, I set out to do just that.

Searching for Alternatives

For my work at SPC, all of our official code and work is technically supposed to be done using the official NOAA VLab hosted GitLab instance. I had moved most of my work code over there already, but there were some stragglers or non-critical projects that had yet to migrate. So, my first instinct was to potentially self-host GitLab. I could be consistent with what I use at work, and it would generally meet the goals of the transition. However, I was concerned that by moving to GitLab, I could just be punting down the road several years, only to end up at this same spot if someone else acquires GitLab. So, while a perfectly viable option and one you could easily pursue if you were interested, I wanted to dig further.

I ultimately settled on Forgejo as what I was looking for. It’s free and open software with open communal governance, extremely lightweight and can run on minimal hardware specs, appeared easy to install and maintain, and had all of the functionality I wanted/needed from a hosted GitHub alternative — including self hosted action runners! Recently, the Fedora Project migrated to self-hosting via Forgejo, and FFMPEG is self hosting Forgejo. All that to say, it’s not just some fad, but something large projects are moving to, which I consider to be a sign of health when choosing a new tool. If you are interested in checking it out without having to host yourself, Codeberg is the official public hosting page. Recently, the Zig programming language made the migration to Codeberg as well.

In this modern era of acquisitions, weak antitrust regulations, and platform capitalism leading to extreme concentrations of wealth, non-profits remain a bastion defending what remains of the commons. - Andrew Kelley

Finally, another reason I was interested in Forgejo is because of its in-progress development towards federation. Federation would mean that interactions between self-hosted Forgejo instances (and Codeberg) could be facilitated. It’s in the early stages, and I don’t have it enabled at the moment, but there are already ways to “star” repositories across hosted instances. Once it reaches a maturity that it allows following developer feeds from across hosted instances, I will enable it. The point being, there is an interesting future for self-hosted repositories that can still interact with each other.

Self-Hosting Forgejo & Code Migration

This won’t serve as a tutorial on how to do this yourself, but I did want to discuss the process and share some resources. I had no trouble following the installation documentation for the binary route. Supposedly, it is even easier if you want to go the Docker route! I ultimately decided to spin up a small/cheap Linode/Akamai Cloud instance (2 CPUs, 8GB RAM, 80GB storage, automatic backups). This seemed to strike the right balance of reasonable pricing and quality/reputability, but my end goal is to eventually migrate away from the cloud hosted instance and go to a fully self-hosted machine one day. Still, I’m okay with renting the hardware for now while I figure this stuff out.

I set up a reverse proxy using Caddy in order to serve https traffic and automatically handle SSL certificates through LetsEncrypt. I also set up SSH authentication and key signing for Forgejo, and once that was all done, it was time to start migrating code. Ultimately, I set up a GitHub Personal Access Token that was scoped and set to expire rapidly, but would allow for me to migrate repositories, pull request & issue history, wiki pages, and more automatically. I also set up repository mirroring for projects not yet able to leave GitHub (SHARPlib), and then I started deleting private repos from GitHub and archiving the public ones. I also learned how to set up a Forgejo action runner that uses Docker containers to execute CI/CD workflows! So, for example, when I commit and push this blog post to the main branch of my repository hosting this website, it will kick off a Linux action runner that builds and deploys my website to the server automatically. No dependence on GitHub actions, or any 3rd-party action runners. Just my infrastructure, and nothing else.

Farewell, GitHub

So, after a long Friday afternoon/evening following some tutorials, it was time to say goodbye to GitHub. Sure, SHARPlib will still live there for the time being, but I’ll eventually find a way to self host my CI/CD runners for MacOS and Windows. Once that happens, the GitHub repository will just become a public mirror. It’s a little bit sad, walking away from a platform that has supported my development and growth over the majority of my adult life… but the change is good, and I had so much fun learning the process of making this happen. I also feel tremendous pride and joy knowing that this blog post was published straight from my self-hosted code repository to my website, which I also own, maintain, and manage, via the action runner that I control and manage. I own and control nearly every aspect of the pipeline and infrastructure used to make this content, and that is such a cool feeling! I have already updated the “code” and footer links on this website to point to my repository. You can also check out labs.stormscale.io, or my personal developer profile.

If you read this far, thanks for entertaining my thoughts and letting me share something I’m excited about. If you happened to enjoy this, or perhaps you are interested in the idea of hosting code somewhere other than GitHub, I’ve been loosely entertaining the idea of opening up my instance to allow others to host their code too. Perhaps, if there was sufficient interest, it could become a small community hub for developing and sharing code within the atmospheric sciences/meteorology. Probably a bit grandiose of a dream, but, if I know you/have met you in the flesh, and you’re interested in kicking the tires, reach out to me. You can get private repositories for free, and maybe have one less dependency on Microsoft in your life :). At the very least, check out the other GitHub alternatives mentioned here!

Happy coding, and don’t be afraid to own your own data, infrastructure, and don’t be afraid to tinker.