GitLab Tech Stack: Simplified Deep Dive
Ruby on Rails: The Core
What it is: The main framework GitLab is built on.
How it works simply:
- Handles web requests when you click around in GitLab
- Manages the database connections
- Renders the web pages you see
- Processes form submissions
Why it matters: Rails lets GitLab developers build features quickly. It's like LEGO blocks for web apps - pieces fit together in standard ways, making development faster.
Real-world impact: When you create a new issue or merge request, Rails handles the entire process from saving your data to showing you the updated page.
Go (Golang): The Performance Booster
What it is: A faster programming language used for specific parts of GitLab.
How it works simply:
- Handles Git operations (like clones and merges)
- Runs in separate services outside the main Rails app
- Processes the heavy lifting that would slow down Rails
Why it matters: Some operations would make GitLab slow if done in Ruby. Go is like adding a turbocharger to specific parts of the system.
Real-world impact: When you push code or clone a large repository, Go-powered services handle it, making these operations much faster than if they were done in Ruby.
PostgreSQL: The Data Storage
What it is: The database where all GitLab data is permanently stored.
How it works simply:
- Stores all your projects, issues, user accounts, etc.
- Organizes data in tables with relationships
- Handles complex queries efficiently
- Ensures your data stays consistent
Why it matters: Without PostgreSQL, GitLab would lose all your data when servers restart. It's like the filing cabinet that keeps everything organized.
Real-world impact: Every time you search for issues or filter merge requests, PostgreSQL is finding that information for you.
Redis: The Speed Layer
What it is: A super-fast temporary data store.
How it works simply:
- Stores data in memory (much faster than disk)
- Keeps track of background jobs
- Caches frequently accessed information
- Handles real-time features
Why it matters: Redis makes GitLab faster by storing frequently-used data in a format that can be accessed quickly. It's like having important papers on your desk instead of filing them away.
Real-world impact: When you see real-time updates in the UI or when background jobs process (like CI pipelines), Redis is coordinating this behind the scenes.
Sidekiq: The Background Worker
What it is: The system that processes work outside of web requests.
How it works simply:
- Takes jobs that would make the website slow
- Processes them in the background
- Handles retries if something fails
- Manages job priorities
Why it matters: Without Sidekiq, GitLab would feel sluggish because you'd have to wait for everything to finish processing before getting a response. It's like having assistants who handle paperwork while you keep helping customers.
Real-world impact: When you push code and a CI pipeline starts, Sidekiq is managing those jobs. When you get an email notification, Sidekiq sent it.
Vue.js: The Interactive UI
What it is: The JavaScript framework that makes GitLab's interface interactive.
How it works simply:
- Creates responsive UI components
- Updates the page without full reloads
- Manages user interface state
- Handles user interactions
Why it matters: Vue makes GitLab feel like a modern app instead of a series of page loads. It's like the difference between digital controls and manual knobs.
Real-world impact: The merge request interface uses Vue to update in real-time, showing comments and changes without refreshing the page.
NGINX: The Front Door
What it is: The web server that first receives all web traffic to GitLab.
How it works simply:
- Receives all incoming web requests
- Routes them to the right internal service
- Serves static files directly
- Handles SSL encryption
Why it matters: NGINX efficiently manages connections so GitLab can handle many users at once. It's like a receptionist directing visitors to the right department.
Real-world impact: NGINX is why GitLab can serve thousands of users without crashing under the load of connections.
GitLab Workhorse: The Smart Router
What it is: A component that handles certain types of requests more efficiently.
How it works simply:
- Intercepts large file uploads/downloads
- Routes requests to the right backend service
- Bypasses the Rails app when possible
- Handles long-running connections
Why it matters: Workhorse prevents the main application from getting bogged down with certain types of requests. It's like having a shipping department handle packages so the sales team doesn't have to.
Real-world impact: When you upload large files or clone repositories, Workhorse manages these operations efficiently.
Gitaly: The Git Manager
What it is: A specialized service that handles all Git operations.
How it works simply:
- Manages Git repositories on disk
- Processes Git commands (clone, push, pull)
- Optimizes Git operations for performance
- Handles repository access control
Why it matters: Git operations are resource-intensive and would overwhelm the main application. Gitaly is like having a dedicated team just for handling source code.
Real-world impact: Every time you browse code, commit history, or push changes, Gitaly is doing the heavy lifting behind the scenes.
CI/CD Runner: The Pipeline Executor
What it is: The component that runs your continuous integration jobs.
How it works simply:
- Picks up jobs from the queue
- Creates isolated environments for each job
- Runs the commands in your .gitlab-ci.yml file
- Reports results back to GitLab
Why it matters: Runners let GitLab execute code in secure, isolated environments. It's like having testing labs separate from your main facility.
Real-world impact: When your tests run after a commit or your application deploys automatically, Runners are executing those processes.
Each of these components fits together to create a complete system that handles everything from storing your code to testing and deploying your applications. The beauty of GitLab's architecture is how these specialized components work together while each focusing on what they do best.
Simplied Archtecture Diagram
graph TB
%% External access points
HTTP((HTTP/HTTPS<br>Web & API Access))
SSH((SSH<br>Git Access))
%% Front-end components
NGINX[NGINX Web Server<br>Routes all incoming traffic]
GitLabWorkhorse[GitLab Workhorse<br>Smart proxy & file handling]
GitLabShell[GitLab Shell<br>Handles SSH Git operations]
%% Core applications
Puma["Puma (GitLab Rails)<br>Main application server<br>Ruby on Rails"]
Sidekiq["Sidekiq<br>Background job processor<br>CI/CD, emails, hooks"]
%% Data storage
PostgreSQL[(PostgreSQL<br>Main database<br>Users, projects, issues)]
Redis[(Redis<br>Queue & cache service<br>Temporary data store)]
Gitaly[Gitaly<br>Git repository service<br>Written in Go]
%% Extensions
GitLabPages[GitLab Pages<br>Static website hosting]
Registry[Container Registry<br>Docker image storage]
%% Web Request Path
HTTP -- "1. TCP 80/443" --> NGINX
NGINX -- "2." --> GitLabWorkhorse
GitLabWorkhorse -- "3." --> Puma
Puma -- "4." --> PostgreSQL
%% Git SSH Path
SSH -- "1. TCP 22" --> GitLabShell
GitLabShell -- "2." --> Gitaly
%% Background Job Path
Puma -- "1. Queue job" --> Redis
Redis -- "2. Process job" --> Sidekiq
Sidekiq -- "3. Update results" --> PostgreSQL
%% Other connections
NGINX -- "TCP 8090" --> GitLabPages
NGINX --> Registry
GitLabShell --> GitLabWorkhorse
GitLabWorkhorse --> Gitaly
GitLabWorkhorse --> Redis
Puma --> Redis
Puma --> Gitaly
Sidekiq --> Redis
Sidekiq --> Gitaly
%% Legend
LegendBox[Legend:<br>Pink = External Access Points<br>Blue = Frontend Components<br>Green = Core Applications<br>Orange = Data Storage<br>Purple = Extension Services]
%% Styling with improved contrast
classDef external fill:#ff99cc,stroke:#000,stroke-width:3px,color:#000,font-weight:bold
classDef frontend fill:#99ccff,stroke:#000,stroke-width:2px,color:#000,font-weight:bold
classDef core fill:#99ff99,stroke:#000,stroke-width:2px,color:#000,font-weight:bold
classDef storage fill:#ffcc99,stroke:#000,stroke-width:2px,color:#000,font-weight:bold
classDef extension fill:#cc99ff,stroke:#000,stroke-width:2px,color:#000,font-weight:bold
classDef legend fill:#f8f8f8,stroke:#000,stroke-width:2px,color:#000,font-weight:bold
%% Apply styling
class HTTP,SSH external
class NGINX,GitLabWorkhorse,GitLabShell frontend
class Puma,Sidekiq core
class PostgreSQL,Redis,Gitaly storage
class GitLabPages,Registry extension
class LegendBox legend
%% Title as a note at the top
title[GitLab Tech Stack - Component Architecture]
class title legend