There have been a number of updates in the last 3 years that would have completely broken or caused 500 errors on your Gitlab instance if you immediately updated it prior to a hotfix being released. If you didn't encounter these I would be shocked or you're keeping off bleeding edge releases (smart). I've managed private gitlabs for 4-5 years. I've submitted ~5-10 tickets regarding various things breaking (gitlab-runner, pages 500ing after an upgrade, etc).

If you give each update a few weeks/month and pay attention to the comments on each release blog you'll save yourself quite a bit of headaches.

I found that the good old “skip the .0 release” goes a long way.

Exactly what I am doing too, always wait for the next patch release after a x.0.0.

Before doing that I had two situations where the major release broke something. Never looked back.

exactly my experience. Assuming that a powerful enough server is available to do that. Our first attempt to run gitlab on some small cheap VPS (2 cores, 4 gigs of ram) was a total disaster.

What server specs are working well for you?

Not OP but I have a number of gitlab instances:

For 5 users we use 18G/4vCPU. For 20 users we use 32G/8vCPU

I keep asking to lower the footprint but the gitlab is the very definition of feature creep. And that comes at the cost of optimisation.

We support 30 developers on 10gb ram and 4 cores. That said, we are probably a year and a half behind version wise and only use it for its SCM capabilities.

We are running it on a 2vCore, 8GB RAM vm. Works good for our ~10 concurrent users on peak. The ~120CI builds per day are running on other hosts though.

quad core with 16 gigs of ram for a team of 4 people. Most likely 8gb of ram would be sufficient for us but the risk of decreasing our productivity is not worth the insignificant difference in price of 8GB vs 16GB VPS monthly fee.

Gitlab has lots of problems. It runs slowly unless you throw tons of hardware at it, and has lots of bugs. Our devops guy burns tons of time keeping it running. There are too many parts to it; too many services. And ruby is just not meant to be used in production stuff, particularly not of that scale.

What is Ruby meant to be used for, if not production software?

Rapid prototyping. I'm not talking entirely out of my behind here; I've done ruby before. It's a joy to write, especially compared to something like Java. Unfortunately, that convenience and syntactic sugar comes at a price - performance.

Ruby is like a back-of-the-napking sketch, almost: it takes nothing to get started, you can just jump in and start writing. Other languages are closer to gradations of a proper engineering diagram, the sort of thing you draw up once you've fleshed out your idea a little and want to scale.

As much as I hate bothering with a proper diagram, it's very hard to scale based on napkin sketches.

Have you also tried Gogs?

https://gogs.io

Gogs isn't exactly the same product though. If all you need is a git repo then sure, but it's all the other features that make GitLab more difficult to maintain