GitLab SaaS Free Tier FAQ
about.gitlab.com
about.gitlab.com
$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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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.
But yes, if you have public repos repoa/repoa and repob/repob instead of user/repoa and user/repob, then my understanding is both repoa and repob will hae 5GB each.
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.
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/...
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.
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.
- 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.
> 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.
Storage limits will apply to both private and public namespaces.