Breaking free from GitHub: the why and what am I using now?

Published: 2026-08-16

In light of recent reliability issues early this year, I’ve joined the bandwagon migrating away from GitHub. In my search for alternatives along with my evolving needs for what a git platform provides, I’ve come to the conclusion that I don’t want my projects to be locked into similar monolithic ecosystems like what GitHub offers.

The biggest pain point has been encountering points where issues with one service can often cascade into availability problems across entirely separate functionalities. At a certain point, having more features doesn’t feel as critical; I need the separate parts to be more available and decoupled from one another.

With that in mind, I’ve used moving away from GitHub as an opportunity to craft my own software development lifecycle stack catered towards my needs. My goal, has been to choose solutions that work well together, but ultimately can function independently.

Beyond the basic repository

Building complex projects (especially those using languages like Rust or Nix) can be time-consuming; managing these long build/compile cycles requires robust support systems. And that brings up some key technical considerations:

Self-Hosted CI/CD: While GitHub Actions are convenient, I’ve limited myself sticking with the free tier. Given my access to a few competent servers via my homelab setup, utilizing a self-hosted CI/CD solution made far more sense.
Caching and Artifact Management: To accelerate slow builds, I needed the ability to implement binary caches that can be used by or dumped into the CI/CD pipeline. Furthermore, artifact storage limitations (particularly when dealing with images built for deployment) required a dedicated infrastructure solution beyond what the free tier could provide.
Git hosting: None of these software development niceties would be possible without a git platform to to pull the code from! Ideally, it would be used only for git hosting, and therefore a minimal solution was something I preferred.

What I’ve landed on

From the get go, Forgejo stood out for its simplicity and lightweight nature; it’s effective for git hosting without demanding excessive resources. But ultimately I elected Codebreg to be the new home for my code. This choice was motivated by the fact that Codeberg is a custom deployment of Forgejo. This let’s me keep git hosting simple but takes the burden of disaster recovery off my plate. Git hosting is mission critical: artifacts can always be rebuilt, caches aren’t meant to be long-lived, but without the code there’s nothing to build on.

To support this move, and after some experimentation I’ve landed on using this stack:

Woodpecker CI: A platform agnostic CI runner. A standout feature is its Kubernetes integrations allowing you to declare pod resources and scheduling from the workflow configuration!
Harbor Container Registry: Feature rich with automated security scanning and some robust artifact retention policy options.
Attic: simple to use self-hosted Nix binary caching service.
Garage: S3 compatible object storage backing both Harbor and Attic. Very useful for a host of other projects as well!

Looking at the future

While exciting, its not all sunshine and rainbows, and my implementation of my services still has some room for improvement. Self-hosting my own infrastructure is pretty freeing, but it comes at the cost of scaling and maintaining it myself. As I mentioned, disaster recovery has yet to be considered and I’ve only got the repositories covered. Maybe once I block out some time to a look at my options, I can make the leap and have the confidence to host Forgejo myself.