The Helm chart deploys Deckhouse Code directly to a Kubernetes cluster, without the Deckhouse Kubernetes Platform module. The chart deploys the application components and, when enabled, the container registry; the cluster and the services below exist before you install the release.
Helm
The chart is published as an OCI artifact and installs with the helm command line client. The chart prints a warning when the client is older than Helm 4.0, and asks you to test the configuration before upgrading when it is older than Helm 3.17, because that version changed how values are merged.
Ingress controller
An ingress controller runs in the cluster. The chart creates Ingress objects for the web interface, the container registry and, when enabled, Pages; they target the ingress class from global.ingress.class, which is nginx by default. The load balancer the chart deploys forwards HTTP and HTTPS to the Service ingress-nginx-controller.ingress-nginx.svc unless global.codeHelm.loadbalancer.ingressService names another one.
LoadBalancer Services
The chart deploys an HAProxy load balancer with a Service of type LoadBalancer that carries HTTP, HTTPS and Git over SSH on one external address. The cluster assigns external addresses to such Services through a cloud provider or an implementation such as MetalLB. When the cluster has none, disable the load balancer with global.codeHelm.loadbalancer.enabled: false and expose SSH through gitlab.gitlab-shell.service.type; see Load balancer.
cert-manager
cert-manager with the cert-manager.io/v1 API runs in the cluster. The chart uses it twice:
- for the Ingress certificates, signed by the ClusterIssuer from
global.codeHelm.ingress.tls.clusterIssuer(letsencryptby default); the ClusterIssuer exists before the install, orglobal.codeHelm.ingress.tls.modeis set tomanualand the certificates are supplied as Secrets; - for the internal certificates between the components, signed by a self-signed Issuer the chart creates itself.
StorageClass for Git repositories
Each Gitaly pod mounts a PersistentVolumeClaim for Git repositories, from the default StorageClass or from the class named in gitlab.gitaly.persistence.storageClass. The chart recommends 50Gi in gitlab.gitaly.persistence.size and takes 1Gi as the minimum. The volume grows with the repositories, so set the size they need.
PostgreSQL
An external PostgreSQL server of version 17 or later, reachable from the cluster, with the databases and roles below created in advance. The chart does not deploy PostgreSQL.
| Database | Values | Used by |
|---|---|---|
| Application database | global.psql.host, global.psql.database, global.psql.username | The web service, Sidekiq, the migrations job and the toolbox. |
| Praefect database | global.praefect.psql.host, global.praefect.psql.dbName, global.praefect.psql.user | Praefect, which routes Git traffic to Gitaly. Praefect is enabled by default, so this database is required. |
| Registry metadata database | registry.database.host, registry.database.dbname, registry.database.user | The container registry, only when registry.database.enabled is true. |
Redis
An external Redis server reachable from the cluster, addressed by global.redis.host and global.redis.port, holds background job queues, caches and sessions. The chart does not deploy Redis.
Object storage
An S3-compatible object storage with one bucket per store. Object storage is enabled by default and cannot be replaced with local volumes; the chart does not deploy a storage. The buckets and their values:
| Bucket | Value | Default name |
|---|---|---|
| Git LFS objects | global.appConfig.lfs.bucket | git-lfs |
| CI/CD artifacts | global.appConfig.artifacts.bucket | gitlab-artifacts |
| Uploads | global.appConfig.uploads.bucket | gitlab-uploads |
| Packages | global.appConfig.packages.bucket | gitlab-packages |
| Merge request diffs | global.appConfig.externalDiffs.bucket | gitlab-mr-diffs |
| Terraform state | global.appConfig.terraformState.bucket | gitlab-terraform-state |
| CI/CD secure files | global.appConfig.ciSecureFiles.bucket | gitlab-ci-secure-files |
| Agent plan content | global.appConfig.agentPlanContent.bucket | gitlab-agent-plan-content |
| CI/CD catalog bundles | global.appConfig.ciCatalogBundles.bucket | gitlab-ci-catalog-bundles |
| Dependency proxy | global.appConfig.dependencyProxy.bucket | gitlab-dependency-proxy |
| Backup archives | global.appConfig.backups.bucket | gitlab-backups |
| Temporary backup files | global.appConfig.backups.tmpBucket | tmp |
| Container registry | global.codeHelm.externalSecrets.registry.storage.s3.bucket, when the registry is enabled | — |
| Pages content | global.pages.objectStore.bucket, when Pages is enabled | gitlab-pages |
The storage endpoint and the access keys go into global.codeHelm.externalSecrets.s3, global.codeHelm.externalSecrets.backup and global.codeHelm.externalSecrets.registry.storage.s3; see Secrets created from values.
Access to the image registry
The cluster pulls the component images from the Deckhouse Code image registry. The credentials go into global.codeHelm.externalSecrets.registryDockerConfig as a Base64-encoded .dockerconfigjson; the chart turns them into the image pull Secret of every pod.
DNS names
The web interface answers at global.hosts.gitlab.name, the registry, when enabled, at global.hosts.registry.name and Pages, when enabled, at global.hosts.pages.name. A name that is not set is derived from global.hosts.domain as gitlab.<domain>, registry.<domain> and pages.<domain>. The names resolve to the external address of the load balancer Service, or to the address of the ingress controller when the load balancer is disabled; the address is known after the install, see Quick start.