GitLab Helm Chart: When Dedicated Customer Releases Make Sense

Direct answer

The GitLab Helm chart deploys a cloud-native version of GitLab on Kubernetes. It requires external PostgreSQL, Redis, and object storage. For production, follow the Cloud Native Hybrid reference architectures. A release-per-customer model offers strong isolation but comes with significant operational complexity—this is a high-complexity reference architecture, not a one-click example.

What the GitLab Helm chart provides

The chart contains all required components to get started and can scale to large deployments. It is made up of multiple subcharts, each of which can be installed separately.

Key requirements for production:

External PostgreSQL database
External Redis cache
External object storage
Strong working knowledge of Kubernetes

The chart supports deploying either Enterprise Edition (ee) or Community Edition (ce). Different management, observability, and concepts apply compared to traditional deployments.

The use case: when dedicated GitLab per customer makes sense

GitLab is a resource-intensive application. Dedicated customer releases are appropriate when:

Data sovereignty requirements demand separate databases and storage per customer
Compliance boundaries require independent audit trails and access controls
Upgrade windows must be customer-specific rather than platform-wide
Performance isolation is required—one customer's CI/CD load should not affect another's
Contractual separation demands strong operational boundaries

However, the operational overhead is substantial. Each release requires its own PostgreSQL, Redis, object storage, and the full GitLab subchart suite. This is not a pattern for dozens or hundreds of tenants.

Reference architecture

customer GitLab profile
  → validate domain, database, and storage requirements
  → provision external PostgreSQL, Redis, and object storage
  → resolve tenant-scoped credentials
  → render GitLab values for one release
  → install into the tenant namespace
  → verify all subcharts are healthy
  → promote or roll back independently

The GitLab chart consumes per-service subcharts. For dedicated customer releases, each tenant gets its own full set of subcharts, external dependencies, and credentials.

Illustrative tenant declaration

tenant: acme
userspace:
  namespace: tenant-acme-gitlab
  domain: gitlab.acme.example
deployment:
  engine: helm
  template: gitlab
  release: gitlab-acme
  config:
    edition: ee
    externalPostgresql:
      host: postgres-acme.svc
      database: gitlab
    externalRedis:
      host: redis-acme.svc
    externalObjectStorage:
      provider: s3
      bucket: gitlab-acme
  secretScope: tenants/acme/gitlab

This is illustrative. A production GitLab declaration requires extensive configuration across all subcharts.

Production decisions before onboarding

External dependencies. GitLab requires PostgreSQL, Redis, and object storage. For dedicated releases, decide whether each customer receives dedicated service instances, dedicated databases on shared services, or a governed shared topology.

Subchart configuration. The chart is made up of multiple subcharts (webservice, sidekiq, etc.). Each subchart has its own configuration parameters. Tenant-specific values must be applied across all subcharts.

Storage and data. GitLab stores repositories, artifacts, and container images in object storage. Each tenant needs isolation at the bucket or path level. Persistent data (PostgreSQL, Redis) must be backed up per tenant.

Upgrades. GitLab upgrades can involve database migrations. Test the target version, back up the tenant database, and promote through controlled cohorts. A Kubernetes rollback cannot reverse an incompatible database migration.

Resource requirements. GitLab is resource-intensive. Each dedicated release needs significant CPU, memory, and storage. Plan capacity accordingly.

Evaluation checklist

Does every tenant have dedicated external PostgreSQL, Redis, and object storage?
Are database, Redis, and storage credentials isolated per tenant?
Can one tenant's CI/CD load affect another tenant's GitLab instance?
Are subcharts configured consistently across all tenant releases?
Can you upgrade one tenant, verify it, and stop the rollout?
Does offboarding remove all external dependencies and credentials?
Are backups and restores tested per tenant?

When shared GitLab is the better choice

A single shared GitLab instance is usually simpler and cheaper for internal teams or customers who can share infrastructure. Dedicated releases make sense only for a small number of high-value customers with strong isolation requirements. For most use cases, GitLab's built-in groups, projects, and permissions provide sufficient logical separation.

Sources

OpenTenant makes the decision explicit: dedicated GitLab per customer is a deliberate architectural choice, not a default.