some thoughts on installing sr.ht (and why you may not want to).

TL;DR: installing and configuring sr.ht (especially from source) is a time-consuming process, requires maintenance of its own, and requires you to embrace some philosophies that you may find dealbreaking. YMMV.

hey, folks. it's been a really long time since my last post (not surprising). I think it may be worth a quick intro - I've been trying to find a self-hostable Git solution that I could spin up to internally store projects that I'm working on and/or am only prototyping.

I've known about sr.ht (or more specifically, its hosted version SourceHut) for a while, but never really thought to try it out until now. it bills itself as a privacy-friendly alternative to GitLab and GitHub that also happens to be somewhat modular - that is, you can elect to install specific components like Git or todos, and all of these components can interact with each other or standalone. another selling point is the fact that none of these services require JavaScript to run, which can be a boon for those who don't enjoy it. (my apologies in advance to those of you who block JavaScript and have to enable it for this site.)

there are repos with prebuilt packages available for Debian (not Ubuntu), Arch Linux, and Alpine Linux, but chances are that you'll end up needing to configure things outside of this. if you, like me, are running Ubuntu or something outside of those distributions, you'll pretty much need to compile everything from source. with that said, let's begin.

part 1: onions sr.ht has layers.

to give credit to the sr.ht authors, the project itself is currently (as of the time of writing) in an alpha state, despite being stable enough for many use cases. the installation documentation reflects this, but even so there's still some key details (in my opinion) left out that make this process more arduous.

none of the immediate prerequisites listed on that page should be any concern to even new users (not even Redis), but parts of the build processes also leverage node's npm (so much for JavaScript-free??) to fetch some packages, compilation of Go source code, and Python modules that need to be supplied by your distribution rather than through pip.

it's not as obvious to know where to begin besides that. the core.sr.ht and meta.sr.ht packages are absolutely essential for anything else to work, but it can feel very daunting to know where to grab the source code to put each layer together. (some services, like the git.sr.ht service you're likely reading this to figure out how to install, may also require some other packages like scm.sr.ht to function on top of this.)

what this means, dear reader, is that you need to successfully build and configure the following services in order to be able to have a self-hosted sr.ht Git server up and running:

• core.sr.ht (shared libraries & other things for all sr.ht services)
• meta.sr.ht (authentication system for sr.ht services)
• scm.sr.ht (shared libraries for sr.ht version control systems)
• git.sr.ht (the Git-specific functionality for sr.ht)

to start, you will want to create a working directory to hold each project, then run the following commands in order:

• git clone https://git.sr.ht/~sircmpwn/core.sr.ht --recursive
• git clone https://git.sr.ht/~sircmpwn/meta.sr.ht
• git clone https://git.sr.ht/~sircmpwn/scm.sr.ht
• git clone https://git.sr.ht/~sircmpwn/git.sr.ht

(the reason --recursive is used in the first clone is because Bootstrap is pulled in as a dependency; meta.sr.ht and other packages will not build successfully without it.)

also!! if you haven't already, make sure to grab libpq-dev, sassc, and basically anything else listed as a dependency (it's a massive list) through apt and not pip; you'll get build errors if you don't. you may wish to peruse the source tree of the officially maintained Alpine apkbuilds repo, as the requirements should be up to date there (their words, not mine).

once you've done this, you may be tempted to run sudo pip install . in each of these folders - but I promise you, this is not the way to go here. you'll likely run into issues, and you will earn the displeasure of the developers. you'll want to run sudo setup.py install --install-scripts /usr/bin instead. here, --install-scripts essentially makes sure that scripts like srht-keygen and metasrht-initdb are placed in the right folder so that they can be called by both you and the systemd services we'll be setting up later.

from my experiences, two Go binaries were built, but not installed into /usr/bin; run sudo install api/api /usr/bin/metasrht-api in the meta.sr.ht folder and sudo install api/api /usr/bin/gitsrht-api in the git.sr.ht folder after the Python build scripts complete to manually accomplish this.

part 2: so. much. configuration.

now that you hopefully have these components installed, it's time to create a config.ini file. make sure to create it in the /etc/sr.ht directory, and consult the repositories of the meta and git (and/or other) components as needed. some of this is well documented, but parts will require you to have meta.sr.ht up and running to generate the right authentication key.

also, make sure to set up cron jobs/systemd services. this part was probably the most daunting for me because of the inconsistency in the python build process, where the end results of the build process dropped files into /usr/local/lib/python3.8/dist-packages/metasrht-0.58.7_1_ga8bbf84-py3.8.egg/metasrht for the meta.sr.ht build, but git.sr.ht build artifacts lived in /usr/local/lib/python3.8/dist-packages/gitsrht... and both of these conflict with the reference nginx config files that SourceHut (hosted sr.ht) use in production, which themselves are confusing. insert major frustration noises here

for the most part, you can use the Debian package sources as a reference; I implemented the cron jobs as systemd timers to make management easier on my end, but the cron jobs can still be cron jobs if you wish. this was pretty much a copy/paste job for most of them.

don't forget to use SSL certificates - certbot certonly did the trick nicely. as for setting up the nginx server config files, symlink meta.sr.ht.conf and git.sr.ht.conf into your sites-enabled folder and leave the rest in /etc/nginx.

(I really thought I was going to be more guiding folks through an installation while starting to write this post, but in retrospect, this is more of a rambling.)

final thoughts.

I really like sr.ht on a fundamental level - open source, modular, and no JavaScript needed. SourceHut is also in a valuable space as an alternative to proprietary solutions like GitHub and Bitbucket (and even open source platforms like GitLab), and they're in a very good position financially speaking. the UI is simple, yet perfect, and the lack of JavaScript seems to benefit it in terms of performance and speed. (that said, for anyone who's asking how it affects memory, I'm seeing from systemd-cgtop -m that the API, webhooks, and primary webserver services take up a total of ~500 megabytes of memory and very little CPU (if any) while idle^[1], but do keep in mind that this isn't accounting for overhead incurred by redis, the PostgreSQL database, the resources used by the ongoing maintenance scripts triggered by timers/cron jobs, or anything under normal usage.)

also, when I went to add my SSH key in the meta.sr.ht account settings, I received an error that leaked my PostgreSQL connection string; I'm chalking this up to a bug with the underlying SQLAlchemy library not being able to fully account for passwords with special characters in them, but who knows^[2].

in summary: this is not for the faint of heart. expect to spend a lot of time installing, configuring, and maintaining this system. if this bothers you, consider creating an account on SourceHut and possibly financially supporting or otherwise contributing to the project, or try another self-hosted solution like Gitea.