From b9f1acb2e3eb12c4847e5f8486e156923b3d556e Mon Sep 17 00:00:00 2001 From: Physick <96335032+DegustatorPonos@users.noreply.github.com> Date: Wed, 25 Mar 2026 15:26:28 +0500 Subject: Git selfhost article --- GitSelfhost.html | 106 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 GitSelfhost.html (limited to 'GitSelfhost.html') diff --git a/GitSelfhost.html b/GitSelfhost.html new file mode 100644 index 0000000..f63bc6b --- /dev/null +++ b/GitSelfhost.html @@ -0,0 +1,106 @@ +

Selfhosting a git GUI server

+

+All good things must come to an end. The carefree childhood, that one ramen you used to buy but they don't make anymore. So did +github - over the time it turned from a developer-first platform with great QoL things like CI/CD through actions and web-based +merge conflict resolution to AI trashcan that dies way too often for a glorified SSH file storage (saw a screenshot recently - +they are barely holding on a single 9 in service uptime) and charges you to give them your code to train the worst agent on market +. I have had enough of this a long time ago but only recently found time to host something personal to replace it. +

+

+Well, not exactly. The old PC I plugged into internet permanently has served me my bare repositories for more than half a year +now but it wasn't particularly easy to use. The main issue was that you would have to SSH into the server to watch the repository +list. The other issue was that I couldn't watch my commit history without cloning it and typing git log. Despite that, I kept +using it alongside github until I noticed that I didn't want to use my git anymore due to pure inconvenience. That's when I +decided to stop being lazy and host something.

+

The many routes

+

+While doing research I encountered a couple of many modern contenders: +

+ +

+Out of presented options Gitea is a clear winner for my insane 8gb server. So naturally I chose CGit.

+

CGit

+

+Gitea is great when you want to own a fully featured system many users can use. Thing is, no one cares about my personal git, so +why would I waste computational power on something not a living soul would use? CGit +was an obvious winner - lightweight, minimalistic and customizable alternative. The only issue is that documentation for it is a +disaster.

My server runs arch linux (btw). Naturally, the first thing I do after checking out their repo is googling +'cgit arch' and get this page. . The order of execution is quite convoluted +in the article. First it tells you to download cgit, then choose a web server, then download a wrapper, then configure CGit +itself. I always use Nginx the first opportunity I get so I jump to its configuration. The second fun part is that it doesn't +work out of the box. The instructions are wrong - you have to search for the files to feed it to cgi-bin (yes, it's that breed +of software) and add them manually. Also they forgot the path to the static files so you have to find add it yourself. All in +all, I got this config: +

+
+worker_processes 1; + +# Load all installed modules +include modules.d/*.conf; + +events { + worker_connections 1024; +} + +http { + include mime.types; + default_type application/octet-stream; + sendfile on; + keepalive_timeout 65; + + server { + listen [internal port]; + + root /usr/share/cgit; + try_files $uri @cgit; + + # This has to ba added and altered to use static files + location ~* ^/(cgit.(css|png|js|svg)|favicon.ico|robots.txt|cgit_bak.css|(switch|search).svg) { + root /usr/share/webapps/cgit; + expires 30d; + } + + location ~ /.+/(info/refs|git-upload-pack) { + include fastcgi_params; + fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend; + fastcgi_param PATH_INFO $uri; + fastcgi_param GIT_HTTP_EXPORT_ALL 1; + fastcgi_param GIT_PROJECT_ROOT /srv/git; + fastcgi_param HOME /srv/git; + fastcgi_pass unix:/run/fcgiwrap.sock; + } + + location @cgit { + include fastcgi_params; + fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi; + fastcgi_param PATH_INFO $uri; + fastcgi_param QUERY_STRING $args; + fastcgi_param HTTP_HOST $server_name; + fastcgi_pass unix:/run/fcgiwrap.sock; + } + } +} +
+

After that it required a config file that was relatively easy to write (somehow `man cgit` is good despite the rest having +close to no documentation) and after an hour of tinkering it finally came alive. The next logical thing was to customize it.
+The customization is fairly straightforward - you just create a single CSS file and replace the default one with it. By default +cgit looks for the static files in /usr/share/webapps/cgit (good luck finding that) and if you put files there it will gladly +eat it up. The default CSS provided by CGIT is also there. I spent an evening trying to make it look like my website and while +I'm not too happy about the result it will do. The configuration for the server you can find + here +

+

Afterthoughts

+At the time of the writing 10 days have passed. By this time according to my meter I've successfully surpassed microsoft's +uptime (around 97% vs 91% at GitHub). I understand that it might not be a valid comparison due to the lack of features and users +at my server but the fact that I'm in charge of what happens and when my server is online comforts me. I can also access it +locally if I would ever need to. So far nothing has bothered me, every time I push it gladly accepts my code and I don't have to +wait for like 20 minutes to push changes (actual situation I found myself recently into). So yeah, if you have a spare server you +should absolutely look into doing the same. I am not that delusional and I understand that not everyone can easily pull this off +so I won't propagate selfhosting here but if you were doubting about it selfhosting your infrastructure as an independent person +is 100% worth it. +

-- cgit v1.3