Installing GitLab by using Helm
- Tier: Free, Premium, Ultimate
- Offering: GitLab Self-Managed
Install GitLab on Kubernetes by using the cloud native GitLab Helm chart.
Assuming you already have the prerequisites installed and configured,
you can deploy GitLab with the helm command.
The default Helm chart configuration is not intended for production. The default chart creates a proof of concept (PoC) implementation where all GitLab services are deployed in the cluster. For production deployments, you must follow the Cloud Native Hybrid reference architecture.
For a production deployment, you should have strong working knowledge of Kubernetes. This method of deployment has different management, observability, and concepts than traditional deployments.
In a production deployment:
- The stateful components, like PostgreSQL, Redis or Gitaly (a Git repository storage dataplane), must run outside the cluster on PaaS or compute instances. This configuration is required to scale and reliably service the variety of workloads found in production GitLab environments.
- You should use Cloud PaaS for PostgreSQL, Redis, and object storage for all non-Git repository storage.
If Kubernetes is not required for your GitLab instance, see the reference architectures for simpler alternatives.
Container images
The GitLab Helm chart uses the Cloud Native GitLab (CNG) container images to deploy GitLab. Besides the CNG images for GitLab itself, the default configuration uses images published by third parties (for example, Bitnami) to deploy PostgreSQL, Redis, and MinIO to simplify non-production deployments.
Production instances should not deploy these (stateful) third party services with the GitLab chart as mentioned above.
Refer to the following documentation for instructions on how to configure the chart to use external services.
Starting in December 2024, Bitnami changed its build policy to update only the latest stable major version of each application in the free catalog. The GitLab chart will continue to default to publicly available images.
In July 2025, Bitnami announced it will require a subscription to Bitnami Secure Images, a paid offering, for users to get access to secure and versioned charts and images.
As a result, the versions of these Bitnami charts configured by GitLab will fall out of date. Teams that deploy these Bitnami charts for non-production use should take care to use appropriate up-to-date, patched images commensurate with their security requirements.
Configure the Helm chart to use external stateful data
For production-grade deployments, you should configure the chart to point to external object storage, Valkey/Redis, PostgreSQL, and Gitaly services that match with your selected reference architecture.
While the GitLab chart bundles MinIO, PostgreSQL, and Redis charts for proof-of-concept and testing scenarios, these components and charts have experienced several project and licencing changes upstream impacting our ability to maintain them.
If you are running a production system with one of these bundled charts, you should migrate to external solutions.
Use the reference architectures
The reference architecture for deploying GitLab instances to Kubernetes is called Cloud Native Hybrid specifically because not all GitLab services can run in the cluster for production-grade implementations. All stateful GitLab components must be deployed outside the Kubernetes cluster.
Available Cloud Native Hybrid reference architectures sizes are listed at Reference architectures page. For example, here is the Cloud Native Hybrid reference architecture for the 3,000 user count.
Use Infrastructure as Code (IaC) and builder resources
GitLab develops Infrastructure as Code that is capable of configuring the combination of Helm charts and supplemental cloud infrastructure:
- GitLab Environment Toolkit IaC.
- Implementation pattern: Provision GitLab cloud native hybrid on AWS EKS: This resource provides a Bill of Materials tested with the GitLab Performance Toolkit, and uses the AWS Cost Calculator for budgeting.