GitLab SaaS Free Tier FAQ(about.gitlab.com)
about.gitlab.com
GitLab SaaS Free Tier FAQ
https://about.gitlab.com/pricing/faq-efficient-free-tier/
13 comments
> 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.
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.
> by far the best in the world
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.
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.
> GitLab CI is much more straight forward if you have your own Docker image
In my experience GitLab is straight-forward in all of its happy path, which happens to be exactly what all developers need to do: build software, push build artifacts, run tests, and in the case of services deploy stuff somewhere else.
With GitLab anyone can set their fully working CICD pipeline from scratch after a quick googling, which is absolutely not possible with GitHub actions.
The only downside of GitLab is their pricing model. If it wasn't for GitLab's not-so generous free tier, there wouldn't be any reason to bother looking at alternatives like GitHub and the like.
In my experience GitLab is straight-forward in all of its happy path, which happens to be exactly what all developers need to do: build software, push build artifacts, run tests, and in the case of services deploy stuff somewhere else.
With GitLab anyone can set their fully working CICD pipeline from scratch after a quick googling, which is absolutely not possible with GitHub actions.
The only downside of GitLab is their pricing model. If it wasn't for GitLab's not-so generous free tier, there wouldn't be any reason to bother looking at alternatives like GitHub and the like.
The pricing does seem unusual. Dropbox is also $0.06/year GB. A dev/b2b servicing charging 100x as much as a consumer service seems very strange.
At least they could charge in increments if 1 or 2GB.
At least they could charge in increments if 1 or 2GB.
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"
From their perspective it's basically "as long as it is cheaper than customer paying someone to set up gitlab instance"
> Dropbox is also $0.06/year GB.
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.
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.
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.
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.
[deleted]
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.
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.
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.
> 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.
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.
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.
> It is insanely expensive for me as a small time hobby coder.
No small time hobby coder needs GitLab Premium. You are free to create as many projects and groups as you need, without having to pay a dime.
No small time hobby coder needs GitLab Premium. You are free to create as many projects and groups as you need, without having to pay a dime.
> No small time hobby coder needs GitLab Premium. You are free to create as many projects and groups as you need, without having to pay a dime.
For now, I'm nowhere near any limits of the free plan. I'm not sure I'll ever be but I'm not ruling out the possibility, especially if/when the plans change in the future.
Edit: My local Linux kernel git repo is over 4GB. If I wanted to hack on that and keep it on Gitlab, with my current usage, I would be pretty close to the 5GB limit. Of course I don't need Premium in such a case as there is a (relatively expensive) storage addition option, but if I need to expand again then Premium would actually be $1 less and I'll get more storage.
For now, I'm nowhere near any limits of the free plan. I'm not sure I'll ever be but I'm not ruling out the possibility, especially if/when the plans change in the future.
Edit: My local Linux kernel git repo is over 4GB. If I wanted to hack on that and keep it on Gitlab, with my current usage, I would be pretty close to the 5GB limit. Of course I don't need Premium in such a case as there is a (relatively expensive) storage addition option, but if I need to expand again then Premium would actually be $1 less and I'll get more storage.
OR: You can run your own node and pay the native cost for storage.
I run a gitlab for my IRC network (https://git.drk.sc) because I like to do sysadmin things and some people don't want to do that.
But storage isn't free, it's not really fair to expect everything hosted for free, they give you the software which you can run yourself.
I know Github does this; but it's obviously a loss leader for them and I do think that the day will come that they'll start restricting (heavily) the free tiers once they have total dominance on the Git ecosystem or the financials start becoming a huge issue.
I run a gitlab for my IRC network (https://git.drk.sc) because I like to do sysadmin things and some people don't want to do that.
But storage isn't free, it's not really fair to expect everything hosted for free, they give you the software which you can run yourself.
I know Github does this; but it's obviously a loss leader for them and I do think that the day will come that they'll start restricting (heavily) the free tiers once they have total dominance on the Git ecosystem or the financials start becoming a huge issue.
> OR: You can run your own node and pay the native cost for storage.
At that point I'll just run Gitea on a sub-$5 VPS. It does more than what I need and is simple to run, and has more storage for less.
> But storage isn't free, it's not really fair to expect everything hosted for free, they give you the software which you can run yourself.
I'm more interested in paying a reasonable amount if I hit their free plan limits. My point is that their pricing scheme seems ridiculously high for small time hobby coders like myself and will drive me away from Gitlab if I hit their limits, instead of giving them money.
At that point I'll just run Gitea on a sub-$5 VPS. It does more than what I need and is simple to run, and has more storage for less.
> But storage isn't free, it's not really fair to expect everything hosted for free, they give you the software which you can run yourself.
I'm more interested in paying a reasonable amount if I hit their free plan limits. My point is that their pricing scheme seems ridiculously high for small time hobby coders like myself and will drive me away from Gitlab if I hit their limits, instead of giving them money.
You can, per another comment it’s $60/yr for 10GB extra storage. Not exactly cheap, though.
$0.50/m per Gig.
Pretty high; maybe 20x what Google would charge for raw storage for regionally available disks.
Not counting access (0.05c/10,000 ops) or backups.
Pretty high; maybe 20x what Google would charge for raw storage for regionally available disks.
Not counting access (0.05c/10,000 ops) or backups.
I'm pretty sure of my reading: if your GitLab repo is a fork of an existing repo, you only pay for the difference.
It may well be that your repo currently isn't a fork of something like https://gitlab.com/linux-kernel/linux then you can fork it, add the fork as your origin, and push the result.
It may well be that your repo currently isn't a fork of something like https://gitlab.com/linux-kernel/linux then you can fork it, add the fork as your origin, and push the result.
[deleted]
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.
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.
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.
> The instructions for removing the most recent artifacts also just never works (https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#k...)
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...
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...
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.
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.
Oh it feels great to learn I'm not alone in this problem. I completely agree with everything noted here.
The current interface provided for removing the artifacts on GitLab just does not work. There is no feedback; no confirmation. We just uncheck a box and just cross our fingers since there is no other step noted.
Even with the new guidance provided, it's still additional jumps through other codebases just to see if it works. I'm now worried that if I go through this new process, I'll end up right back at the same issue.
The current interface provided for removing the artifacts on GitLab just does not work. There is no feedback; no confirmation. We just uncheck a box and just cross our fingers since there is no other step noted.
Even with the new guidance provided, it's still additional jumps through other codebases just to see if it works. I'm now worried that if I go through this new process, I'll end up right back at the same issue.
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.
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
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
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.
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 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 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 said basic git hosting... I have no need for any of CICD pipline, or issue tracking features.
My point is that it makes no sense to adopt any third-party git hosting service is all you want to do is have a git repo somewhere, thus it makes no sense to complain about how a service is expensive when you do not have any reason to use the service to begin with. Services like GitHub or GitLab or BitBucket or AWS CodeCommit are pointless if all you need is a remote repo somewhere. Complaining that GitLab is expensive when you only need a git repo is like complaining that Netflix is expensive when you only need a screen saver.
My point is that it makes no sense to adopt any third-party git hosting service is all you want to do is have a git repo somewhere, thus it makes no sense to complain about how a service is expensive when you do not have any reason to use the service to begin with. Services like GitHub or GitLab or BitBucket or AWS CodeCommit are pointless if all you need is a remote repo somewhere. Complaining that GitLab is expensive when you only need a git repo is like complaining that Netflix is expensive when you only need a screen saver.
I'm not sure why you are so selectively reading my post.
I'll paste the first sentence of my first paragraph here again, it provides a good reason:
> 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.
Also you can't simultaneously argue that I have no right to use a service with which I can compete with against cost price and that I cannot possibly compete with their price. I get the sense that you have an axe to grind.
My argument is merely that the price change is excessively unreasonable for those who only wanted git hosting... and at it's core, it's a git hosting service.
I'll paste the first sentence of my first paragraph here again, it provides a good reason:
> 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.
Also you can't simultaneously argue that I have no right to use a service with which I can compete with against cost price and that I cannot possibly compete with their price. I get the sense that you have an axe to grind.
My argument is merely that the price change is excessively unreasonable for those who only wanted git hosting... and at it's core, it's a git hosting service.
And yet again it's crypto miners abusing public resources and leading to stricter rules for everyone :(
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.
Then you haven't seen how chia miners and data hoarders abusing "unlimited" storage have destroyed one online platform after another in recent months.
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.
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're a paying user it's 5GB per repository.
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 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're a paying user it's 5GB per repository.
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".
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".
Apologies for the confusion. I'd be happy to provide some more clarity. The answer depends on which tier of GitLab you are using.
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.
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.
> 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.
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.
> What does this cover?
https://about.gitlab.com/pricing/faq-efficient-free-tier/#ma... provides a list of what counts towards the storage limits, and also ways to manage, reduce and cleanup storage.
> Does it cover the size of a git repo? Build artifacts, both temporary and exported to packages? And what about Docker images?
Yes, they all are storage types that add to the overall storage consumption.
> 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.
You can define container cleanup policies within the registry, matching on age, tags, etc. https://docs.gitlab.com/ee/user/packages/container_registry/...
https://about.gitlab.com/pricing/faq-efficient-free-tier/#ma... provides a list of what counts towards the storage limits, and also ways to manage, reduce and cleanup storage.
> Does it cover the size of a git repo? Build artifacts, both temporary and exported to packages? And what about Docker images?
Yes, they all are storage types that add to the overall storage consumption.
> 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.
You can define container cleanup policies within the registry, matching on age, tags, etc. https://docs.gitlab.com/ee/user/packages/container_registry/...
> You can define container cleanup policies within the registry, matching on age, tags, etc. https://docs.gitlab.com/ee/user/packages/container_registry/...
Yeah, I gotta say - this is not great. Particularly given the overarching guidance on GitLab CI is "break everything up into 30 jobs", having to store containers as either an artifact or in the registry in order to pass them to sast or test jobs or w/e means that most projects are going to hit this limit instantly. Our largest work project has registry usage sitting at 800g - admittedly, we could be a lot better at cleaning up tags. But staying under 50 for the whole namespace, not even just registry, is going to incredibly difficult.
A fair while ago, we used self-hosted and swapped to SaaS because it was the same price and we didn't have to deal with upgrades etc - and we used our own CI runners anyway. Is the unspoken intention to force users like us onto self-hosted? Should we instead be using a non-GitLab registry to store this stuff?
Very long term GitLab user, very disappointed by this.
Yeah, I gotta say - this is not great. Particularly given the overarching guidance on GitLab CI is "break everything up into 30 jobs", having to store containers as either an artifact or in the registry in order to pass them to sast or test jobs or w/e means that most projects are going to hit this limit instantly. Our largest work project has registry usage sitting at 800g - admittedly, we could be a lot better at cleaning up tags. But staying under 50 for the whole namespace, not even just registry, is going to incredibly difficult.
A fair while ago, we used self-hosted and swapped to SaaS because it was the same price and we didn't have to deal with upgrades etc - and we used our own CI runners anyway. Is the unspoken intention to force users like us onto self-hosted? Should we instead be using a non-GitLab registry to store this stuff?
Very long term GitLab user, very disappointed by this.
> You can define container cleanup policies within the registry, matching on age, tags, etc. https://docs.gitlab.com/ee/user/packages/container_registry/...
As a long time GitLab user, and a user who championed the adoption of GitLab by a previous employer, this is highly disappointing. This basically eliminates GitLab as a viable option to some SMEs and specially for personal projects that relied on GitLab to build Docker images and deploy them as part of the CICD pipeline.
I just checked a personal project I have hosted in GitLab that does nothing more than pulling a Docker image, do a minor tweak and deliver the image to the container registry, and the Docker image build step alone adds ~100MB to the usage quotas each time the pipeline is triggered.
I'm sorry to say, but if this plan stays as is, GitLab ceases to be an option.
As a long time GitLab user, and a user who championed the adoption of GitLab by a previous employer, this is highly disappointing. This basically eliminates GitLab as a viable option to some SMEs and specially for personal projects that relied on GitLab to build Docker images and deploy them as part of the CICD pipeline.
I just checked a personal project I have hosted in GitLab that does nothing more than pulling a Docker image, do a minor tweak and deliver the image to the container registry, and the Docker image build step alone adds ~100MB to the usage quotas each time the pipeline is triggered.
I'm sorry to say, but if this plan stays as is, GitLab ceases to be an option.
Thanks. 2 more questions:
- 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)?
- 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)?
The FAQ contains information on how to manage your storage which will be helpful for top-level namespace exceeding 5GB in storage: https://about.gitlab.com/pricing/faq-efficient-free-tier/#ma...
> If you require 15GB storage, you will pay $120 for the year.
This sounds like a lot, just so I can keep my native Windows/Linux/MacOS builds online. My current usage need is 14.9gb.
This sounds like a lot, just so I can keep my native Windows/Linux/MacOS builds online. My current usage need is 14.9gb.
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.
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.
The core is open source so if that happens, you can fork it and do the hard work of supporting it yourself!
[deleted]
Seems like free tier limitations does not apply to a public group as top namespace, that contains private subgroups and repositories. This would kind of help a lot!
GitLab team member here! User Limits will not apply to a public group as a top namespace and as at this time, no limit on private groups within a public top namespace group. See the 6th Q&A entry in the FAQ page (https://about.gitlab.com/pricing/faq-efficient-free-tier/#us...), excerpt here:
> Q. Do these changes apply to private projects within a top-level namespace with public visibility? A. User limits are currently applied based on the visibility of the top-level namespace. We will monitor how top-level namespaces with public visibility are using private projects to identify whether any limits on such projects are needed.
> Q. Do these changes apply to private projects within a top-level namespace with public visibility? A. User limits are currently applied based on the visibility of the top-level namespace. We will monitor how top-level namespaces with public visibility are using private projects to identify whether any limits on such projects are needed.
Great news!!!
Anyone able to comment on this? Difficult to check before the new limits' deadline though...
For the free tier of GitLab SaaS, user limits will apply only to top-level namespaces that are private. Public namespaces will not have user limits at this time.
Storage limits will apply to both private and public namespaces.
Storage limits will apply to both private and public namespaces.
Sounds reasonable. In general I think price for any cloud based service will go up until Cloud is obvious solution stop being applied in all contexts.
Anytime I read about price increases with gitlab I am wondering if we should just have a well designed python library for all our CI needs.
I'm fine with this would have minded an extra month's notice but fine with it. It is free after all!
How painful is it to self host Gitlab on your own server ? Number of hours of maintenance per month
$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.