6 ms·
GitLab is best (imo) as a private instance; we haven't had any issues with it after using it for 3 years now
by umvi 7y ago
GitLab is best (imo) as a private instance; we haven't had any issues with it after using it for 3 years now
- mr__y 7y agoexactly 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.
- rococode 7y agoWhat server specs are working well for you?
- dijit 7y agoNot 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.
- aprdm 7y agoWe 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.
- mr__y 7y agoquad 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.
- maverwa 7y agoWe 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.
- mtgx 7y agoHave you also tried Gogs? https://gogs.io https://gogs.io
- emilycook 7y agoGogs 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
- swozey 7y agoThere 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.
- maverwa 7y agoI found that the good old “skip the .0 release” goes a long way.
- lenovouser 7y agoExactly 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.
- bin0 7y agoGitlab 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.
- palimpsests 7y agoWhat is Ruby meant to be used for, if not production software?
- bin0 7y agoRapid 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.