How GitLab runs a giant Rails monolith in the open
GitLab is an open-core platform that covers source control, CI/CD and security in one app, and GitLab.com is the largest install of it. The stack is a deliberately boring Ruby on Rails monolith with PostgreSQL, Redis and Sidekiq, plus Go services for the hot paths, running on Google Cloud and Kubernetes.
Co-founder Dmitriy Zaporozhets picked Rails even though he mostly wrote PHP at the time, partly because GitHub was built on it. CEO Sid Sijbrandij later defended the choice: the gem ecosystem gives the team great shoulders to stand on, and Rails conventions tell everyone where code belongs.
That last point matters for GitLab's mission that everyone can contribute. A newcomer can find their way around a huge codebase because it follows the Rails happy path, and the team prefers boring solutions over clever tricks.
Sijbrandij put it bluntly: Ruby was optimized for the developer, not for running in production. So the code paths hit most often, or the ones that spend their time waiting on disk and network, were rewritten in Go.
The biggest result is Gitaly, a Go service that handles every Git call GitLab makes. It was built to remove the need for NFS for Git storage, and its stated goal is fault-tolerant horizontal scaling of Git storage, especially on GitLab.com. Today all application code reaches repositories through it.
GitLab.com used to run on Azure, and it was not ready for mission-critical work. In 2018 the team moved it to Google Cloud, citing the performance and consistency they needed, plus Kubernetes and price. They used GitLab's own Geo replication to copy the data and moved about 200 TB of CI artifacts, uploads and LFS objects into Google Cloud Storage.
The numbers improved quickly. Availability went from 99.61% before the move to 99.93% by April 2019, and daily errors dropped from an average of 8.2 to about one.
The VM-based setup was slow to scale and deploy, so in August 2019 GitLab.com started moving to Google Kubernetes Engine, beginning with the Container Registry. Web, API, Git traffic and Sidekiq jobs followed, all running from the same official Helm chart customers use.
The stateful parts stayed on VMs: PostgreSQL, Redis, GitLab Pages and Gitaly. A year in, the team reported much faster and safer deploys, though cross-zone network traffic became a new cost to watch.
The front end is a mix: Rails renders HAML pages, and Vue.js apps are mounted into them where the page needs interactivity. The frontend guide asks teams to keep the number of Vue apps per page low.
For data, GraphQL with Apollo is the default, and REST stays for simple HAML pages and older code. Vuex is deprecated in favor of Pinia or plain stateful components.
