FE: Add `User Cap` setting for licensed self-managed GitLab

Problem to solve

Licensed self-managed customers paying for users beyond what the company/organization has budgeted for, or can afford.

There is not currently a method of setting a "maximum" or "limit" on seats or users for customers using licensed self-managed instances.

New user logging-in, doing almost anything, and logging-out will take a license seat. License seats can cost up to $1199 per user, per year.

Intended users

• Bobby the Business Owner - "If we spend more than $X this quarter/year, there will be severe consequences"
• Suzie the Accountant - "We have $X money in the bank, we can't spend more than $X."
• Delaney (Development Team Lead)
• Sidney (Systems Administrator)
• Sam (Security Analyst)

Further details

Business use case:

Company/org can only afford x licenses users in their annual budget. They'd like to keep new users sign up enabled on their instance but ensure sure they do not exceed users beyond what they can afford.

Example

Customer, about to write a check to Software Company: I have X thousand dollars that I'm prepared to give you, but I absolutely cannot spend any more than that. Times are tough and budgets are tight, what can I do to make sure we don't spend more than we can afford?

• Option A (how it is today): Turn off new user creation.
• Option B (coming soon): Tell your Systems Administrator to look for banners about overages in the web interface and let your accounting team know when he sees them.
• Option C (what I'm proposing here): "check out this feature you can opt-in to and configure based on your budget to make sure you don't spend more than you can afford!"

Proposal

Add an optional "Max User" setting for licensed self-managed GitLab instances as a mechanism by which customers with a budget or financial constraints can set a "safe" limit to prevent overspending.

I propose this setting is off-by-default and opt-in only. In this case, only customers who definitely don't want to go over their licensed seats would use the limit feature. All customers who want to add users now and pay later would keep it disabled by default.

The idea is that new users and license seats can grow up to a customer-defined Maximum, and after reaching the limit, customers need admin to approve or create accounts new accounts or raise the limit.

Permissions and Security

This setting should be opt-in and configurable only for GitLab self-managed administrators.

Documentation

Availability & Testing

1. user cap is field is default to empty, and will be treated as unlimited
2. only allows non negative integer input, invalid input will result in an error message
3. any new sign-ups will require admin approval once the user cap in met.
4. once user cap is met, new sign-ups will trigger an email notification to admin.
5. when require admin approval for new sign-ups checkbox is checked, regardless of what number is set in user cap, all new sign-ups needs approval
6. when number of current user drops below user cap number, new sign-ups does not require approval
7. only admin has access to this setting

What does success look like, and how can we measure that?

Customers who need to configure max licensed users as a budgeting safeguard have an option to do so.

Zero change in all other situations.

Success is measured by if you can answer the following with "yes"

1. Is the max licensed users setting option off by default, opt-in only?
2. Do GitLab self-managed customers have a mechanism to limit their maximum expenses if they have a limited budget?

What is the type of buyer?

• Customers with a tight budget or limited amount of money to spend on DevOps tooling.
• Public sector and organizations with annual budgets that require approval. (quarterly billing and true-ups make it difficult to estimate the yearly cost for approval)
• Companies and organizations with budgets approved annually or quarterly. (we can pay this much per year/quarter, no wiggle room)

Is this a cross-stage feature?

It would affect Growth, Licensing and Renewals, and Support.

I this could be helpful in resolving license disputes to deflecting tickets where a customer writes to Support: "I did not intend for seats to be added beyond X, I didn't even realize that users could create new accounts that we'd get billed for. Now we cannot afford a license for these extra users".

---

Update: per this comment we are using User Cap for this feature.