Category Strategy - Cloud Native Installation


Stage Enablement
Maturity Viable
Content Last Reviewed 2020-03-06

Introduction and how you can help

Thanks for visiting this category strategy page for the Cloud Native Installation. This page belongs to the Distribution group of the Enablement stage and is maintained by Larissa Lane (E-Mail).

Your ideas and feedback are important to us and play a major part in shaping the product direction. The best way to provide feedback on scheduled improvements is by commenting on issues in the deliverable issues board. To create a new feature request, create an issue in the Charts project.

We are always looking for opportunities to interview GitLab users and learn more about your experiences using the cloud-native install to deploy a self-managed instance of GitLab. If you would like to share your experience and provide feedback throgh a video call, please email Larissa.


The cloud-native installation is used for deploying GitLab as a Kubernetes application. In this deployment method, GitLab is broken down into a cloud-native application structure comprised of GitLab services and resources that are distributed across a set of containers.

The GitLab Helm charts are used to deploy and manage the containers in Kubernetes. Additionally, the GitLab Operator has been developed to further improve the experience of managing the cloud-native deployment of GitLab. The Operator provides greater control over upgrades and makes it possible to perform rolling upgrades.

Cloud-native applications offer a number of benefits over the more traditional monolithic applications. Perhaps the greatest benefit is the ability to automatically scale individual services within the application to meet usage demand. We have seen significant growth in organizations adopting Kubernetes and increased interest in deploying GitLab in Kubernetes.

GitLab is committed to staying ahead of the curve in new developments for deploying applications and managing the underlying infrastructure that they run on. We already have a strong cloud-native offering, but we know we can make it even better. Our goal is to offer a full-featured, cloud-native version of GitLab that can be reliably used at any scale, even beyond our 50,000-user reference architecture.

Target Audience

Similar to the Omnibus category, the Cloud Native Installation is for organizations or teams that prefer to run their own instance of GitLab rather than use the hosted offering. This install method is specifically for teams wanting to run GitLab in Kubernetes.

It is also for GitLab's own admin team that is responsible for managing We are transitioning from using Omnibus to manage, to using the GitLab Helm charts and running parts of in Kubernetes. This allows us to more easily scale what is the world's largest instance of GitLab.

The user personas most likely to be working with the Cloud Native Installation are:

Challenges to address

Where we are Headed

The Cloud Native Installation is a newer deployment method for GitLab and it has come a long way since it was first launched. Almost all of the major features that are available in Omnibus GitLab are now available in the Cloud Native Installation, but it still doesn't support all of the features that are available in Omnibus GitLab. The two major features that are still missing are GitLab Pages and support for CAC cards. Pages is going through a redesign that includes adding support for object storage. As soon as this work is complete, we will prioritize adding support for Pages in the GitLab Helm chart. Adding support for CAC card authentication is expected to be unblocked in the near future when an issue with TLS authentication is resolved.

Previously, there had been occasional lags between the implementation of features within Omnibus GitLab and when they arrived in the Helm charts. We want to change this. In 2020, we will move towards releasing new features in Omnibus and Helm simultaneously. We know this won't always be possible because we sometimes get blocked by implementation decisions that are not supportable in Helm. However, we want our Helm users to have the latest and greatest GitLab features as soon as we can make it happen and we will continue addressing issues that cause a delay in adding them to the Helm chart.

GitLab has developed reference architectures for different scales of deployments. These reference architectures provide recommendations for architectures supporting anywhere from 2,000 to 50,000 users. These were originally created for Omnibus-based deployments. We will be going through the same testing and validation to make specific recommendations for Helm-based deployments so that we can provide more guidance to our Helm users.

The cloud-native documentation today is comprehensive, but it could be better. We will be focusing on making it even clearer, more thorough, and rethinking the information architecture to ensure you can easily find what you need. Epic:

GitLab is a large and complex application. If you are new to Kubernetes, it currently may not be the first application you want to start with. However, we will continue focusing on ways to simplify cloud-native deployments of GitLab so that users with minimal Kubernetes experience can easily use this deployment method. Improvements to the documentation mentioned above will provide more advanced users with the resources they need to customize and optimize their cloud-native deployments.

What's Next & Why

What is Not Planned Right Now

There is a lot planned for 2020, but there's more that we would like to do. For now, we will be relying on contributions from other teams and the community to improve support for running GitLab on container platforms such as OpenShift.

Maturity Plan

This category is currently at the Viable maturity level. Our next maturity target is Complete (see our definitions of maturity levels). We are aiming to reach the Complete level by Q3 of 2020, after which we will push on towards the Lovable maturity level.

Competitive Landscape