Table of Contents
I recently decided to move my projects from GitHub to Forgejo. This post captures the reasoning behind that choice and what I hope to gain from it.
Plenty of creators have already covered reasons to leave GitHub. Here are a few good ones, better than anything I’ll add here:
- Wolfgang has a very comprehensive blog post (he also has a killer YouTube channel)
- Primeagen discusses how bad GitHub Actions are
- Theo takes on the new pricing model for self-hosted GitHub Actions
Why I Left GitHub
The last straw was GitHub announcing they would charge for self-hosted GitHub Actions runners. The outcry from the dev community was immediate, and they have since postponed the change.
Still, I think it shows that Microsoft does not have developers in mind when it makes platform decisions. Microsoft takes GitHub’s dominant position for granted and does not seem to prioritize developer experience.
An additional point to support this is Microsoft’s lazy approach to maintaining Github Actions. This can be seen with the safe_sleep.sh script in the Github Actions runner codebase. This script is used to sleep for a period of time but sometimes gets stuck looping, charging developers for each minute of sleep time when the runner is doing nothing. That same article also documented the series of events.
Here’s a timeline of the issue and fixes:
- Issues from high CPU usage due to this script were reported as early as 2022.
- A pull request to fix it was submitted in February 2024, but it was automatically closed by a bot without any explanation.
- An issue documenting the infinite hang was reported in April 2025.
- The original pull request to fix the script was merged in August 2025.
- An additional PR suggesting alternative solutions was merged in December 2025.
Leaving a well-documented problem unfixed for that long is hard to excuse, especially one that stretched runtimes and wasted CPU. To me it suggests lack of competence, indifference toward developers, a profit-first mindset, or some mix of the three.
Those are the main reasons I wanted off GitHub. I also do not rely that heavily on its workflows. I do not heavily collaborate on projects (GitHub is still the default for that), and I have minimal production code on there. I mainly need somewhere to share what I’m building and to host static sites. For that, GitHub is far from the only option.
Why Forgejo?
For self-hosting a GitHub alternative, I really only saw three viable picks: Forgejo, Gitea, and GitLab.
GitLab is full-featured and ships a lot of tooling. That also means noticeably more overhead than Forgejo or Gitea. GitLab CI/CD is syntax-wise different from GitHub Actions, and GitHub Actions-style YAML still feels like the default for CI/CD workflows, so I wanted more practice with that.
That left Forgejo and Gitea. They are very similar because of a shared history. Forgejo forked from Gitea in 2022 after a for-profit company run by lead maintainer Lunny Xiao silently transferred Gitea’s trademarks and operations to that company and began pushing an open-core model. Forgejo, by contrast, is maintained by Codeberg.org, a non-profit focused on promoting open-source software.
Taken together, that pushed me toward Forgejo: it matches what I care about and aligns best with an open-source-friendly model.
VPS vs Self-Hosting
I initially considered self-hosting Forgejo on my own hardware. However, I decided to go with a VPS for a few reasons:
- A VPS sits on a separate network with its own public IP, seperate from my home LAN, which is a real security win.
- I get more exposure to “cloud” infrastructure. The gap versus a self-hosted AlmaLinux 9 box may be small, but I still want more hands-on cloud experience.
I ended up on IONOS for the VPS, with AlmaLinux 9 as the OS and Cloudflare for DNS.
I picked AlmaLinux 9 because it is an open-source alternative to RHEL that tracks RHEL well and fits a VPS nicely. Experience on a RHEL-family distro matters to me (it’s what I often see in production), and skills I build on my own projects might transfer to an enterprise environment later. If I can do both at once, that is a win.
Security Considerations
I was somewhat concerned about exposing a VPS to the internet. I also do not want to point people toward sloppy security. At the same time, some hardening steps add real implementation overhead. I focused on the highest-impact pieces instead of chasing every detail.
- SSH allows only key-based authentication.
- The firewall blocks traffic to ports I do not need.
- TLS encrypts traffic to and from the VPS.
Here are some other security features that I considered implementing but I did not.
Cloudflare offers proxied DNS records so it can absorb DDoS and other network-layer attacks and hide your host’s origin IP. I may add that later. Proxied records come with extra headaches for nested subdomains like jackwaterloo.pages.jackwaterloo.com; proxying those can require a Cloudflare Business plan. Proxied DNS also complicates my Forgejo host at git.jackwaterloo.com, where I use SSH to clone repositories. I would need to set that up to work with proxied mode. That was more than I wanted to tackle for my initial setup.
Fail2ban is a service that can be used to ban IPs that are making too many authentication requests. This is useful for blocking brute-force attacks. I have ssh running on the default port 22 and only have key-based authentication available. This is secure enough for now. If the amount of ssh requests starts to become a problem, I will revisit Fail2ban.
Final Thoughts
For now, this is the shape of the move: Forgejo on a VPS, security basics in place, and a platform that fits how I use Git today without the baggage I was trying to leave behind. After I’ve lived with it for a while, I’ll know what still needs tuning and whether switching was worth it.