This page is meant to provide a general overview of how the GitLab.com (SaaS) context is different from other GitLab instances (any self-managed instance).
Please note that how the following applies to day to day work should be covered by the various workflows the GitLab.com training including where to find more information and resources on these topics.
GitLab.com Architecture
GitLab.com is the largest known GitLab instance. It is taken care of by our infrastructure team.
The Support team should have a general understanding of the architecture along with how to access logs (Kibana) and error reports (Sentry) to troubleshoot reported issues.
Numerous Support team members including all primary .com focused ones also assist with incidents as CMOC.
Legal context
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.
Administration
With GitLab.com, GitLab (the company) is the administrator of the instance.
This has a number of consequences.
Users are not admins
Users including customers never have an admin role.
This means that none of the administrator documentations apply, and instance level settings are managed by infra.
Accounts belong to users
Due to the current way users register for accounts, terms apply to individual accounts and information should not be shared to others regardless of their affiliation.
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.
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license
