Toward the end of 2016 and at the start of 2017, there was a public debate in the GitLab community about whether reverting back from the cloud to bare metal would be cost-effective for GitLab.com. At the time, the filesystem used for repositories was Ceph. The performance of that distributed filesystem was not good enough to handle GitLab.com. They asked the community for advice and received a lot of feedback from people who experienced similar moves firsthand. In the end, the decision was made to stay in the cloud (https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/). Instead, GitLab would focus on creating a solution, not on the filesystem level, but making sure that Git input/output (I/O) behavior is better managed at the application level. This can be seen as the birth of the Gitaly component. Sid Sijbrandij emphasized the importance of being a software company, not an infrastructure company.

In August 2018, GitLab migrated their cloud-based offering, GitLab.com, from Azure to Google Cloud Platform (GCP). The main reason for switching to GCP according to CEO, Sid Sijbrandij was as follows:

It seems the move paid off; users have reported that GitLab.com is noticeably faster. Another transformation that is likely to cause further acceleration soon is the move to using Kubernetes as a container orchestrator. This is an important part of their strategy to incorporate functionality in a lot of places in GitLab besides the autoscaling of GitLab runners. GitLab's own high-availability tool, GEO, was used to synchronize the data from one cloud to another. Running on Google's architecture also allows GitLab to utilize object-storage for particular features as well, such as Git LFS.