skip to main content

Give Up GitHub!

published icon  |  category icon software

tags icon open source self-hosted

Give Up GitHub!—a clear message that the Software Freedom Conservancy started spreading to open source software (FOSS) developers on 29 June via https://giveupgithub.org. Why? The whole story is available on their website, but the gist is that recently, GitHub yet again proved that they don’t really care about FOSS, or about the privacy or licensing choices of their users. Their newest product called GitHub Copilot is “trained on billions of lines of code, GitHub Copilot turns natural language prompts into coding suggestions across dozens of languages.”, as the landing page suggests. That is, they used your code, with or without your consent, and while it used to be FOSS, now it’s converted into a closed-source product you have to pay for. If you have a repository hosted on GitHub, I urge you to read what the Conservancy has to say about this.

I presume many of you have looked into leaving GitHub after the Microsoft acquisition in 2018. I did so too, but it was too hard, I wasn’t in that place yet, and didn’t possess the needed knowledge of tools that could make the transition easier. I do now (a bit more), and after encountering the giveupgithub.org link at several places last week, I finally made an effort.

I left GitHub. The result is https://git.brainbaking.com/.

It’s far from perfect, and it’s not GitHub. The problem is that GitHub has become ubiquitous for git—our computing students think that GitHub is git, while the power of it lies in its decentralizing capabilities, not its centralized ones. Still, GitHub has steadily added layers upon layers of superb user experiences such as:

  1. A pleasant web-based UI to work with;
  2. A boatload of repo-based statistics built-in with little effort to add more;
  3. A boatload of yearly global statistics on popular tools, frameworks, and languages;
  4. Continuous Integration (CI) capabilities;
  5. GitHub Pages that can serve static websites;
  6. Artifact release repositories with automatic storage;
  7. The possibility to financially support repo maintainers;
  8. Tools upon tools upon tools, such as GitHub Classroom which I do use for lab assignments;
  9. Above all: a vibrant community.

What are the alternatives? There are a couple of viable options, but none of them offer everything GitHub has to offer (for “free!” if we forget that both our usage and code data is being processed for profit). GitLab is the main competitor to GitHub and is another “enterprise-level” heavyweight that aims to provide as much functionality as possible. I have limited experience with it, but I’ve encountered many rants of other users complaining about the speed and amount of weird bugs. Without self-hosting such an instance, in a few years, it’ll become the next GitHub, so no thanks.

Source Hut is a “hacker’s forge”, they claim—the next Source Forge, yay! Remember what happened with Source Forge? It suddenly went closed source. People fled. It died. Right. Anyway, Source Hut seems to come with a lot of interesting features such as powerful CI features, including SSH access. What’s more, it doesn’t require contributors to register an account. Patch reviews and issues can be discussed using mailing lists. As for where it’s hosted: somewhere in the US, sr.ht is a LLC. I’m all for mailing lists when interacting with hundreds of developers, but for my own small projects, it seems overkill, and the UI is less intuitive than Gitea-clones.

Codeberg is essentially a Gitea-powered hosted solution that welcomes free software and is a German non-profit organization with servers hosted in the EU. At the moment, CI integration—one of the prime reasons for me to lean towards a hosted solution—is very wonky and based on a fork of Drone. What eventually turned me to other solutions is the weird https://join.codeberg.org/ page where “dues” (financial membership support) have to be selected. I don’t mind paying at all but that page feels confusing (read: amateurish) and if at the time of writing Codeberg offers little extra besides a Gitea instance, I’ll pass.

Gitea is “Git with a cup of tea”, or “a painless self-hosted Git service” (there are hosting options available). It’s essentially a single binary that’ll get you setup in no-time, provided you choose SQLite as your back-end database (again, other options are available). THe UI is obviously inspired by what GitHub does. The downside is that Gitea is a Git server coated with an easy-going UI—it’s not a statistic generator, CI server, artifact repository, … So yeah, I do miss that: now I have to install a Drone instance that builds and runs my Go tests.


I have two Gitea instances running: one on our internal NAS, and one on our external VPS. I initially didn’t want to install a second one but the VPS needs git access to my sites as part of the build workflow. The VPS is essentially a web server, not a source code or integration server, and mixing responsibilities is never a great idea. Yet it still had ample juice left and since my projects are neither rocket science nor very popular, I figured I’d spin up a second Gitea instance. It currently holds about 820 MB on data, which is still manageable to backup. A tarball is pulled weekly from the VPS into the NAS—that’s good enough, as most important repositories are checked out anyway on different computers here.

