GitLab introduces user limits for Free users on SaaS

I remember seeing that “400min cap on ci minutes” banner a while ago, thinking that since we have our own runners, it’s not something we have to worry about.

I just found about the users limit completely by accident, I use Gitlab daily and have not seen any notifications regarding this, and this is a month after it was initially scheduled to take effect.

The way these changes are handled and especially the communication aspect is very unprofessional, and while you say that this was not planned, maybe you didn’t plan for this exact change, but now there is absolutely no doubt in my mind that locking people into your platform and then trying to force them into paid tiers by removing features and changing limits is part of your plan.

It’s very hard not to speculate that you push the proper announcements of this change, simply to force people to change to your paid plan because they won’t have time to properly migrate to another provider when the notification eventually go out, and then hoping they will not bother changing since they at that point are already paying.

You say it will affect less than 2% of your users? All the people complaining about your platform simply becoming infeasible to use begs to differ. It looks like you are simply weeding out the users that you don’t expect to be able to convert into paying customers.

And that it causes significant costs? CI build minutes? - We have our own runners.
Put some limits on whatever causes you significant costs.

It’s fortunate that my company are in a position where we are able to migrate away from your saas offering.

My initial comment was deleted due to a bad word, so I have tried to recreate it from memory…
I do apologize about the inappropriate word usage though.

1 Like

In order to reduce our storage usage below the new 5gb user limits for the free version, I have been busy reducing the amount of storage used by deleting jobs and container tags. The deletion of jobs has reduced our storage usage, however I am still seeing a high number (over 100gb) in the container registry storage used section – even though I have deleted most images and tags. I am happy to pay for extra storage, but paying for 100gb additional storage of which I have no idea where it is exactly is difficult to justify.

3 Likes

Hi @berrange :wave:

I’m happy to offer an update here. We really appreciate your feedback and your care in laying out your concerns so precisely.

On August 19 2022, we updated the terms of the GitLab for Open Source Program Agreement to explicitly address those concerns. In particular, we made two key revisions:

  • We removed the obligation to pay past license fees in the event the software is used outside the purposes permitted in the agreement. Under the revised agreement, if GitLab determines a project no longer meets the Open Source Program’s eligibility requirements, we’ll connect with that project and allow 30 days to rectify the misuse. If after 30 days the project still doesn’t meet the eligibility requirements, the project has the choice to either terminate its membership in the Program (and the agreement) or pay for GitLab from the time the 30-day “cure period” expired. If the project doesn’t take any action, the agreement and the project’s membership will terminate automatically.

  • We’ve clarified that the obligations arising under the agreement, including those relating to the meeting of the eligibility requirements, fall not on the individual who accepts the agreement on behalf of an open source project, but on the project itself. Any project member who accepts the agreement on behalf of a project is assumed to have the authority to bind that project to the terms of the agreement.

The revised agreement applies automatically to everyone who either joins or renews their membership of the Program on or after 2022-08-19. Because the agreement has a one year term, the revised will apply to any renewing Program members if and when they choose to renew their membership in the Program.

We hope this helps clarify the Program’s terms and better aligns them with the spirit in which we maintain the GitLab for Open Source Program. Thanks again for sharing your concerns.

4 Likes

The date has been again changed, see the initial blog post Upcoming changes to user limits on Free tier of GitLab SaaS :

2022-08-16 UPDATE: User limits will not be applied before 2022-10-19. Also, user limits do not apply to top-level namespaces with only public projects. If you’re running an Open Source project, please also consider the GitLab for Open Source program which can provide more CI/CD minutes as well as additional storage.

Somehow I can’t work out how to reduce the storage size required by my docker containers. In my profile https://gitlab.com/-/profile/usage_quotas#storage-quota-tab, the container registry is shown to use 6.1GB of storage. However, when I go through all of my projects and look at the container registries, I can only find way less than 1GB of storage in total.

How can I find the items in my registries that are using up all this space so I can delete them?

1 Like

I have been using the following script to find which projects and repositories are using the space. It requires an API key with read_api permission and a user name and will process up to 100 repositories.

It outputs a list of all containers and their sizes for each project.

#!/usr/bin/env python3

from urllib.request import Request, urlopen
from urllib.parse import urlencode, urljoin, urlunsplit
import json

API_TOKEN = "…"
USER = "…"

def invoke(endpoint, args=None):
    url = urlunsplit((
        "https",
        "gitlab.com",
        urljoin("api/v4/", endpoint),
        urlencode(args) if args else None,
        None,
    ))
    req = Request(url, headers={"Private-Token": API_TOKEN})
    with urlopen(req) as res:
        return json.load(res)

for project in invoke(f"users/{USER}/projects", {"per_page": 100}):
    print(f"{project['name']}:")
    try:
        containers = invoke(f"projects/{project['id']}/registry/repositories")
    except Exception as exc:
        print(f"    {exc}")
        containers = []
    for container in containers:
        info = invoke(
            f"registry/repositories/{container['id']}",
            {"size": "true"}
        )
        print(f"    {container['name']}: {info['size']}")
1 Like

Bye bye gitlab!
I discussed this topic today with company owners. We are a small company with only 4 developers and other 2 or 3 external consultants. We used to have gitlab installed on our server, and decided one year ago to switch to saas for various reasons. Now we need to decide whether to return to previous set up, or switch to another company.

I was asked to do a comparison with other options:
gitlab 228$/user/year
github 44$
bitbucket 36$

So, no way to stay with gitlab saas, price is overkilling. I don’t know why you didn’t decide a different plan for small teams, but probably you have good reasons. As others commented, I understand the move from a business point of view, get rid of all the small companies that will generate little or no profit.

