This page is meant to provide a general overview of how GitLab SaaS (GitLab.com) is different from self-managed instances of GitLab.
Please note that context for the following sections on this page should be covered by the various workflows that Support utilizes when working with GitLab SaaS along with the GitLab.com Basics training module.
GitLab.com is the largest known GitLab instance. It is monitored and maintained 24/7 by our infrastructure team.
The Support team should have a general understanding of its architecture along with how to access logs (Kibana) and error reports (Sentry) to troubleshoot reported issues.
As well, Support team members should be aware that Gitlab.com has certain customizations. These customization are applied through the chef-repo. Details of Gitlab.com customizatons can be found in GitLab.com custom limits
Numerous Support team members including all SaaS focused ones also assist with incidents as CMOC.
When signing up, users agree to our terms, which means they are bound by them as well.
Violation of terms, including DMCA and code of conduct, are taken care of by Security Operations.
With GitLab SaaS, GitLab (the company) is the administrator of the instance. This has a number of consequences, outlined below.
Users including customers never have an admin role.
This means that none of our administrator specific documentation will apply to end-users, and instance level settings are managed by our infrastructure team.
Due to the current way users register for accounts, terms apply to individual accounts and information should not be shared to others unless they are an Enterprise User as defined below.
Note: Only share information with a user if they have access to it.
While it can sometimes make support interactions more difficult or frustrating, even something as basic as the email address on an account should not be shared if it's not public, or the user has not provided us explicit permission to share it with the other individual.
As of 2021-02-01 when our terms were last updated, we introduced the definition of an enterprise user.
Enterprise user accounts belong to the company that purchased a GitLab subscription. This means when requested by an Owner in the top-level of a paid group, information can be shared about, and actions can be made on behalf of an enterprise user.
In situations where proof of account ownership is required, then either the relevant user or requesting owner can pass the verification process.
A user is considered an enterprise user when:
provisioned_by_group_id value that is the same as the organization's group's ID.Note: This means that the user's primary email must be in the company domain, but it need not be a member of the paid group, as that is only one of the possible conditions.
If the Owner is requesting access to an account which has a primary email in the company domain, but does not meet any of the second conditions, then we must treat the account as belonging to the user. In this case, the only recourse for the Owner is to send a request from the primary email account and then validate the account as a personal User account.
The relevant information can be found in the ZenDesk GitLab User Lookup, GitLab admin or API. Subscription information can additionally be found in CustomersDot.
Unpaid users get limited support as outlined in the statement of support. Most of the requests are related to user accounts through the "SaaS Account" ticket form.
The following table is meant to be a helpful quick reference. However, the source of truth in order:
| Request type | Available to Unpaid users | Notes |
|---|---|---|
| 2FA | No | See gitlab&3783 |
| Account Blocked | Yes | |
| Data Restoration | No | See gitlab#357175 |
| Email release | Yes | See gitlab#352514 |
| Email swap | Yes | See gitlab#16311 |
| Email typo | No | See gitlab#325525 & gitlab#350498 |
| Emails not received | Yes | See also gitlab#16311 |
| Log request | Only if GitLab initiated | |
| Namesquat release | No | |
| Trial Cancellation | No | See customers#3470 |