GitLab Documentation

GitLab-Omnibus Helm Chart

These Helm charts are in beta. GitLab is working on a cloud-native set of Charts which will replace these.

Officially supported cloud providers are Google Container Service and Azure Container Service.

This work is based partially on: GitLab would like to thank Sergey Nuzhdin for his work.


This chart provides an easy way to get started with GitLab, provisioning an installation with nearly all functionality enabled. SSL is automatically provisioned as well via Let's Encrypt.

The deployment includes:

A video demonstration of GitLab utilizing this chart is available.



Networking Prerequisites

This chart configures a GitLab server and Kubernetes cluster which can support dynamic Review Apps, as well as services like the integrated Container Registry and Mattermost.

To support the GitLab services and dynamic environments, a wildcard DNS entry is required which resolves to the external Load Balancer IP.

To provision an external IP on GCP and Azure, simply request a new address from the Networking section. Ensure that the region matches the region your container cluster is created in. Note, it is important that the IP is not assigned at this point in time. It will be automatically assigned once the Helm chart is installed, and assigned to the Load Balancer.

Now that an external IP address has been allocated, ensure that the wildcard DNS entry you would like to use resolves to this IP. Please consult the documentation for your DNS service for more information on creating DNS records.

Configuring and Installing GitLab

For most installations, only two parameters are required:

Other common configuration options:

For additional configuration options, consult the values.yaml.

These settings can either be passed directly on the command line:

helm install --name gitlab --set,baseIP=,gitlab=ee,gitlabEELicense=$LICENSE, gitlab/gitlab-omnibus

or within a YAML file:

helm install --name gitlab -f values.yaml gitlab/gitlab-omnibus

Note: If you are using a machine type with support for less than 4 attached disks, like an Azure trial, you should disable dedicated storage for Postgres and Redis.

Choosing a different GitLab release version

The version of GitLab installed is based on the gitlab setting (see section above), and the value of the corresponding helm setting: gitlabCEImage or gitabEEImage.

gitlab: CE
gitlabCEImage: gitlab/gitlab-ce:9.1.2-ce.0
gitlabEEImage: gitlab/gitlab-ee:9.1.2-ee.0

The different images can be found in the gitlab-ce and gitlab-ee repositories on Docker Hub.

Note: There is no guarantee that other release versions of GitLab, other than what are used by default in the chart, will be supported by a chart install.

Persistent storage

By default, persistent storage is enabled for GitLab and the charts it depends on (Redis and PostgreSQL).

Components can have their claim size set from your values.yaml, along with whether to provision separate storage for Postgres and Redis.

Basic configuration:

redisImage: redis:3.2.10
redisDedicatedStorage: true
redisStorageSize: 5Gi
postgresImage: postgres:9.6.3
# If you disable postgresDedicatedStorage, you should consider bumping up gitlabRailsStorageSize
postgresDedicatedStorage: true
postgresStorageSize: 30Gi
gitlabRailsStorageSize: 30Gi
gitlabRegistryStorageSize: 30Gi
gitlabConfigStorageSize: 1Gi

Routing and SSL

Ingress routing and SSL are automatically configured within this Chart. An NGINX ingress is provisioned and configured, and will route traffic to any service. SSL certificates are automatically created and configured by kube-lego.

Note: Let's Encrypt limits a single TLD to five certificate requests within a single week. This means that common DNS wildcard services like and are unlikely to work.

Installing GitLab using the Helm Chart

You may see a temporary error message SchedulerPredicates failed due to PersistentVolumeClaim is not bound while storage provisions. Once the storage provisions, the pods will automatically restart. This may take a couple minutes depending on your cloud provider. If the error persists, please review the prerequisites to ensure you have enough RAM, CPU, and storage.

Once you have reviewed the configuration settings and added the Helm repository, you can install the chart. We recommending saving your configuration options in a values.yaml file for easier upgrades in the future.

For example:

helm install --name gitlab -f values.yaml gitlab/gitlab-omnibus

or passing them on the command line:

helm install --name gitlab --set,baseIP=,gitlab=ee,gitlabEELicense=$LICENSE, gitlab/gitlab-omnibus

Updating GitLab using the Helm Chart

Once your GitLab Chart is installed, configuration changes and chart updates should we done using helm upgrade

helm upgrade -f <CONFIG_VALUES_FILE> <RELEASE-NAME> gitlab/gitlab


Uninstalling GitLab using the Helm Chart

To uninstall the GitLab Chart, run the following:

helm delete <RELEASE-NAME>