Hey Reader,

​

You may have seen the drama around self-hosted GitHub Actions runners.​

Quick recap: GitHub wanted to start charging for self-hosted runners.

This had a massive backlash on social media, and they decided to temporarily reverse that decision.

For the time being they are still free, but the message is clear: this will not be free forever.

I promise I’m not some kind of seer. But two weeks before this, I decided to start self-hosting my own Git server.

I had it on my Homelab Wish List for quite a while and finally took the plunge.

So when this news came out, I had a very satisfying “Pah, I outsmarted you” moment.

In this newsletter I will share the tool I ended up using, why, and some thoughts about platform independence.

What is a Git server?

To give you some context, what are we talking about here?

You may know about GitHub. Many people think that Git is equal to GitHub, but that’s a big misunderstanding.

Git is the tool created by Linus Torvalds to manage changes and versioning of source code.

GitHub is a place where your Git repositories live, and where you can host your CI/CD pipelines with GitHub Actions.

GitHub has become the de-facto standard for open source work because it has a huge user base and many large projects are on it.

For example, the Kubernetes project is being developed on GitHub.

But there are alternatives to this. Gitlab and Bitbucket are some of the alternatives that are commonly used at companies.

Taking Gitlab as an example, they offer a hosted solution similar to GitHub, or you can self-host your own instance of Gitlab and have everything running on your own infrastructure.

This is useful for companies who want to keep their code on their own local network for data privacy reasons.

Self-hosting Alternatives

The main one I had on my list was Gitea.

But when I embarked on this project, I researched the alternatives.

I considered Gitlab, but found it was overkill for my use case. Gitlab is a full-on enterprise tool.

All I needed was:

• Hosting git repos
• Running actions
• Mirroring git repos from GitHub and other sources

Fun fact: you don't even need a full-blown tool like Gitlab or Gitea to host Git repos. All you need is SSH.

You can check this video to learn more, it's really cool.

But since I wanted to run my CI/CD pipelines for building and testing images, I needed something more than that.

Gitea checks all of these boxes, but when I dug a bit deeper, I discovered some things there too.

Gitea started as an open-source project but was acquired by a company which now also offers a managed solution for Gitea.

This is a common pattern you’ll see in open-source software and I have nothing against that.

But I wasn't really happy, so I kept on digging.

Forgejo

But then I discovered Forgejo, and it appealed to me more.

Forgejo started as a fork of Gitea but will always remain fully free and open source.

It’s being used to host Codeberg, a non-profit community effort that provides free Git hosting for open source projects.

Think of it as a middle finger to corporate platform lock-in.

I chose Forgejo because of its emphasis on being free and open source forever, and because it works with most GitHub Actions workflows with minimal changes.

Also, there is even interest from the Dutch government to use it, so I genuinely think it can be a good bet to learn and to have this on the CV as well.

What I Do With Forgejo

I now run my personal repositories on it, including my blog.​

When I push code, an Action builds the container image, pushes it to my private container registry (also in Forgejo), and my cluster picks it up automatically.

The Action also runs as a self-hosted runner on my Kubernetes cluster.

Full GitOps pipeline running entirely on my own hardware.

But the feature I love most is mirroring.

I can point Forgejo at any GitHub repository and it will automatically pull in the latest changes.

If a maintainer ever makes that repo private, I still have my own complete copy with full commit history.

Try It Yourself

Want to take it for a spin? One Docker command is all you need:

​
docker run -d \
--name forgejo \
-p 3000:3000 \
-p 2222:22 \
-v forgejo-data:/data \
codeberg.org/forgejo/forgejo:13
​

Open localhost:3000 in your browser and you have your own Git server running.

Create a repo, push some code, set up a mirror. See how it feels.

​

Forgejo in Kubernetes

Now, I run my Forgejo on Kubernetes in my homelab.

Getting it production-ready was not easy.

Docker-in-Docker, network policies, non-root containers, self-hosted runners on a separate cluster…

It took real work to get it right.

But this is the same homelab setup my students use to land job offers every week.

This homelab is not a project you do for fun. It becomes the project on your CV that proves you can do the work of a DevOps, Platform or Infrastructure engineer.

My students are landing jobs because of this project all the time.

If you want to land a 6-figure DevOps job by learning to build this enterprise-grade homelab:

​>>> Click here to apply for KubeCraft <<<​

​

​

​

​

KubeCraft also includes the plug-and-play manifests to run Forgejo in production on Kubernetes.

​

​

If you’re tired of platforms changing the rules on you, I strongly recommend checking out Forgejo.

It’s lightweight, familiar for GitHub Actions users, and genuinely community-driven.

​

Talk soon,

Mischa

​

P.S. We’re accepting 10 new students into KubeCraft this month. You need to move fast. CLICK HERE to claim your spot before they’re gone.