GitLab Dedicated

Tier: Ultimate Offering: GitLab Dedicated

GitLab Dedicated is a single-tenant SaaS solution, fully managed and hosted by GitLab. GitLab Dedicated operators and tenant administrators can use Switchboard to provision, configure, and maintain their tenant environments.

For more information about this offering, see the subscription page.

Architecture

This page collects a set of architectural documents and diagrams for GitLab Dedicated.

High-level overview

The following diagram shows a high-level overview of the architecture for GitLab Dedicated, where various AWS accounts managed by GitLab and customers are controlled by a Switchboard application.

Diagram of a high-level overview of the GitLab Dedicated architecture.

When managing GitLab Dedicated tenant instances:

  • Switchboard is responsible for managing global configuration shared between the AWS cloud providers, accessible by tenants.
  • Amp is responsible for the interaction with the customer tenant accounts, such as configuring expected roles and policies, enabling the required services, and provisioning environments.

GitLab team members with edit access can update the source files for the diagram in Lucidchart.

Tenant network

The customer tenant account is a single AWS cloud provider account. The single account provides full tenancy isolation, in its own VPC, and with its own resource quotas.

The cloud provider account is where a highly resilient GitLab installation resides, in its own isolated VPC. On provisioning, the customer tenant gets access to a High Availability (HA) GitLab primary site and a GitLab Geo secondary site.

Diagram of GitLab-managed AWS accounts in an isolated VPC containing a highly resilient GitLab installation.

GitLab team members with edit access can update the source files for the diagram in Lucidchart.

Gitaly setup

GitLab Dedicated deploys Gitaly in a sharded setup, not a Gitaly Cluster. In this setup:

  • Customer repositories are spread across multiple virtual machines.
  • GitLab manages storage weights on behalf of the customer.

Geo setup

GitLab Dedicated leverages GitLab Geo for disaster recovery.

Geo does not use an active-active failover configuration. For more information, see Geo.

Optionally, private connectivity is available for your GitLab Dedicated instance, using AWS PrivateLink as a connection gateway.

Both inbound and outbound private links are supported.

Diagram of a GitLab-managed AWS VPC using AWS PrivateLink to connect with a customer-managed AWS VPC.

GitLab team members with edit access can update the source files for the diagram in Lucidchart.

Hosted runners for GitLab Dedicated

The following diagram illustrates a GitLab-managed AWS account that contains GitLab runners, which are interconnected to a GitLab Dedicated instance, the public internet, and optionally a customer AWS account that uses AWS PrivateLink.

Diagram of hosted Runners architecture for GitLab Dedicated.

For more information on how runners authenticate and execute the job payload, see Runner execution flow.

GitLab team members with edit access can update the source files for the diagram in Lucidchart.

Get started

To get started with GitLab Dedicated, use Switchboard to:

  1. Create your GitLab Dedicated instance.
  2. Configure your GitLab Dedicated instance.
  3. Create a hosted runner.