[mardifoufs]

I mean I dislike the gitlab pricing increases, and we are kind of regretting sticking with them (especially since everyone on the Gitlab instance has to pay for a seat, even when not using any of the premium features) considering how Github is cheaper and has a higher release velocity at this point... But to be very fair, we never saw what you describe about memory leaks or slow ruby services. Migrations are also usually silent and done in the background. I guess the software itself is pretty heavy, but predictably so (RAM usage rarely spikes, for example).

We have a 400+ seats instance, with a decade worth of code and it just works 99.99% of the time, and upgrades are generally painless. Though our instance is pretty vanilla, and internal to our corporation. The runners are more finnicky and buggier, especially since we have tons of different build targets but that's besides the point if we are just talking about using it as a dumb git repo. And if you only need it for that purpose why even pay instead of using the community edition?

(I'm in the AI team but I sometimes help the devops team that takes care of the instance to customize our AI pipelines, so I'm familiar with gitlab and with my colleagues experience with it)

[cwsx]

The company I'm currently at uses a self hosted instance, which due to our "security"* constraints we're grossly behind in updates. Not to say that's Gitlabs fault at all, but the amount of issues we have near daily is hilarious (if it didn't simultanously crush productivity).

That said, I recall issues with the Gitlab Enterprise Support / whoever we contact about our license etc, mostly to do with slow or poor communication. Requests would sit for a month before we got a reply, often dismissive or generally unhelpful, though we _were_ on an outdated version so I don't blame them.

I vaguely recall an email about support ending on self hosted instances? I can't recall the details, but I know it triggered an internal investigation into moving away from Gitlab. EDIT: Pretty sure I'm remembering self hosted Jira, a quick Google search shows Jira EOL but no Gitlab.

All of that said, I largely blame my company for the failures here. I wouldn't expect any company to support self hosted, outdated versions. The support issues were annoying, but I'm also not sure how much I can blame Gitlab for that. I'm also struggling to remember the details, so take this as one mans hazy annecdote.

* film industry, security by obscurity in the worst ways, leads to incredibly outdated and neglected tech (we only _just_ transitioned to Python3, and that's only the core services)

[jmholla]

At least parts of what you say ring true in my experience following GitLab releases more closely (e.g. 1-2 months behind). I would highly recommend not self-hosting if you're going to go with GitLab. Performance issues will appear and disappear between updates, and sometimes on a whim and you're never quite sure what you did or didn't do.

I did find the support staff to be fairly responsive, but most of that time felt like me collecting diagnostic information with little actionable material, and sometimes I would have to explain the same thing multiple times in the same support ticket because it switched hands.

If you do still opt to self-host, dig into their documentation: there are little nuggets and hacks they use internally that you'll want to use to get the right performance out of it.

[cwsx]

I absolutely would not opt to self-host, but unfortunately that's not my department. I agree about the performance issues, most of our issues were performance related and did seem quite random (though unsure if that was our self hosted instance or a Gitlab issue, sounds like it could be both).

I will admit I'm probably overly harsh on the support staff, and misrepresenting the support issues we had. I wasn't directly involved in most of it so I'm parroting what I've heard from coworkers that were more involved, which isn't the whole story. Though the times I was directly involved (in support requests) the experience mostly matched yours, with a couple (albeit rare) cases of slow replies.

In terms of self hosting I 100% agree, and anyone who is thinking of setting up their own self hosted instance should take note of your comment.

[mardifoufs]

Self hosting is fine... but only for an internal instance. The release cycle is pretty extreme, with a critical security update seemingly popping up every two weeks. I mean that's better than not patching the issues, but it still means you have to stay on top of it. Having an internal/private network instance doesn't actually help you all that much, but it still gives you a little more breathing room.

(and I know it might contradict my earlier comment saying that Github's release velocity is a plus, but it doesn't. Most gitlab releases don't introduce useful features, they mostly patch security issues and regressions. For example, the Runners are in a dire need of tons of features and an outright rework of some parts, but barely get any. Which is sad since they were so far ahead of the competition not so long ago.)

[jmholla]

> The release cycle is pretty extreme, with a critical security update seemingly popping up every two weeks.

That just reminded me of my least favorite thing about their releases: they brag about releasig on time for however many months in a row, but they're always quickly followed up with bug and security fixes. I felt their presentation of consistency was misleading at best.

[megous]

My bad experience was mostly just with installing gitlab on a 1GiB RAM VM, to see how it will fare and how easy it is to manage. I expect it to work for people who don't mind throwing a 16GiB+ RAM machine at it. But our dataset is currently like ~200 MiB and simple relatively dumb git hosting just works much better in our case.

[jcrawfordor]

GitLab should run fine on a machine with 4GB memory - this is the smallest recommended memory allocation, spec'd for up to 500 users. 2GB tends to work okay for testing but 1GB is indeed probably too small for all of the services to start. Postgres actually tends to be the long pole in the tent on small systems.

[deng]

Sorry, but the recommended system requirements are an absolute joke. They might be OK if you really only do pure code hosting and don't use CI, container/package registries, project planning features and whatnot, but on our instance with 400 users, the sidekiq background jobs alone easily eat 12GB RAM (I had to extend sidekiq to 4 processes just to deal with the load, otherwise GitLab would become unresponsive).