Poll: Self Hosting Git Repositories | Hacker News Reader

Poll: Self Hosting Git Repositories

64 pointsgmemstr82 comments

I'm looking to setup a git host to at the very least mirror my git repositories, but more likely to migrate to full time. Suggestions are welcome, but I'm also curious what HN uses!

View on HN

Gitea (originally a fork of Gogs) is moving fast, and they are adding ActivityPub federation support to the software. This will allow you to collaborate with projects hosted on remote Gitea instances (and other software once they add federation support too). If you are working on FOSS then Codeberg [1] is a good Gitea instance, which offer Woodpecker CI and Codeberg Pages.

[1] https://codeberg.org

I believe the Gitea people are also about to add an artifact registry feature.

I run a Gitea instance on my Synology to act as a source for flux2 on the living room Kubernetes cluster. I don't want to have that on Github so it'll all work without internet connectivity (still a WIP though). I had my own Gitlab for a long time but at some point its hunger for resources made it uneconomic for my use case. Gitea does less but in a fraction of the resources.

I've been using gitea for a while now and still recommend it, I just wish they didn't go the gitlab route and started doing everything and the kitchen sink. They would be better off if they just focused on the federation part and let everything else outside of hosting to other specialized tools.

Gitea is love. There are not a lot of shenanigans and it just does the job. If you want vcs with an online interface it's great for personal use and smaller teams.

If you want fancier stuff like integrated CI/CD that is more common out there, Gitlab is an option, but running it by yourself it's not as simple (as gitea), for example.

Gitlab is extremely simple to run yourself. I've been doing it for 2 years at this point. What is really difficult about the operation?

Not really difficult per se, but more of anecdotal experience of needing dedicated time to maintain it internally. In a smaller company a few years back, whenever an update was due we would have some down time after it and someone had to spend a morning checking the server/dependencies/configs, this was around 2016.

Apart from that, a fact is that gitea is less resource hungry, so it runs well even in modest configurations.

same here, gitea for a few years, works great for all my personal git repos. it's essentially my own github/gitlab that runs off one binary.

Was just about to say this, I’m so excited for Gitea to get federation support and think they could really give GitHub a run for their money. I think a lot of major foss projects would switch over to a self hosted instance if it didn’t require users to create an additional account for every instance

if it's for personal use and no access rights are needed, just use ssh.

If you need to add more people, but don't require access right for the git repos (i.e. everyone will be able to force push). Still use ssh, but create a git user and git-shell as the shell to improve security.

If you want to go one step up, I was looking at soft-serve, however it's too immature yet. So I added a git-shell-commands folder and added list command that will list my git repos.

It's really simple!

If you need access rights and reviews, things will be a bit more complicated. Although git-shell seems pretty easy to add some access rules to, if not gitolite is better. For browsing, cgit and gitweb should be obvious choices, however I don't really see the point for a minor site.

For code review, I'm really voting for git-appraise to take off. Once I get a coworker, that's what we will be using.

> if it's for personal use and no access right are needed, just use ssh.

This! I think many people don't realize how easy it is to host git repositories over just pure ssh. I backup all my git repositories this way, and also have a usb disk drive with backups (which is super easy to setup, just add a git remote with a unix path to where you wanna send it). Each repository I have have three remotes (`origin` which is usually GitHub/Codeberg, `ssh` which is my remote backup and `usb` which is my disk drive). My alias `gp` pushes the current branch to all three simultaneously.

Do you mean use VSCode with Remote-SSH and just work on a server?

No I think OP means log in to your server via SSH, ‘git init —bare’ and you’re done. You’re now self hosting your git “server” without any of the tools listed in this poll.

What you are talking about is remotely accessing and working on a codebase. That has nothing to do with repository management.

As mprime1 replied, it's more on the lines of firing up the terminal to create the git repository. Then go back to your local system and git clone/pull the thing. Then you fire up your local VSCode and work on it and then finally push the changes. This way the whole team can work seamlessly and implement CI/CD while addressing conflicts in real time.

What you are talking about is a beautiful way to work on a remote machine (especially the headless ones) but only when you are the single dev. For a team, you gotta go the other way.

Why would this not work for a small team?

Thanx for the explanation, so if you create the repo on the server, can you just got clone server.ip then? How do you clone it? Does that git init —bare command create a server?

git clone teekert@ssh.example.com:path/like/scp

If you also want public access over http you can activate one of the default hooks (so a single "rename a file" command on the server) and then export it using literally any web server software (as it is a folder of dumb files).

