GitLab is a complex system; it has a lot of moving parts. It's very useful to understand the architecture of GitLab.

At the core of GitLab is the GitLab web app. This is what you see and use everyday. This web app is built upon the Ruby on Rails framework. The database it connects to depends on your configuration, but GitLab advises you to use PostgreSQL.

GitLab is not directly connected to the Web, but it needs an app server and a web server to connect to the outside world. For the app server, Unicorn is used. For the web server, GitLab uses either Nginx or Apache; the GitLab team advises you to use Nginx.

There are a lot of things that need to run in the background. For example, when you push a commit to GitLab, it needs to check whether you referenced an issue or a merge request, and if you did, GitLab needs to create a comment on that item. In order to make all of this work, GitLab uses a background worker called Sidekiq; every item that needs to be processed is called a job. You can see what jobs are being processed by Sidekiq by visiting http://gitlab.example.com/admin/background_jobs. You need to be an admin in order to see this page.

GitLab also needs to talk to Git. In order to simplify this, the GitLab team has created a layer over Git that is called GitLab Shell. This means that GitLab does not talk directly to any of your Git repositories but always uses GitLab Shell to do so. GitLab Shell is also responsible for queuing the jobs in Sidekiq.

There is one last component that is important: the Gitlab satellites. For every project you have running on GitLab, the system creates a copy; these copies are called satellites. When you try to merge a merge request, GitLab will check the satellite to see whether the merge request is actually mergeable. It also uses the satellites for the web editor.

To make everything a little more easy to understand, I have created a very simplified schema of the architecture.