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!
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.
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.
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).
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 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 (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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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?
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).
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.
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!
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.
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 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]
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 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.
85 comments
[ 0.20 ms ] story [ 190 ms ] threadIIRC 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.
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 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.
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).
Gitweb can work quite nicely with gitolite to provide a web view of your repositories, with access control managed by gitolite.
Gitweb does not belong, it is just a repository viewer.
https://github.com/charmbracelet/soft-serve
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.
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.
[1] https://codeberg.org
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.
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.
Apart from that, a fact is that gitea is less resource hungry, so it runs well even in modest configurations.
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)
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 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.
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.
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.
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.
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).
Are you saying that I can self-host and have the same "review" functionality as GitHub when reviewing PR's?
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/
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.
[1] https://github.com/cbdevnet/fugit [2] https://git.zx2c4.com/cgit/
The [-ro] gives the readonly access. I use git-shell to prevent normal ssh access to the server on those accounts.
That said, I think what the OP actually wants it a web front-end.
[0] https://fossil-scm.org/ (created by Richard Hipp, the guy that made SQLite)