The biggest downside of giving up GitHub—and especially self-hosting—is that you’re essentially leaving (yet another) social media. How are potential contributors going to find you? GitHub is explored, scoured, and rummaged through daily. Source Hut and Codeberg are doing their best to build a community. Federated Gitea systems do not exist1, and by that I don’t mean the git protocol itself.

Suppose you want to create a new issue on my Go-Jamming repository, at https://git.brainbaking.com/wgroeneveld/go-jamming/issues. You press “New Issue” and are redirected to the sign-in page. But I don’t want you to create an account, and you’re likely to pass up on that too. After a bit of config file fiddling, I managed to enable OAuth2 and “Sign In With GitHub”. That way, you can simply use your existing account to interact with my source repositories, even if those aren’t hosted on GitHub anymore. Behind the screens, Gitea automatically creates a user in its local DB and links your GitHub profile to it.

It required the following alterations in /etc/gitea/app.ini, after scanning the Configuration Cheat Sheet:

[service]
REGISTER_EMAIL_CONFIRM            = true
ENABLE_NOTIFY_MAIL                = false
DISABLE_REGISTRATION              = false
ALLOW_ONLY_EXTERNAL_REGISTRATION  = true
ENABLE_CAPTCHA                    = false
REQUIRE_SIGNIN_VIEW               = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = false

[admin]
DISABLE_REGULAR_ORG_CREATION = true

[repository]
MAX_CREATION_LIMIT = 0

[oauth2_client]
REGISTER_EMAIL_CONFIRM = false
ENABLE_AUTO_REGISTRATION = true

[openid]
ENABLE_OPENID_SIGNIN = true
ENABLE_OPENID_SIGNUP = true

Then, add an Authentication Source in your Site Administration panel (type OAuth2, protocol GitHub), and register a new app at https://github.com/settings/applications/new to acquire a Client ID and Secret. If you carefully follow the instructions, it should work out of the box, provided the above oauth2_client settings were added.

Another thing I modified was increasing the maximum upload size:

[attachment]
MAX_SIZE=5000

That alone won’t cut it if you’re using Nginx as a reverse proxy: also add client_max_body_size 50M; in-between your server {} definition. This allowed me to upload a release binary, like Go-Jamming v2.0.2 at https://git.brainbaking.com/wgroeneveld/go-jamming/releases/tag/2.0.2. GitHub does this automatically based on CI Workflows. There’s an API available, but I haven’t set up a CI just yet. I wonder if it’s worth all that trouble (and extra load) for just a few small repos. Ideally, I’d hire another VPS to separate web server from CI/Git server concepts. Again, we’ll see.


Migrating the repositories themselves was dead easy: git remote set-url origin ssh://git@brainbaking.com/wgroeneveld/go-jamming.git and git push. Done. (Don’t forget to adjust custom SSH ports accordingly) I chose to be radical and deleted a lot of older repositories at GitHub and archived the more popular ones with a link to the new URL. For me, there’s no need to add a second remote URL and work in mirror mode.

I guess it’ll be up to me now to promote my own coding work, instead of letting GitHub/Microsoft do that. Oh noes, all those lost stars and followers! What shall I do?

Yo check it out: https://git.brainbaking.com/. Contributions welcome!

Addendum 21:26: Mykal Machon hacked my Gitea instance! I seemed to have forgotten to disable repository/organization creation for new users (that are created via the OAuth sign-in). What a nasty surprise, thanks so much Mykal for reaching out! The solution was found in this Can new users be restricted to issues only? forum post.


  1. Apparently, it’s being worked at, nice! I’m really happy to see that many cool things forthcoming. More support for importing repository data from an exported GitHub data blob is coming as well, making it possible to host the Gitea source code on… Gitea! ↩︎

I'm Wouter Groeneveld, a level 36 Brain Baker, and I love the smell of freshly baked thoughts (and bread) in the morning. I sometimes convince others to bake their brain (and bread) too.

If you found this article amusing and/or helpful, you can buy me a coffee - although I'm more of a tea fan myself. I also like to hear your feedback via Mastodon or e-mail. Thanks!