> Additional units can be purchased from the GitLab Customer Portal at $60/year for 10GB
$6/year per GB. My Backblaze costs me $0.06/year per GB, so it’s only a factor of 100 more expensive.
Am I the only one that thinks that’s pretty insane?
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.
> Am I the only one that thinks that’s pretty insane?
Their pricing model might not be designed to cover only storage. Pretty much all features from GitLab are loss leaders, including computing costs and developing/maintaining a CICD system that arguably is by far the best in the world. At the end of the day the money needs to come from somewhere, and you don't get that cash flow by offering everything for free.
Bold opinion. I extensively use GitHub actions and GitLab CI on a daily basis, and I am slowly liking GitHub Actions more. GitLab CI is much more straight forward if you have your own Docker image, but the mix and match approach in GitHub actions, despite the configuration complexity, is more robust in my opinion.
That said, my rudimentary knack is that GitLab CI tend to be quite fast in their free hosted runners. I have CI jobs completing in under a minute on some setups that otherwise take 2-3 minutes on GitHub hosted runners. This could be because I use a custom container image on GitLab, that basically requires no additional tooling setup.
I think its simply a reselling of GCP storage services with overhead cost of their backup redundancy and SRE on-call.
But even with all that, 6GB per year definitely make you question the value of using Gitlab Container Registry vs Your Cloud of choice similar offering.
They simply know the storage limit is the one users will most likely exceed first so having all of it bundled instead of separate price for storage and for "compute" would net them less money.
From their perspective it's basically "as long as it is cheaper than customer paying someone to set up gitlab instance"
GitLab really needs to work on their marketing and their pricing page.
On GitHub, they show their generous open source limits first,(Unlimited actions, Unlimited members, GitHub pages, etc)
While on GitLab, the first thing you see, 5 users limits and 400 minutes limit, which are nothing compared to GtiHub.
Then under a small FAQ link you can find the actually generous limits for FOSS:
> 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
OP's link.
> 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.
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.
> While on GitLab, the first thing you see, 5 users limits and 400 minutes limit, which are nothing compared to GtiHub.
I feel the minutes thing is far from a blocker, as GitLab's GitLab Runner is trivial to setup and a must-have if you care about having control over how your software is built. I have a tiny Hetzner CX11 node with a GitLab Runner handling the workload of about a dozen projects, and things work flawlessly.
GitLab Premium, at €20/(user*month) is not that pricy though, given you get the whole saas stack with it.
To me GitLab is unmatched in terms of DX and features and simplicity, but I understand if some people care about paying €20/month to use it.
> GitLab Premium, at €20/(user*month) is not that pricy though, given you get the whole saas stack with it.
It is insanely expensive for me as a small time hobby coder. I'm not sure what I'll do if I ever hit the free plan limits but $228/year is not the answer for me.
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.
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.
What's the error / job logs you are seeing with having the project settings disabled for keeping the latest artifacts? The async operation to delete artifacts can take a while. Suggest to continue on the GitLab community forum: https://forum.gitlab.com/ where more folks can help. If you continue seeing the problem, also suggest to create an issue as a bug report. Thanks! https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_t...
I might be alone, but I'm really struggling with this line of fixes from Gitlab.
To be clear - I'm all for Gitlab charging, I think that's fair and reasonable.
However, if they're gonna charge for artifact storage, they need to provide first-class tooling to manage the storage.
My experience is almost exactly the same as the OP's. Huge artefact storage from builds, the scripts to clean up don't work.
> The async operation to delete artifacts can take a while.
How do I tell if something has succeeded or failed then? Last time I ran the scripts, no errors were mentioned, but nothing was tidied up.
Cleaning this stuff up shouldn't be via hacky scripts or community projects. It should be a mandatory requirement for managing an aspect of my account that's about to become very very expensive.
Just in case anyone from Gitlab is monitoring this thread, there remain issues[0][1][2] in the artifacts listed both in the UI, and returned from the API, resulting in artifacts unable to be deleted.
It's clear that the gitlab dev team are aware of these issues, but given they've been open for years, I'm not convinced they'll be resolved before the pricing changes kick in, in a little over a months time.
If not addressed, according to the FAQ, teams builds will start failing, as they'll be unable to publish artifacts, and unable to manage the artifacts, essentially leaving them blocked.
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.
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.
> 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.
That's like complaining that AWS is expensive because you can self-host your apps. I mean, it's true but it still misrepresents the whole problem and misses the whole point of subscribing to a service.
I'm not going to play the role of GitLab salesperson, specially as I'm seeing this change as an invitation to start hosting my projects elsewhere, but there is no professional devteam on earth that can hire anyone for 200€/month to reliably develop, manage and operate their self-hosting ticketing, services, CICD pipeline, team management software, etc. Claiming otherwise is just like claiming that you can maintain your used car as well as any professional mechanic provided that it never breaks down.
And if all you need is to host git somewhere, a SSH connection will cover all your needs. But you use a bit more than that, don't you?
> That's like complaining that AWS is expensive because you can self-host your apps
I appreciate the one less job in maintaining self hosting... I have other things to maintain and would have happily paid with a reasonable markup. However the difference is not marginal, it's > 100x, and my team is small, the difference will be even larger for medium to large sized teams because the price is artificially proportional to number of users, it's not scalable and adds resistance to growth... If we derived more value than merely avoiding basic git self hosting that might be reasonable, but we don't.
> but there is no professional devteam on earth that can hire anyone for 200€/month to reliably develop, manage and operate their self-hosting ticketing, services, CICD pipeline, team management software, etc. Claiming otherwise is just like claiming that you can maintain your used car as well as any professional mechanic provided that it never breaks down.
This is disingenuous, It doesn't take the entirety of someone's role to maintain a basic git hosting server without the complexity of CI/CD. I already run a fleet of servers with far more requirements than gitea. Also I said basic git hosting... I have no need for any of CICD pipline, or issue tracking features, this significantly reduces the requirements.
> if all you need is to host git somewhere, a SSH connection will cover all your needs. But you use a bit more than that, don't you?
I don't think you read my post fully, I said basic git hosting without CI/CD... I was actually tempted by a basic SSH only git server but I don't want to manage SSH keys or force people to use the CLI to create repos, so I will be using Gitea to provide a simple web UI.
I don’t think crypto miners are to blame. More that gitlab has been giving stuff away for free for a very long time and with the current world financial situation, they have to start charging money for this stuff now.
I got the email several weeks ago - and I still don’t fully understand what it means! Unbelievable confusion.
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 are not on a paid tier, all your repositories share a pool of 5GB per namespace. A namespace is basically a user or project. So if you don't use namespaces, everything is under your personal user namespace and your limit is 5GB total storage across all your repositories.
> If you are using the free tier on GitLab SaaS, there will be a 5GB storage limit per top-level namespace.
What does this cover? Does it cover the size of a git repo? Build artifacts, both temporary and exported to packages? And what about Docker images?
Docker images concern me the most. It's terribly easy to build and use Docker images that are >100MB, and 50 of those easily go beyond 5GB. Two projects with nightly builds easily go beyond that in a month even when doing nothing at all.
I’m pretty sure the whole thing with the Gitlab product was that if you want to have that kind of control, you can host it yourself! And then you can use as much disk space as you want, for the price of disk space! (and management, power and backup)
Until they start pulling features out of the self hosted free tier.
The catch is that you need to host the Community Edition if you don't want to be at the mercy of their arbitrary decision making, which is much harder to find and install, and has far worse documentation/support and limited features.
Readit News
$6/year per GB. My Backblaze costs me $0.06/year per GB, so it’s only a factor of 100 more expensive.
Am I the only one that thinks that’s pretty insane?
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.
Their pricing model might not be designed to cover only storage. Pretty much all features from GitLab are loss leaders, including computing costs and developing/maintaining a CICD system that arguably is by far the best in the world. At the end of the day the money needs to come from somewhere, and you don't get that cash flow by offering everything for free.
Bold opinion. I extensively use GitHub actions and GitLab CI on a daily basis, and I am slowly liking GitHub Actions more. GitLab CI is much more straight forward if you have your own Docker image, but the mix and match approach in GitHub actions, despite the configuration complexity, is more robust in my opinion.
That said, my rudimentary knack is that GitLab CI tend to be quite fast in their free hosted runners. I have CI jobs completing in under a minute on some setups that otherwise take 2-3 minutes on GitHub hosted runners. This could be because I use a custom container image on GitLab, that basically requires no additional tooling setup.
At least they could charge in increments if 1 or 2GB.
But even with all that, 6GB per year definitely make you question the value of using Gitlab Container Registry vs Your Cloud of choice similar offering.
From their perspective it's basically "as long as it is cheaper than customer paying someone to set up gitlab instance"
Dropbox is 10€/month, which comes with a max cap of 2TB for what amounts to cold storage for docs that are rarely touched.
GitLab comes at 20€/month, and comes with a max cap of 50GB for files that are actively edited.
Comparing GB is disingenuous as the usecases involving storage are hardly comparable.
Deleted Comment
On GitHub, they show their generous open source limits first,(Unlimited actions, Unlimited members, GitHub pages, etc)
While on GitLab, the first thing you see, 5 users limits and 400 minutes limit, which are nothing compared to GtiHub.
Then under a small FAQ link you can find the actually generous limits for FOSS:
> 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
OP's link.
> 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.
https://about.gitlab.com/pricing/#why-do-i-need-to-enter-cre...
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.
I feel the minutes thing is far from a blocker, as GitLab's GitLab Runner is trivial to setup and a must-have if you care about having control over how your software is built. I have a tiny Hetzner CX11 node with a GitLab Runner handling the workload of about a dozen projects, and things work flawlessly.
GitLab Premium, at €20/(user*month) is not that pricy though, given you get the whole saas stack with it.
To me GitLab is unmatched in terms of DX and features and simplicity, but I understand if some people care about paying €20/month to use it.
It is insanely expensive for me as a small time hobby coder. I'm not sure what I'll do if I ever hit the free plan limits but $228/year is not the answer for me.
Deleted Comment
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.
The instructions for removing the most recent artifacts also just never works (https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#k...)
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.
This is causing us to dramatically revisit our strategy of using GitLab and might force us to other tools.
What's the error / job logs you are seeing with having the project settings disabled for keeping the latest artifacts? The async operation to delete artifacts can take a while. Suggest to continue on the GitLab community forum: https://forum.gitlab.com/ where more folks can help. If you continue seeing the problem, also suggest to create an issue as a bug report. Thanks! https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_t...
Another thought: You could clean the artifacts via the GitLab API, if that helps. An example script is available in https://gitlab.com/gitlab-de/gitlab-storage-analyzer also listed in the FAQ https://about.gitlab.com/pricing/faq-efficient-free-tier/#ma...
To be clear - I'm all for Gitlab charging, I think that's fair and reasonable.
However, if they're gonna charge for artifact storage, they need to provide first-class tooling to manage the storage.
My experience is almost exactly the same as the OP's. Huge artefact storage from builds, the scripts to clean up don't work.
> The async operation to delete artifacts can take a while. How do I tell if something has succeeded or failed then? Last time I ran the scripts, no errors were mentioned, but nothing was tidied up.
Cleaning this stuff up shouldn't be via hacky scripts or community projects. It should be a mandatory requirement for managing an aspect of my account that's about to become very very expensive.
It's clear that the gitlab dev team are aware of these issues, but given they've been open for years, I'm not convinced they'll be resolved before the pricing changes kick in, in a little over a months time.
If not addressed, according to the FAQ, teams builds will start failing, as they'll be unable to publish artifacts, and unable to manage the artifacts, essentially leaving them blocked.
0: https://gitlab.com/gitlab-org/gitlab/-/issues/373806 1: https://gitlab.com/gitlab-org/gitlab/-/issues/363010 2: https://gitlab.com/gitlab-org/gitlab/-/issues/228681
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.
That's like complaining that AWS is expensive because you can self-host your apps. I mean, it's true but it still misrepresents the whole problem and misses the whole point of subscribing to a service.
I'm not going to play the role of GitLab salesperson, specially as I'm seeing this change as an invitation to start hosting my projects elsewhere, but there is no professional devteam on earth that can hire anyone for 200€/month to reliably develop, manage and operate their self-hosting ticketing, services, CICD pipeline, team management software, etc. Claiming otherwise is just like claiming that you can maintain your used car as well as any professional mechanic provided that it never breaks down.
And if all you need is to host git somewhere, a SSH connection will cover all your needs. But you use a bit more than that, don't you?
I appreciate the one less job in maintaining self hosting... I have other things to maintain and would have happily paid with a reasonable markup. However the difference is not marginal, it's > 100x, and my team is small, the difference will be even larger for medium to large sized teams because the price is artificially proportional to number of users, it's not scalable and adds resistance to growth... If we derived more value than merely avoiding basic git self hosting that might be reasonable, but we don't.
> but there is no professional devteam on earth that can hire anyone for 200€/month to reliably develop, manage and operate their self-hosting ticketing, services, CICD pipeline, team management software, etc. Claiming otherwise is just like claiming that you can maintain your used car as well as any professional mechanic provided that it never breaks down.
This is disingenuous, It doesn't take the entirety of someone's role to maintain a basic git hosting server without the complexity of CI/CD. I already run a fleet of servers with far more requirements than gitea. Also I said basic git hosting... I have no need for any of CICD pipline, or issue tracking features, this significantly reduces the requirements.
> if all you need is to host git somewhere, a SSH connection will cover all your needs. But you use a bit more than that, don't you?
I don't think you read my post fully, I said basic git hosting without CI/CD... I was actually tempted by a basic SSH only git server but I don't want to manage SSH keys or force people to use the CLI to create repos, so I will be using Gitea to provide a simple web UI.
Dead Comment
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 are not on a paid tier, all your repositories share a pool of 5GB per namespace. A namespace is basically a user or project. So if you don't use namespaces, everything is under your personal user namespace and your limit is 5GB total storage across all your repositories.
TFA says 10 GB (and so does my experience).
> A namespace is basically a user or project
I believe you meant to write "a user or a group".
If you are using the free tier on GitLab SaaS, there will be a 5GB storage limit per top-level namespace.
Paid tiers on GitLab SaaS will have limits of 50GB for Premium and 250GB for Ultimate.
Community programs (GitLab for Open Source, GitLab for Education, and GitLab for Startups) will have the same 250GB limit as the Ultimate tier.
Self-managed users have no limit.
What does this cover? Does it cover the size of a git repo? Build artifacts, both temporary and exported to packages? And what about Docker images?
Docker images concern me the most. It's terribly easy to build and use Docker images that are >100MB, and 50 of those easily go beyond 5GB. Two projects with nightly builds easily go beyond that in a month even when doing nothing at all.
- Do I have to do anything now with all my “top-level” repositories (total >5GB)?
- When I create a new repository do I have to do something else as well (create new namespace)?
This sounds like a lot, just so I can keep my native Windows/Linux/MacOS builds online. My current usage need is 14.9gb.
The catch is that you need to host the Community Edition if you don't want to be at the mercy of their arbitrary decision making, which is much harder to find and install, and has far worse documentation/support and limited features.
Deleted Comment