So thanks so far for the great platform and farewell.

3 Likes

Disappointment and something like disgust.
I’m a devops in a medium sized company and now I have to migrate all projects to github (there are enough of them).
Why do we have to pay $19 for features that we won’t even use?
Why can’t we only pay for what we really need? I only need an additional number of places in the project and all the free limits that the gitlab gave me are enough. Why can’t I just buy places in a group for a normal price? With a team of 100 people, I overpay $1500 every month if I had to buy a subscription.
To be honest, it’s a shame that due to lack of foresight and lack of an adequate understanding of the realities, the sales department (or whoever is responsible for these changes) ruined such a wonderful product.

3 Likes

This Q&A published in Gitlab’s official FAQ on the topic is puzzling me:

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.

Seems to suggest that if a free user owns a top-level public group A, and creates one private subgroup B under A, the 5-users limit does not apply to private repos under B. Is this assumption correct?

1 Like

I wish there would be ~5$ per user tier, don’t really wanna pay 20$ for each reporter, consultant, analytics and auditors. Gonna end up paying close to 8k across all orgs :sweat_smile:

Have used Gitlab since it’s early days, when it was down more than it was up and always promoted it over everything else. Just like to support underdog :yum:

Seems like Gitlab is going to be more enterprise now. Not blaming you, just hoping you did your decision carefully and it’s actually better for you. Would be sad to see one of the best competitors on market to die out coz of bad business decision

Was fun, but it’s time for me (and my teams) to start moving hundreads of repos to Github :slightly_smiling_face:
Might be back one day :wink:

1 Like

Thanks @jkuebart, this confirms again my suspicion that there are bugs in the system. Using your script I come to a total of 9.8GiB, while the usage quotas page states I am using 132.2 GiB for the container registry. So I am going to have to fork over $733 extra for a whole year (renews annually) to avoid having my account locked due to this bug… Mystifying…

1 Like

Are you perhaps hitting the 100 repo limit? If so let me know and I’ll have a look and add paging to the script…

1 Like

I do not have more than 100 repos, but thanks for your offer!

1 Like

Hello,

I’m reposting here one request that I shared in support ticket #326441

My company is a premium customer for GitLab for all our employees and all our projects. But we do run two other top-level namespaces in the free tier to collaborate with customers and partners, those use cases are specific and we don’t want to pay 230 USD/year for each user on those namespaces.

Customer support

One namespace is dedicated to customer support: we have one project per customer and we add multiple persons from each customer to the project so that they can report issues and we will reply to them in the issues that they opened.

This workflow is way superior to the use of the service desk feature:

  • each customer has full visibility on all the issues they opened
  • users are reporting issues with the web interface and we get proper formatting instead of the bad formatting you tend to have with the email input

So we have all our employees and many accounts for our customers, it would be a steep price for us to switch to premium on this namepace. Without any change on your side, we will move away from GitLab for this service. And yet we were driving new users to GitLab with this setup since many of our customers were not yet GitLab users.

One clean way to solve this problem would be to move the “Free guest user” feature to the “premium” offer. I don’t really understand why you restricted that to “ultimate”. Anything that drives more users to Gitlab is good and the ability to add “free guests” is certainly a sure way to encourage your customers to invite their customers/consultants/partners as guest in some projects dedicated to collaborating with them.

I have opened an issue requesting that move to the premium level:

Private file sharing and issue management: basic collaboration

We have another namespace where we add many sub-contractors that are working with us a few hours per month. We have a git repository used to collaborate: we document the work that they can do, they send their reports there too, we have a few issues to collaborate on some specific task. We are not using any CI/CD, it’s not used for any development, plain file sharing and issue management. No need for any fancy/advanced features.

Here again, you are driving us away from GitLab while GitLab was providing everything required. We are not opposed to pay for this service, but not on a per-head basis. As I said, many of the users on that project are working less than 10 hours per month for us, it doesn’t make sense to pay the premium price. I would be happy to pay something based on the disk/traffic usage and have a limited set of features (mainly issues). The former bronze offer was viable for us, but not the premium/ultimate one.

I hope this will help you to make better decisions and possibly reconsider some of your choices here.

Have a nice day.

1 Like

Hello it might be a silly question but would like to clarify?
Is this private project per group?

Example I have 2 groups
Group 1 has 5 users with 5 private projects
Group 2 has 10 users with 2 private projects
Group 1 and 2 has 15 users in total.
Does this mean that I’ll be charge 10 users per month?

If someone could clarify it much appreciated. Thank you!

John

1 Like

The way I understand it is per namespace. Therefore, group1 is one namespace, group2 is another namespace. Since a namespace has a limit of 5 for free users, then your namespace/group2 is over the free limit. So either needs to be reduced to 5 users, or you need to pay for the 10 users. There isn’t any differentiation of paid/free users, so you cannot have 5 free and 5 paid users, since the namespace still has 10 users at this point.

1 Like

I see thanks for clarifying.

1 Like

I have some doubts about what is considered a top-level namespace. If I have a user with x private projects and I include in these more than 5 users. Does it mean that I cannot have repositories at the level of my user with repositories with more than 5 members?

1 Like

I have a doubt about the user limit on the free tier of gitlab saas. In my case I have all my repositories with more than 5 users inside my personal namespace (not group or subgroup namespace). Have I to upgrade to premium in this case? What does mean top-level namespace? It’s not clear enought in the documentation

2 Likes

Is this enforced already? I still see something like … “6 / Unlimited” for “Seats in use / Seats in subscription” (under the group’s Settings / Usage Quota). Anyone else?

1 Like