Skip to content

Switch from flat group runner minutes to X per-member

Problem to solve

Hard barriers on CI minutes are a serious hurdle to additional GitLab.com adoption. Our current model is too rigid. Currently, we provide groups on GitLab.com with a flat quantity of shared runner minutes:

  • Free/Bronze: 2,000 minutes
  • Silver: 10,000 minutes
  • Gold: 50,000 minutes

Once a group hits their respective limit, they're unable to run additional jobs. We should consider a model that scales with the needs of a group, and that does not block a group from running additional jobs.

Proposal

  • Remove fixed minute caps for groups on GitLab.com.
    • Individual groups at all plans should no longer have a fixed, unscalable bucket.
  • Move to count hours, not runner minutes.
    • Round up to the nearest hour.
  • Implement scalable plans for all groups, where each group receives X number of hours per group member.
    • Hours should continue to be tracked on a monthly basis.

In this iteration, we can continue to treat a group's limit as a hard limit (e.g. once you hit it, no more jobs run). Manage will ship a future iteration to allow groups to go beyond their limit and be billed monthly for the hourly overage.

  1. To the extent that self-hosted customers enforce limits too, I’d expect they’d still want to have a fixed limit so let’s not remove that option.
  2. Adding minutes per user means it scales, but there’s always the case where someone needs more minutes than they have allocated based on actual users. Sure, they could buy more users than they actually have, but that will have friction too since the $ cost won’t feel perfectly aligned.
  3. Bundling scaling minutes in with existing tiers without changing price means we’re giving all minutes away free, relative to the normal user cost you would have paid for self-hosted. That feels wrong and unnecessary.
  4. Given the above, I’d think offering fixed paid add-on minutes to a plan (either pre-paid or paid-in-arrears) would be a reasonable first step. It scales unbounded, aligns incentives between buyer and costs, and is intuitive.

Important note: we are not setting direct per-user limits as part of this change; only that group shared limits are set based on the number of users in that group.

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

  • Runner time for GitLab.com groups and individual namespaces is now based on hours.
  • Runner hours in GitLab.com groups scales with the number of members in the group.

Links / references

cc @erushton @jlenny @markpundsack

Edited by Jason Yavorska