paritybit.ca

Choosing a Self-Hosted Git Service

Author: Jake Bauer | Published: 2020-05-26

2022-09-27 Update: Add Stagit.

2020-05-27 Update: Add Gitolite.

2020-05-29 Update: Add cgit.

2020-09-21 Update: Add Pagure.

Git is by far the most popular version control system right now and there are so many options for self-hosting your repositories it can be difficult to figure out which one is the best for you. In this post, I’ll go through many of the more popular free and open source options with a brief opinion about each and links to where you can find out more. I’ll also explain what I chose for myself and why.

GitLab

GitLab is one of the most popular git hosting services next to GitHub. They operate with an open-core business model which means that core features of GitLab are open source, but many other features are proprietary software.

GitLab’s UI is somewhat similar to GitHub’s and it uses the same Pull Request model for contributing to others’ software projects where you “fork” a project and then submit a pull request using the web UI.

I will get straight to the point with this though. Don’t use GitLab. It’s a bloated mess of a software forge that, yes, has a lot of features, but also has a lot of problems. For example, GitLab has memory leaks which, instead of fixing, they created a duct-tape solution which kills a memory-hungry process and re-starts it. They also recommend 8GB of RAM as a minimum for the application to run smoothly. EIGHT GIGABYTES! I’m running Gitea on a PineA64 SBC and the entire system’s RAM usage is at less than 0.5GB. GitLab is slow, bloated, and definitely not a good candidate for someone looking to self-host a git service.

Gogs

Gogs is a GitHub-like software forge programmed in Go and designed to be fairly easy to self-host. If you have some experience using GitHub, you’ll very quickly get used to the interface of Gogs as it’s nearly identical. It also uses the pull-request method of development and maintains a fairly clean-looking UI.

Just like GitHub and GitLab, it’s a bit heavy on the front-end JavaScript and thus its accessibility and client-side performance suffers as a result. It does provide the features one would want from a software forge such as CI/CD, Wikis, and issue tracking.

It’s easy to host since it’s a single, statically-compiled binary. One just needs to install a backing database, set up some configuration, and run the binary to have a fully-featured software forge up and running. It seems appropriate for anywhere from single-user instances, to medium-sized groups and teams.

Gitea

Gitea is a fork of Gogs hence it looks and feels much the same. The development model for Gitea is more open than the one for Gogs and so it tends to receive bugfixes and improvements faster than Gogs. It’s also a better choice than Gogs if you’re someone who would like the ability to send patches upstream.

In most respects, Gitea looks and functions the same as Gogs though Gitea does have many more features. A detailed list of differences between the two can be found on the Gitea comparison page.

SourceHut

SourceHut is a project created by Drew DeVault and released in public alpha on 2018-11-15 through the hosted instance sr.ht. Since then, it has been steadily growing its user base and feature set. It now includes comprehensive CI/CD and Project Hubs.

SourceHut is unique in that it’s a fully-featured software forge which uses no front-end JavaScript and supports esoteric operating systems such as Plan 9 in its automated build framework. Unlike GitHub and many of its clones, SourceHut does not use pull requests and instead uses mailing lists for everything from bug reporting to sending in patches (though this can still be done through the web UI). The advantage to this is that one does not need an account on a SourceHut instance to contribute. Some might say that the disadvantage is that this workflow is hard to figure out, but in reality it’s just a different development paradigm and doesn’t take much effort to learn. See git-send-email.io for a brief introduction.

It’s important to note that SourceHut is still in alpha and requires at least a moderate level of experience to self-host. It also uses individual, modular services to make up the entirety of the forge. For example, if you want access to mailing lists for your instance, you must host a lists.sr.ht service. This makes the entire system much more resilient in the case of bugs or system failures, but can be challenging for a novice sysadmin or not worth the effort if all you want is a software forge for publicly showing off and working on your own repositories. SourceHut is definitely worth checking out if you want a software forge for a group or team of people.

Phabricator

I don’t have as much experience with Phabricator as I do other services on this list so my overview essentially comes from reading documentation and poking around the hosted instance.

