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.
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, when a user meets the definition of an enterprise user, information can be shared and actions can be taken based on a top-level group owner's request.
However, in situations where proof of account ownership is required, then a request is still required from the relevant user, not just the group owner.
A request can be worked on without explicit permission from the account holder if the user meets the definition of an Enterprise User, meaning all of the following are true:
Owner in the top-level of a paid group.