GitLab Cloud Native Chart 7.0

Along with the 16.0 release of GitLab, we have bumped the chart version to 7.0.

Summary of major changes

Upgrade path from 6.x

In order to upgrade to the 7.0 version of the chart, you first need to upgrade to the latest 6.11.x release of the chart. Check the version mapping details for the latest patch.

GitLab now defaults to using two database connections. Prior to upgrading, you can check that PostgreSQL max_connections is high enough (using more than 50% of the available max connections). You can verify this by running the following Rake task using the Toolbox container:

gitlab-rake gitlab:db:decomposition:connection_status

If the task indicates that max_connections is high enough, then you can proceed with the upgrade. If not, or you wish to remain on single connection, you can set the ci.enabled key to false prior to the upgrade.

Upgrade from 6.11.x

Please follow the upgrade steps for 7.0 release.

Major Changes


As part of the 7.0.0 release of this chart, we upgraded the default PostgreSQL version from 12.7 to 14.8. This is done by upgrading PostgreSQL chart version from 8.9.4 to 12.5.2.

This is not a drop in replacement. Manual steps need to be performed to upgrade the database. The steps have been documented in the upgrade steps.

Note that PostgreSQL 13 is the minimum required PostgreSQL version in GitLab 16.0. PostgreSQL 12 is no longer supported by GitLab 16.0 and later.

Bundled certmanager

The bundled certmanager chart is upgraded from 1.5.4 to 1.11.1. Depending on your cluster and tooling this may require manual interaction before upgrading.

Make sure your cluster version is supported by certmanager 1.11. The release supports Kubernetes 1.21 to 1.26 and OpenShift 4.8 to 4.13. See certmanager supported releases for more information.

The default certmanager configuration now uses the annotation. As a result, certmanager will use the existing Ingresses to complete ACME challenges instead of creating new ones. This change ensures compatibility with Ingress controllers that need the ingressClassName to be set.

OpenShift users may have to modify the Security Context Constraints to deploy certmanager 1.10+. See certmanager 1.10 release notes for more information.

In case you deploy any certmanager custom resources not managed by the GitLab chart, or use additional scripts or tooling related to cert-manager, please read through the potentially breaking changes of certmanager 1.6 to 1.11 before upgrading.

Disable in-place Ingress modification

Sometimes the logic of reusing existing Ingresses for validation is not suitable. For example, if you have IP allowlists or other restrictions on your Ingresses that makes them inaccessible to the public Internet.

To perform the ACME challenge validation with an Ingress created dynamically each time, from 7.7.0 you can set the global.issuer.useNewIngressForCerts value to true (defaults to false).

Setting useNewIngressForCerts to true requires the ingressClassName field to be supported by the Ingress controller. This field has been available from Kubernetes 1.18, but is not supported on all controllers, for example it is not yet available when using GKE Ingress.

In case you need to enable this field during an upgrade on an existing cluster running GitLab charts 7.0-7.6, please follow the upgrade instructions


The included bitnami/Redis sub-chart has been updated to version 16.13.2 from the previously installed 11.3.4. This also upgrades Redis from 6.0.9 to 6.2.7.

Manual steps are required prior to upgrading if using the bundled Redis. See Upgrade the bundled Redis sub-chart