Phabricator is a software forge built by Phacility. It offers the same features as the above-mentioned software forges and is also straightforward to install, perhaps requiring a level of skill in between SourceHut and Gitea if the installation guide is anything to go by.

Similar to SourceHut, this service may be more than you need if you’re looking for a simple way to show off your Git repositories. It is fully-featured and competently developed though so, if you’re looking for an alternative to GitLab for a group or team of people, Phabricator is worth checking out.

Pagure

Pagure is similar to the other software forges mentioned above. It has all the features expected from a contemporary software forge including wikis, issue trackers, releases, and more. From the Pagure home page:

With pagure you can host your project with its documentation, let your users report issues or request enhancements using the ticketing system and build your community of contributors by allowing them to fork your projects and contribute to it via the now-popular pull-request mechanism.

One advantage I can see for Pagure over many of the other options is that both project and user discovery seem to be easier than with other software forges. There are dedicated pages listing repositories, users, and groups with a search bar allowing for the quick and easy discovery of different things on a specific instance.

It also offers several methods for installation: Docker, Vagrant, and a manual installation. The manual installation process is very straightforward and clear from the instructions given.

Gitolite

Gitolite is different from any other Git service in this post; it isn’t a full software forge and doesn’t have a web interface. Instead, it simply provides a way to host many git repositories with virtual users and fine-grained access control. Gitolite is an access control layer on top of git.

Notable current or past users of Gitolite include the Fedora Project, the KDE project, Gentoo Linux, and kernel.org.

This may be what you want if all you’re looking for is a way to host multiple git repositories on a central server where each repository can have mutliple developers. To learn more about what Gitolite does and its supported features, see the Gitolite overview.

Gitweb

Gitweb is the default web interface for Git repositories. It’s essentially a way to view the contents of a repository and its git-related data (commits, branches, blames, etc) using a web interface. It’s not a software forge like the others in this article, but if all you want is a UI to view information about git repositories, then this is a valid choice.

cgit

cgit is a simple web interface for Git repositories. Like Gitolite or Gitweb, cgit is not a software forge and only includes functionality for viewing Git repositories, commit diffs, and the like. It’s basically the same as Gitweb, but noticeably faster when viewing large repositories and with support for caching the generated pages. It may also look better than Gitweb, depending on your sensibilities.

Stagit

Stagit is not really a “service” per se. Stagit generates static web pages based on git repositories which can then be served by any web server. It’s very easy to script, customize, and deploy since the stagit program itself is only used for generating pages, not serving content or handling connections. Stagit can be run as a cron job or using a post-receive hook so that pages get updated whenever a push is made to a git repository. It’s also the lightest option out of all of the entries in this post, since it doesn’t do any dynamic content generation and the static pages it generates are very lightweight.

My Choices

I have since changed what I use to cgit. I outline why in a more recent blog post: Switching to cgit

Actually, I'm now using stagit.

When looking for a self-hosted git service, I was looking for a service that fulfilled the following criteria:

At git.paritybit.ca, I currently host a Gitea instance. Although I would have loved to host my own SourceHut instance, I feel it’s not designed for my use case. I basically just use Gitea to mirror my repositories which are also hosted on SourceHut and to allow a small group of friends to collaborate with me in smaller, private projects. I could probably get away with Gitweb, but Gitea also gives me a playground to experiment with CI/CD and other technologies I may encounter in my career. Gitea was also really easy to set up, customize, and maintain. I use a script, gitea-updater, created by a friend of mine to easily update it too.

As far as hosted services, I use SourceHut’s sr.ht instance because it’s lightweight, straightforward, and I like its email-driven development model. I used to use GitHub and GitLab, but SourceHut performs way better and experiences downtime far less often than the big providers such as GitHub and GitLab.

There are also quite a few more, albeit less popular, free and open source software forges available, many listed in this comparison by Apache Allura. Additionally, check out forgeperf.org for a comparison of the performance of some of the biggest hosted software forges.

Let me know if I’ve failed to mention anything important here or if I’ve missed a software forge you’d like to see mentioned.

This is my thirtieth post for the #100DaysToOffload challenge. You can learn more about this challenge over at https://100daystooffload.com.