GitLab Dedicated Architecture
![GitLab Dedicated Group logo](img/dedicated_team_logo.png)
Architecture
This page collects a set of architectural documents and diagrams for GitLab Dedicated.
High level overview
![High level overview diagram for GitLab Dedicated](img/high-level-diagram.png)
Tenant network
![Tenant network diagram for GitLab Dedicated](img/tenant-network-diagram.png)
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.
Note: GitLab Geo is not an “active/active” system. To learn more about how GitLab Geo works, see the solution overview page.
AWS PrivateLink connection
![AWS PrivateLink diagram for GitLab Dedicated](img/privatelink-diagram.png)
Hosted Runners for GitLab Dedicated
Architecture diagram
![Hosted Runners architecture diagram for GitLab Dedicated](img/hosted-runners-architecture.png)
For more information on how runners are authenticating and executing the job payload, see Runner Execution Flow.
Security of hosted runners for GitLab Dedicated
The following section provides an overview of the additional built-in layers that harden the security of the GitLab Runner build environment.
Hosted runners for GitLab Dedicated are configured as such:
- Firewall rules only allow outbound communication from the ephemeral VM to the public internet.
- Inbound communication from the public internet to the ephemeral VM is not allowed.
- Firewall rules do not permit communication between VMs.
- The only internal communication allowed to the ephemeral VMs is from the runner manager.
- VM isolation between job executions.
- Ephemeral runner VMs will only serve a single job and will be deleted right after the job execution.
- On-demand: Hosted runners can be connected to customers’ AWS accounts via a private link bypassing the public Internet.
Documents
Introduction This document is intended to be a high-level summary describing how the existing GitLab Dedicated architecture could be used as a foundation for deployment and operating large numbers of GitLab Cell instances.
Additionally, it explains certain decisions in the Dedicated architecture, and why these are beneficial to both GitLab Dedicated and GitLab Cells, and how they differ from other approaches, such as GitLab.com’s IaC, or GET.
Note to readers: Please keep in mind that this is not a critique of GitLab.