Gitlab hero border pattern left svg Gitlab hero border pattern right svg Subscriptions

How subscriptions work subscriptions work slightly differently to Self-managed licenses. Unlike Self-managed licenses which grant equal access to features across an installation, subscriptions are applied to namespaces on (typically groups). Members of groups that have subscriptions applied to them will enjoy those features anywhere within the licensed namespace. For example, if BigCorp has a Gold license, the sub-groups BigCorp/Frontend, BigCorp/Backend will each have access to Gold features and share a common pool of Shared Runner minutes.

Common Misconceptions

  1. Misconception: If I'm in a Gold group, my profile should say "Gold"
    • Reality: subscriptions are scoped to a namespace, and individual users could participate in many groups with different subscription types. For example, they might have personal projects on a Free subscription type, particpate in an open-source project that has Gold features (because it's public) while their company has a Silver subscription.
  2. Misconception: Subscriptions grant "the midas touch" and any group or project a subscription-bearing user creates will get the features of their subscription level. i.e. a Gold user will be able to create Gold groups in which all members will have Gold features.
    • Reality: Subscriptions can be applied to any namespace all items created within said namespace will receive the features of the subscription level.
    • Reality: Applying a subscription to a personal namespace will mean that group-level features will not be present in any groups that user creates.
  3. Misconception: A license key will be emailed out and applied somewhere in the UI of
    • Reality: Subscriptions are managed, and applied, through on a linked account
  4. Misconception: Someone in accounting made the purchase and can pass along the subscription to the team using it.
    • Reality: Subscriptions are managed by a account who has Owner in the group.
  5. Misconception: I should purchase my subscription first before setting up accounts on
    • Reality: You can do this in any order, most will find it easier to set things up on .com before they purchase, with the exception of those who want to set up SAML.
  6. Misconception: I can apply different subscription levels to subgroups.
    • Reality: Subscriptions are applied to top level groups; sub-groups inherit their license (and Shared Runner minutes) from the top-level group.
  7. Misconception: Minutes are deducted from my group for any jobs that are run, even on my personal runners.
    • Reality: Runner minutes are deducted only from jobs run on Shared Runners, you can set up your own runners per project or group without affecting your shared minutes.


  1. Trials should be initiated by users by going to the Settings page of the group that they want to apply the trial to.
  2. At writing (2019-06-05) Silver and Bronze trials are not generally available. Support can manually downgrade a trial by request
  3. At writing (2019-06-05) Trials must be manually downgraded before a purchase can be made.
  4. Support is not included with trials Please participate in this issue

Common issues the Support Team encounters with sales-assisted purchases

  1. New Customers
    • The support team sometimes receives tickets in Zendesk from sales-assisted clients with basic questions like how to set up groups, how to add additional users, why subscriptions are applied to groups vs users, permission questions, etc. Support will direct them to corresponding documentation to address their questions.
    • Customers are typically not aware that creating an account in the customer portal does not create an account on or how to link a customer portal account to their account.
  2. Upgrades/Downgrades
    • There is presently not a self-service way for customers to upgrade/downgrade subscriptions so any of these requests must go through the sales team via a queue in Zendesk.
    • Requests can sometimes be delayed by the volume or lack of information provided when the ticket is sent to Sales.

How we can set the customer up for success

The best way to assist a user or system admin on any new platform is to arm them with the resources they will need when questions arise. During the onboarding process after the sale, the user/admin will receive an email from GitLab with pertinent information about their subscription. Highlight this and encourage them to save it somewhere easily accessible. While many of the links below are included in the email, it would be helpful to review each of the following resources personally with the user/admin.

  1. GitLab Documentation
  2. Administrator Documentation (self-managed only)
  3. Subscription setup and management
  4. Licensing and subscription FAQ
  5. Uploading your license (self-managed only)
  6. Features available by plan: & Self-Managed
  7. Support portal
  8. Statement of Support

A few more best practices to ensure a smooth start

  1. On this page, you'll read about differences between and Self-Managed functionality. Whenever in doubt, don't hesitate to ask us about a particular feature/functionality which is important to your prospect prior to promissing it is available. For a question like this, contact us on Slack in the #support_gitlab_com or #support_self-managed channel.
  2. Be sure to stress to the new user/admin to submit their support issues directly to us via the Support Portal instead of using you as a go-between. This will provide the most timely and comprehensive support we can offer.
  3. If you find yourself having to submit something on behalf of the user/admin, do not submit a ticket via the Support Portal/Zendesk. Instead, create an issue in dotcom-internal.
  4. For, make sure the user understands how to link their account to the customers portal and how to associate their group with their subscription. See managing subscriptions page for instructions.

Important differences between and Self-Managed subscriptions

The Pricing page includes a "Frequently asked questions for" section that answers "What features do not apply to" in detail. Here are some highlights:

  1. Features availability including SAML/LDAP is Core vs. SAML SSO is Silver.
  2. Access controls: customer is admin on GitLab instance vs. group owner on
  3. Log information and auditing: unrestricted access vs. no access on (can work with Support/Security to answer questions)
    • On, each user is "signing a contract" (TOS, privacy policy, etc) as individuals, regardless of what email domain they use. Because of that, we cannot provide their employer with any personally identifiable information (like email address, log info, etc.) as it would be a violation of the user's contract.
  4. Instance wide settings: custom vs. same for all users
  5. Infrastructure: manage your own, anywhere vs. GitLab manages HA Architecture, instance level backups/recovery, upgrades, based in US