Provides a general overview of how the (SaaS) context is different from other GitLab instances for Support Engineering


This page is meant to provide a general overview of how GitLab SaaS ( 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 Basics training module. Architecture 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 has certain customizations. These customization are applied through the chef-repo. Details of customizatons can be found in 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 Are Not Admins

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.

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 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.

Enterprise Users

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.

Proof of account ownership is required, either the relevant user or requesting owner can pass the verification process.

A user is considered an enterprise user when all of the following conditions are met:

  1. The user’s primary email has a domain that is owned by the company of the paid group, and
  2. The user account meets one of the following conditions:
    • was created 2021-02-01 or later.
    • has a SAML or SCIM identity tied to the organization’s group.
    • has a provisioned_by_group_id value that is the same as the organization’s group’s ID.
    • is a member of the organization’s group, where the subscription was purchased or renewed 2021-02-01 or later.

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.

SaaS tier requirement for SaaS Account and common requests

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 This is an interim solution until gitlab#416451 get solved.

Free users are eligible to request this. But reasoning must be carefully considered, and manager approval is needed.
Email typo No See gitlab#325525 & gitlab#350498
Emails not received Yes
Log request Only if GitLab initiated
Namesquat release No
Trial Cancellation No See customers#3470
Last modified September 6, 2023: Update broken included markdown (3e1cd359)