> Additional units can be purchased from the GitLab Customer Portal at $60/year for 10GB<p>$6/year per GB. My Backblaze costs me $0.06/year per GB, so it’s only a factor of 100 more expensive.<p>Am I the only one that thinks that’s pretty insane?<p>What I think is even stranger, is that the number of users you pay for apparently has no effect on your storage allowance. Whether there’s 1 or a 100 accounts, the limit is the same.
GitLab really needs to work on their marketing and their pricing page.<p>On GitHub, they show their generous open source limits first,(Unlimited actions, Unlimited members, GitHub pages, etc)<p>While on GitLab, the first thing you see, 5 users limits and 400 minutes limit, which are nothing compared to GtiHub.<p>Then under a small FAQ link you can find the actually generous limits for FOSS:<p>> What is changing with user limits?
A. There will be a 5-user limit for top-level namespaces with private visibility. At this time, top-level namespaces with public visibility will not have a user limit<p>OP's link.<p>> Yes. Public projects created after 2021-07-17 will have an allocation of CI/CD pipeline minutes as follows: Free tier - 50,000 minutes, Premium tier - 1,250,000 minutes, Ultimate tier - 6,250,000.<p><a href="https://about.gitlab.com/pricing/#why-do-i-need-to-enter-credit-debit-card-details-for-free-pipeline-minutes" rel="nofollow">https://about.gitlab.com/pricing/#why-do-i-need-to-enter-cre...</a><p>I didn't know that the 5 member limits applies only to private projects. And a big part of the reason I signed up, because they give you a lot of CI/CD minutes for FOSS, although the Visa requirement is very annoying.
We've been struggling with this GitLab storage change, even consulting with GitLab reps on strategy logic between namespace versus repositories. It's still very confusing, especially if you were using their other offerings like CI/CD build systems and associated build artifacts storage.<p>The artifacts storage is that one that's just tough to figure out when dealing with large builds. We have already offloaded all our CI/CD to our own hosted GitLab runners, but apparently storing the artifacts afterwards (which by default GitLab always stores the most recent builds) MUST use their storage, we can't offload it to our own servers.<p>The instructions for removing the most recent artifacts also just never works (<a href="https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#keep-artifacts-from-most-recent-successful-jobs" rel="nofollow">https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#k...</a>)<p>So in our monorepo with multiple Windows and Mac applications, we are now stuck with lots of GB that are just there, currently unable to delete.<p>This is causing us to dramatically revisit our strategy of using GitLab and might force us to other tools.
For teams that only need git hosting the recent price hikes are complete nuts... changed from 0$ to 20$ per user / per month, i.e $240 per user / per year - this represents about a 120x difference in price compared to self hosting for my team. I get that their business model was based upon CI and ancillary integrations (which I have no need for), but I would have been happy to pay a reasonable base rate for git hosting... to me this price is just a "go away" signal for anyone not interested in CI and containers.<p>I'm switching to self hosting, at the cost of 0.25 users in gitlab world - with a lot more resources (I noticed they throttle cloning). Thankfully gitea exists because it sounds like gitlab is a nightmare to self host anyway.
I got the email several weeks ago - and I still don’t fully understand what it means! Unbelievable confusion.<p>PLEASE can someone in plain english say what the limits are PER REPOSITORY? Is it 5GB per repository? can you have as many repositories as you want? I don’t care or use namespaces.
> If you require 15GB storage, you will pay $120 for the year.<p>This sounds like a lot, just so I can keep my native Windows/Linux/MacOS builds online. My current usage need is 14.9gb.
Seems like free tier limitations <i>does not apply</i> to a public group as top namespace, that contains private subgroups and repositories. This would kind of help a lot!
Sounds reasonable. In general I think price for any cloud based service will go up until <i>Cloud is obvious solution</i> stop being applied in all contexts.