You could make this argument about basically any service and it comes up on HN without fail anytime something like this happen: "Just self host, it isn't hard."

And sure - self hosting might not be terribly complicated but that's one more thing that now you've got to worry about and keep track of. One more thing that you've got manage and keep up to date. There is a lot of value in convenience, ease of access, and simple scalability.

This service update only applies to people who self-host. Servers managed by gitlab are patched by gitlab staff. If you're going to self-host I think you should at least --consider-- self-hosting something with a tiny attack surface instead of a complicated product with many dependencies and "casual" security practices.

You're in a thread about an update to the self-hosted Gitlab offering. They aren't saying "use this instead of the service", but "if you self-host you can also self-host a simpler thing", so your response really doesn't fit the topic at hand.

There is a point where "simpler" is so laughably inadequate when compared to the alternative that dismissing the comment makes sense. You lose code review, integrated CI, and will need quite a lot of time to manage this entire solution anyway.

If you want to make a different argument agains the comment, feel free to do so, but I'm not sure how that's relevant to my comment or the comment I replied to?

I'd love to see the same effort that is going into avoiding managing a service go into contributing better tooling to that service or to the OS package/configuration so it's not 30 minutes of work. I'd love it if it worked more like this: apt install myservice and maybe one or two tweaks/decisions to configure for use. A lot of the issues here are that dynamic language based services (python/ruby/js) don't play nice with OS provided interpreters. This is a problem that really needs to be solved, if we'd like to continue to have nice things.

The tooling is already there. All the "not playing nice" issues are largely solved by using Docker. Installing a local Docker instance of Gitlab is literally four commands. Mkdir three directories and docker run to get it started.

See https://docs.gitlab.com/ee/install/docker.html

> All the "not playing nice" issues are largely solved by using Docker

Not really. Now any integration has to be done inside the container or with other containers... which adds lots of extra steps. I do agree using Docker makes a simple deployment easier, though.

In this case though, gitlab is a self hosted product

It takes just 30 minutes to clean your office. You can go to Home Depot and buy all the supplies for cheaper than what it costs for a janitor in a month.

Accept your time is limited and valuable. You might drive a higher roi focusing your time on the core business than doing ancillary tasks

Sure... and yet I would happily spend an entire day learning about git to avoid 30 minutes cleaning: the premise that time is fungible is simply incorrect.

(Regardless: this "30 minutes" is of course an estimate, and isn't "30 minutes longer". I do demos in college classes on how to set up personal git servers--given your existing ssh and web server setup--with nothing more than a git init --bare and renaming a single default hook, and so setting up GitLab to me is definitely going to take way more time as it probably is going to require learning some new config file format and figuring out if it has some kind of database dependency and the such. But the reality is that time is NOT fungible so GitLab might be worth setting up no matter how hard it is vs. using git as intended.)

It only takes 15 minutes to order a new prefabricated office!

For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.

Exposé without encryption, at least use SFTP and rclone mounts in this theoretical use case scenario

I'm pretty sure this is a reference to the famous Dropbox comment[0], not an actual proposal.

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

This comment drastically undervalues the features that both Gitlab and GitHub provide, even for very small teams.

Oh geez I've been hand wringing about which self-hosted git thing to put on my personal VPS to replace Phabricator and this is such an obvious answer. Thanks!

EDIT: replace isn't the right word for most phab features (code review, issue track, wiki), but I just mean replace for repo sharing with push and pull

Personally I hope Phorge gets enough momentum to live on as a community project https://we.phorge.it/source/phorge/

My team went to gitLab after phabricator maybe 2 years ago. Works great here

Thanks for sharing :) GitLab team member here.

Phabricator has many great features which inspired GitLab. I've shared some of them in this blog post: https://about.gitlab.com/blog/2021/08/13/five-great-phabrica...

> It takes about 30 minutes to set up your own git server.

It takes about 50 seconds to setup and run a local Docker instance of Gitlab-ce.

The value for time and money (it's free) is insane. You don't just get git, but a fully featured issue management system, a nice UI, CI/CD integration, Kubernetes hooks...etc,etc.

If you want to run your own repo I can't think of anything which is even remotely as valuable. You can even throw it on a Raspberry Pi and have a home lab code repository setup which would make major corporations envious just a few years ago.

If you're using just plain command line git to manage your code projects you're lingering in the past, which is perfectly fine, but these days you can do way better for less work. It's as if you were using bvi (binary vi) to edit your photos when GIMP is freely available. (I hope I get extra credit for not using a car analogy :)

To be clear I'm not dissing command line git - I use it every day. But if you're managing multiple code projects and need to keep track of issues and run automated tests then Gitlab gives you an amazingly powerful tool set for making your life easy.

I think the difference is that the gitlab instance will probably require care and feeding beyond letting the OS "apt update; apt upgrade" once a night.

There are 100 different features in Gitlab, and only one of those is keeping your code in version control. It's valuable for any size team. Why would you want to waste a small team's time trying to DIY everything when they can just install one solution that does everything for them for free?

What about the cost of maintaining the server? I've had poor experiences with maintaining my own VPS in the past. Basic advice is setup fail2ban and I'm unable to ascertain if that's adequate. We're not all walking around with that knowledge, nor do I know how to easily acquire it.

Either go with a hosted solution or take the time to learn linux server admin. Linux hasn't changed much in the past 15 years, and I don't think it will change much in the coming years either. With web stuff you have to keep up with new developments, but linux is very stable and boring by comparison. There's a learning curve, but taking the time to understand how linux really works is totally worth it.

You'll want to follow some linux hardening guides, set up a firewall, set up fail2ban, set up full disk encryption, backups, and some other things.

The parent suggestion of just running git over SSH has a small attack surface, its not like HTTP accepting anyone through the front door. Set `PasswordAuthentication no` in `/etc/ssh/sshd_config` and I don't think you even need fail2ban. But you could put a rate limit on new connections to port 22, or leave the fail2ban setup as an additional guard, and of course you want to block all the other ports you don't need.

It doesn’t though. I need a secure, maintainable, audited, backed-up solution which would pass a SOC2 audit.

Any soc2 auditor (or other security auditor) that will sign off on self-hosted gitlab, but not self-hosted git should have their accreditation pulled!

Git's attack surface and trusted computing base are a subset of gitlab's. Even if gitlab security were perfect, it would still be no better than git.

Gitlab and Github do way way way more than just run git.

Smaller groups can do without code review, CI/CD and issue tracking? I mean I guess if your "smaller group" is literally 1 or 2 people.

Your setup could also have a security issue.

What's the attack surface of a git linux account that doesn't have a shell and can only log on through ssh with a key from whitelisted IPs in a firewall? Compare that attack surface with that of a complicated web app like gitlab.

Sure, but you could control access to the Web app, too? E.g. allow only certain VPN accounts to access it? There are lots of ways to manage attack surfaces.

How are you going to do code review and manage that discussion?