Lets get started.<\/p>\n
What is Gitlab<\/h2>\n
GitLab is a popular DevOps tool<\/a> that combines version control, CI\/CD<\/a>, and project management<\/a> tools.<\/p>\n It is a end to end platform that can handle the complete software development lifecycle. It is a perfect fit for organisations that needs a unified platform instead of multiple tools.<\/p>\n Companies like Agoda, Airbus, CERN, Goldman Sachs, and NVIDIA use GitLab for their CI\/CD and DevSecOps implementations.<\/p>\n Overall Gitlab offers the following.<\/p>\n Overall, it has everything integrated in one place rather than managing multiple separate tools.<\/p>\n The following outlines the architecture of GitLab and how its components interact with one another.<\/p>\n Here is how all the components work together, as shown in the above arcitecture diagram.<\/p>\n All these components need to work with GitLab properly. We can explore them in the next section.<\/p>\n Once of the key requirement of DevOps engineers is to understand the core architecture of Gitlab. Becuase,you cant optimize or fix what you dont understand.<\/p>\n By understanding the core architecture, you can trohbleshoot, scale, perform upgrades, integrations and more.<\/p>\n GitLab consists of many components. We broke down each component and explained what each component does. Lets get started.<\/p>\n GitLab uses the Nginx<\/a> web server as the reverse proxy<\/strong> for user requests.<\/p>\n This proxy <\/a>even handles the SSL\/TLS termination to encrypt the traffic between the user and GitLab.<\/p>\n We can interact with GitLab in two ways: directly from a web browser using the User Interface (Web UI), and through API calls, primarily for programs to interact with.<\/p>\n GraphQL<\/strong><\/b> is efficient for complex queries, modern integrations, UI applications<\/div>\n<\/div>\n GitLab core is built on the Ruby on Rails web application framework.<\/p>\n When you perform an action in Gitlab, several components work together at the backend to handle the requests.<\/p>\n It starts with <\/strong>Puma<\/strong><\/a>. It is a web server<\/strong> of GitLab that listens to HTTP requests. It forwards the requests to the Rails application.<\/p>\n Rails<\/strong> follows the Model-View-Controller (MVC)<\/strong><\/a> pattern. When Puma passes the request to Rails, it routes to the appropriate Controller<\/strong> to tell what action should be performed.<\/p>\n Workhorse<\/strong> is a reverse proxy<\/strong> that sits in front of Puma.<\/p>\n It handles<\/strong> slow and large HTTP requests <\/strong>(e.g., Big uploads\/downloads). Once it picks the larger requests, it forwards the remaining time-sensitive requests to Puma.<\/p>\n We can access the shell of GitLab over the SSH protocol to download the code and upload the changes from the local to the remote.<\/p>\n We use the standard authentication methods to securely perform these Git operations on GitLab.<\/p>\n The storage and access of Git in GitLab is handled by Gitaly<\/strong>.<\/p>\n The storage of the GitLab for the code we store<\/strong> is managed by a service called Gitaly<\/strong>.<\/p>\n The requests come from Rails and Shell for the Git operations, such as push, commit, MR, etc. These components talk to Gitaly through the gRPC<\/strong> protocol.<\/p>\n Sidekiq is a background job processing<\/strong> unit for long running tasks. <\/p>\n For example, a task needs to send hundreds of emails to users, and Rails creates a job queue in Redis.<\/p>\n The Sidekiq workers then pick them and execute. So the main requests will not be affected.<\/p>\n Redis<\/strong> server is an in memory store<\/strong> of GitLab to store the temporary data for the following key operations.<\/p>\n All the long lived data will be stored in the PostgreSQL<\/a> database.<\/p>\n PostgreSQL<\/strong> is a relational database that stores long lived data<\/strong> like user account information, project information, permissions, issues, and MR, pipeline metadata, registry metadata, etc.<\/p>\n In Gitlab, every project has a bare repository<\/strong> on the server side. It is a special type of Git repository that does not have a working directory.<\/p>\n Normally, in a local Git repository, the In GitLab, only this In short, the bare repository in GitLab exists mainly to implement core Git functionality (git push, git pull etc)<\/p>\n Also, all GitLab components, such as GitLab Rails, GitLab Shell, and Gitaly, work together to handle these Git operations, whether they come through HTTP or SSH.<\/p>\n We have already looked at the storage components of GitLab individually. <\/p>\n Overall, here is how storage works in Gitlab.<\/p>\n When implementing Gitlab in DevOps projects<\/a>, scaling & avaialbilty ]becomes a key part when the projects grow. For example, if a central platform team provides GitLab as a service, many teams may onboard to the same GitLab instance.<\/p>\n In such cases, you dont need to scale the entire GitLab system at once. Instead, you can scale individual components based on the workload and requirements.<\/p>\n For example, PostgreSQL, Redis, and Gitaly are the stateful components<\/strong> and these handle heavy I\/O and background operations. So instead of running them a single instances, you can deploy them a clusters.<\/p>\n The replicas in the clusters should span multiple zones<\/strong> for high availability. Also, periodic backups will help in disaster recovery <\/a>scenarios.<\/p>\n GitLab by default, provides the standard login using username and password. Additionally you can enable Two-Factor authentication to improve security.<\/p>\n For enterprise setups, you can use the external <\/strong>authentication providers<\/strong><\/a> such as LDAP, SAML, or OAuth2 for the user authentication.<\/p>\n To securely access the GitLab shell for the Git operation, we can use the Secure Shell (SSH)<\/a> method.<\/p>\n For API based authentication, you can use the Personal Access Tokens (PATs) or Bearer Token.<\/p>\n We can control access to Gitlab by assigning permissions to users or applications, specifying what actions they are allowed to perform and on which resources.<\/p>\n GitLab follows a hierarchical permission model<\/strong>, where access can be granted at either the group level or the project level.<\/p>\n The following are the roles that we can assign.<\/p>\n A Self-hosted GitLab insrtance can be monitored using Prometheus <\/a>and Grafana<\/a>. We can track all the performance, system health and issues using its internal metrics and visualize them on dashbaords<\/a>.<\/p>\n GitLab also stores logs for all its components in a central location at Thats a wrap!<\/p>\n In this blog, we have looked at the Gitlab architecture and how all the key components interact behind the scenes.<\/p>\n We also discussed important topics such as storage, scalability, authentication, and authorization, which are very important in enterprise environments.<\/p>\n To know more about how real organizations use GitLab for their project, you can refer to this official documentation.<\/a><\/p>\n In the upcoming blogs, we will cover the setup and configurations of GitLab.<\/p>\n\n
GitLab Architecture<\/h2>\n
![\"The](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/10\/image-4.png\")
\n
Core Components of GitLab<\/h2>\n
Proxy\/HTTP Server (Nginx)<\/h3>\n
GitLab Web UI \/ API<\/h3>\n
Controllers \/ Rails \/ Puma<\/h3>\n
GitLab Workhorse<\/h3>\n
GitLab Shell<\/h3>\n
Gitaly<\/h3>\n
Sidekiq<\/h3>\n
Redis<\/h3>\n
\n
PostgreSQL<\/h3>\n
GitLab Bare Repository<\/h3>\n
.git<\/code> directory stores all the data commits, branches, tags, and history.<\/p>\n.git<\/code> data is stored on the server. That is what forms the bare repository<\/strong>. This repository exists mainly for synchronization. <\/strong><\/p>\nGitLab Storage and Data Persistence<\/h2>\n
\n
GitLab Scaling and High Availability <\/h2>\n
GitLab Authentication<\/h2>\n
GitLab Authorization<\/h2>\n
\n
GitLab Monitoring with Prometheus & Grafana<\/h2>\n
\/var\/log\/gitlab\/<\/code>. You can use log collectors such as Fluent Bit to gather these logs and send them to a central logging<\/a> or monitoring system for further analysis.<\/p>\nConclusion<\/h2>\n
\n