Ah! Somehow I was assuming some magic in the cloning, some server-client relation. There is not I guess, and that is actually logical. Also refreshing in a way.

FWIW, I do believe that you have to have git installed on the other side, and what it is doing at an implementation level is using ssh to run a transient copy of the git daemon backed by that path on the remote machine, which communicates over stdin/stdout--and so over ssh--and which implicitly (due to the EOF) dies when the ssh connection dies. Like, I don't think it is accessing the remote side using mere scp/sftp file-system operations or anything (which would be horribly slow for a number of basic operations and would make cleanly running triggers and the such more annoying).

Thanx for this reply!

> reviews

Are you saying that I can self-host and have the same "review" functionality as GitHub when reviewing PR's?

Anything else than GitLab, it's so slow and bloated. With every "update" it seems to get even slower and depend even more on javascript. I really hate how so many open source projects shifted to this abnormation because Microsoft acquired GitHub, I mean, regardless of what evil shit Microsoft could think up, it can't be worse than having to deal with this javascript turd. If your web interface can't even just display simple information like issues page or merge requests, without depending on a huge pile of steaming javascript, you have FAILED in web design. I cry every time I'm forced to use GitLab. Just my two cents.

You may want to give more details about your usecase: do you need _only_ git hosting or other features too (e.g. issue tracker, CI/CD pipelines)? How many users will use this setup? Do you have a dedicated machine or you run it locally (e.g. in a docker container?? Hosting locally or in cloud?

IIRC Gitolite was aquired by Gitlab a while back, Gitweb is not really a git hosting, it's more like a web view of your `git log`

Gitlab needs at least a couple of gigs of RAM to run well, double/triple that if you need CI/CD.

I have no experience wiht gogs/gitea.

This poll is really me being curious about what the citizens of HN use themselves. My own use case would benefit greatly from CI/CD pipelines, but beyond that I'm mostly looking for a nice web interface to expose the repository contents.

Gitlab CI is powerful, and (IMHO/IME) a selling point compared to other options.

In my company CI is pretty trivial. docker build . -t projectname:branchname and push it to the internal registry. For one project I set up additional docker run step to run integration test (it used docker itself so it was not possible to run it at build time which is docker limitation IMO). I remember setting up complex jenkins jobs back in the past, but at this time usually all you need is to build docker container from your project and actual build configuration is inside Dockerfile. And this should not require complex CI (and I spent more than one hour setting up Gitlab CI for this simple workflow). Gitlab CI is powerful indeed, but needlessly complex IMO. If I would set up project for myself, I probably would downshift to simple bash script like I did CI 15 years ago.

Then you don't have too much of a choice: gitlab all the way :)

We ran an gitlab instance for about eight years and it worked flawlesly[1] for a team of ~20, with quite a few active repos (i.e. constantly pushing), some of them being generously large, running several pipelines on most of them.

PS: gitorious was aquired by gitlab, not gitolite. My bad.

[1]: once we pumped up _LOT_ of RAM into it that is

I would not recommend Gitlab. It is slow and buggy.

I cannot disclose details (we are premium customer and the bug reports would disclose my employer and identity), but every second week our Gitlab integration is blocked by some real shitty bug. Most common thing: Gitlab has a feature we need, but its only usable via WebUI and the API endpoint is broken or lacking in necessary details. So we cannot automate things that are very manpower-intensive.

We were also using Gitlab for a couple years now and are switching over to Github now. CI on Gitlab is nice, but Github Actions work very similar.

Most of our devs were annoyed by some external toolings that supported Github but not Gitlab, Gitlab being slow or down, markdown rendering being terrible slow as well as almost all of the PR additions (e.g. eslint checks, test coverage reports etc) being in the top tiers (with pricings being out of scope for us).

Gitolite is open source maintained by Sitaram Chamarty https://gitolite.com/ so I don't think it's even possible to acquire it in the way you suggest.

Gitweb can work quite nicely with gitolite to provide a web view of your repositories, with access control managed by gitolite.

If you don't need a front-end, push and pull directly from git. https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-...

I am surprised that this got downvoted so quickly without comment. I'd genuinely like to know what the downsides of doing it this way would be. Having to manage your own SSH keys seems like a problem, but I don't know what the others would be since my needs aren't very big.

As far as I know there's nothing wrong with access via direct SSH if you have a simple single-user setup and just want to store your repos on a remote host.

However I once saw a small team try that approach and it caused endless problems related to permissions and ownership of the files on the remote system. Maybe things have improved or with a better setup it would be easier but from my experience 0/10 would not recommend.

In that scenario -- where you have a small team and want a remote host for the repos but you don't want all the other baggage -- I've found gitolite to be a good solution. It provides a simple access control layer to handle the multiple git users and basic security requirements while using only a single local user on the server side. Otherwise it stays out of your way and it's mostly just a smart use of git hooks so it's very lightweight.

Gitea all the way.

Lightweight (can run on a RPi unlike GitLab), does everything you expect, can work with SQLite or MySQL/MariaDB or PostgreSQL, and can sync remote (GitHub/Bitbucket/whatever) repositories locally.

I voted "other": I just put bare git repositories on my VPS, and interact with them over SSH. Tiny and simple cgit exposes a read-only HTTPS interface for the repos that I want to share publicly.

Similar here. So simple:

  user@remote ~ > git init --bare myproject.git
  user@local myproject > git remote add vps user@remote:myproject.git

I use ssh, and a script that manages ssh keys and system user accounts, with a umask change and some symlinks. This means I can add read-only ssh access for deployment keys. The remote address would be of the form ssh://{clientname}[-ro]@domain:port/~/repos/{reponame}.git

The [-ro] gives the readonly access. I use git-shell to prevent normal ssh access to the server on those accounts.

I also use this method. Getting some front-end UIs to work with ssh is kind of a pain though.

That said, I think what the OP actually wants it a web front-end.

You may also want to include onedev [1][2] in your exploration (https://code.onedev.io/) if you also need good CI/CD integration.

My experience (as a user) has been pretty good, though I was not involved in the adminstration/setup related aspects but I have been told it doesn't require a lot of maintenance effort.

[1] https://github.com/theonedev/onedev [2] https://code.onedev.io/

Can't believe this is not better known. I had huge problems with a git-lfs setup being slow on gitea, but I tried out onedev and its implementation was a magnitude faster. Plus configuring and launching the thing was pretty simple.... easy win!

I made Redwood, a general purpose p2p/distributed database (and blob store) with pluggable merge algorithms (including some cool CRDTs, like what @josephg is working on).

Turns out it makes for a great self-hosted git solution, so I made a git remote plugin that allows you to interact with it using regular vanilla git commands: https://github.com/redwood/redwood/tree/libp2p-connectivity2...

Gitea+drone [0] for all my projects for several years : dockerized for even more simplicity. An update is nearly just 'compose pull && compose up'.

[0] https://www.drone.io/

I know this specifically asks for git, but I just want to mention fossil[0] here as it has git export, a built-in wiki + ticket system, etc, and is incredibly easy to self-host.

[0] https://fossil-scm.org/ (created by Richard Hipp, the guy that made SQLite)

I used to use a self-hosted instance of gitbucket:

https://github.com/gitbucket/gitbucket

That's a single .WAR file, running under Java which was nice and easy to get started with, and even has support for some trivial CI/CD actions. Unfortunately a sudden death of the docker container it was running with corrupted the internal database to the extent that it wouldn't restart. (All my repositories were fine, on-disk, but the issues and similar stuff was mangled beyond belief.)

At that point I realized that I didn't use the issues, or pull-request facilities except very very rarely, so I switched to using bare repositories on a remotely hosted virtual-server.

While I have not used it, softserve looks like a cool terminal/SSH based remote git server.

https://github.com/charmbracelet/soft-serve

I just host on my VPS and use ssh to access. My VPS gets imaged nightly (for one kind of backup) and versioned back ups using Restic.

I only collaborate with folks who I trust enough to give accounts, which means most are just personal repos.

SourceHut (https://sr.ht) is open source, although I've never tried setting it up for self-hosting. Anyone here with experience?

On Alpine Linux it’s quite simple. Each service of sourcehut is already packaged for Alpine (SourceHut’s author Drew Devault is also an Alpine contributor.) so all that’s needed is a few `apk add` and basic configuration. And a PostgreSQL database. I never finished setting up the CI service though because it requires building your own VM images to run scripts in and that was more work than I was willing to do at the time. But since it’s all modular you can have a working instance without the CI service.

I run gitlab on my kube cluster and installed that via helm charts and configured the omniauth system to communicate with my keycloak server via oidc. Overall complexity 6/10 took about 5 hours to fuss with it the first time. Subsequent deployments became easier. I hear Gitea is also a good selfhosted solution and less complex to install. However, I went with Gitlab specifically because we use it at work and I want to practice gitops/devops with it.

https://docs.gitlab.com/charts/installation/

I wonder whether people monitor resources consumed by processes… A couple of years ago I had installed Gitea, but it was constantly using between 5-10% CPU. I switched to Gogs, and it doesn’t waste CPU cycles. So, I have stayed with Gogs. My needs are minimal (self-hosting for personal use), so I could probably switch to something even more minimal, but so far Gogs works fine.

I use stagit along with https://hosakacorp.net/p/stagit-server.html and basic auth for private repos. Works amazingly. I mess with it so infrequently I constantly forget the name of it (say it three times! stagit stagit stagit!)

We're serving git over https using apache2, where apache handles authentication via LDAP. We also serve subversion repos with a similar setup. We use separate web services for search, code review, CI, and issue tracking.

Running this way does involve more moving parts, but every part is relatively self-contained and we can replace one thing without disrupting everything.

[Edit] one other benefit I should add, all the other services like code review and CI are compatible with git and svn, so the development teams have consistent tools regardless which vcs they're running for a particular project.

I prefer to do my project management in in disjunct tools from the actual source control (and I dislike the tech stack of most integrated solutions), so my main repository host is running fugit[1], which simply allows push/pull access on a per-ssh-key basis. Some repositories are then exposed to the Web using cgit[2]

[1] https://github.com/cbdevnet/fugit [2] https://git.zx2c4.com/cgit/

You should add Gerrit to your list: https://www.gerritcodereview.com

Gitweb does not belong, it is just a repository viewer.

As long as you are not looking to go totally all in [0] on GitHub or any SaSS based solution then either self-host solution option is fine.

ReactOS is a fine example of this: [1]

[0] https://news.ycombinator.com/item?id=22867803

[1] https://github.com/reactos/reactos#code-mirrors

I sync stuff via the Gitea mirror feature. Works well.

Nice, I didn't know of this feature. More info: https://docs.gitea.io/en-us/repo-mirror/

My main repos are all on Github (a few on bitbucket from back when Github did not have free private repos... how many years ago was that?) and I mirror them all with a simple cronjob of "git pull --rebase" (this gets into the normal backup cycle then)

I used to run gitolite (pre Github's existence :P) and I'm thinking about gitea, but for now I am very happy with my setup.

For those on Gitea: What CI (if any) are you using?

drone.io (https://www.drone.io/) has worked wonders for me.

TeamCity. Jetbrains has great developer tools. It is unfortunate that they have scuttled Upsource and there is not really an alternative.

No need to mirror as each checkout is a mirror. I just maintain checkouts of all the things with https://myrepos.branchable.com/

Gitea is the best thing that comes near Github is you are resource constrained.

Voted others. Just ssh into a Linux server. Have a special user account ‘git’ on the server to hold all the repos so they can just reside at the base directory of its home.

Access via ssh://git@server:~/myproj1.git.

I have a git folder in my home directory that I use syncthing to mirror.

I guess I would like a web interface that ran locally to provide other features, but the close to 0-maintenance and complete privacy of this works for me.

Used to host gitlab on my Synology. But it's so resource heavy I stopped. Also the migrations between versions weren't always pain free and costed me many hours of my time.

I'm looking at alternatives.

If you don’t need code reviews just… SSH into your server? This is what I do with my Synology, works great.

Gitea is great, and there's this reference getting more out of it:

https://gitea.com/gitea/awesome-gitea

Gitea. Also, there are GitNex (mobile app for Gitea) and Jenkins plugin.

Gogs / gitea fan here. Used both, can recommend either. One-liner docker command to set up & a simple docker-compose.yml to declare everything in one place.

SSH access through an user with git-shell as the shell. git init --bare on remote. Hosted on the tiniest VPS instance available.

I highly, highly recommend cgit. It's a lot safer than hosting accounts, databases, etc. It's a read only frontend for bare repositories.

I'm still running gitosis over here because of technical baggage. If I had the time and energy to escape it, I'd move to gitolite.

For personal stuff, I use an s3 bucket that's mounted locally via FUSE as the origin. A bit slow, but works out of the box!

Radicle https://radicle.xyz/

GitLab has a decent CI functionality baked in, should it ever come to need.

Fork Gitea, remove Discord references for safety, perfect.

Suggestion: Don't.*

But, if you have your mind set: GitLab is great.

(It WILL break at one point or another, and you will need to do recovery)

Hasn't broken for me, using it for a few years now. Are you talking of gitlab breaking specifically? Maybe that's the difference, since I use gitea instead.

Self hosted gitlab breaks all the time, at least for us. Maybe had ~10 significant issues just the last few months.

I keep expecting mine to break, but hasn't missed a beat in 2+ years.

SourceHut

charm.sh softserve

Reply on news.ycombinator.com