Configuration Profiles¶

A GitlabProfile is a cluster-scoped resource that bundles opinionated defaults for a class of GitLab deployments. Profiles decouple how a class should be deployed from the specifics of each instance.

What a profile provides¶

A profile supplies default values for:

PostgreSQL deployment topology (ha or standalone) and node count
Redis deployment topology
Elasticsearch node count (EE only)
Backup cron schedule

These are the lowest-priority layer in value composition. Explicit settings on the GitlabInstance always override the profile default.

Referencing a profile¶

spec:
  profile: production   # name of a GitlabProfile CR

If the named GitlabProfile does not exist, the error is transient — the operator requeues. This lets you apply instances and profiles in any order during initial cluster setup.

The built-in production profile¶

examples/profile-production.yaml ships a production-ready profile:

apiVersion: k8s.bnerd.com/v1alpha1
kind: GitlabProfile
metadata:
  name: production
spec:
  defaults:
    postgres:
      topology: ha
      nodes: 3
    redis:
      topology: ha
    elasticsearch:
      nodes: 3
    backupSchedule: "30 2 * * *"

Apply it once per cluster:

kubectl apply -f examples/profile-production.yaml

Creating custom profiles¶

You can create profiles for different deployment classes:

Staging profileDevelopment profile

apiVersion: k8s.bnerd.com/v1alpha1
kind: GitlabProfile
metadata:
  name: staging
spec:
  defaults:
    postgres:
      topology: standalone
      nodes: 1
    redis:
      topology: standalone
    backupSchedule: "0 4 * * 0"   # weekly on Sunday

apiVersion: k8s.bnerd.com/v1alpha1
kind: GitlabProfile
metadata:
  name: development
spec:
  defaults:
    postgres:
      topology: standalone
      nodes: 1
    redis:
      topology: standalone
    # No backup schedule for development

How defaults are applied¶

The composition order is:

Profile defaults  →  VersionMap values  →  GitlabInstance spec  →  spec.helm.values
    (lowest)                                                          (highest)

This means:

If the profile sets postgres.topology: ha and the instance sets postgres.topology: standalone, the instance wins.
If the instance omits postgres.topology, the profile default (ha) is used.
spec.helm.values always wins over everything.

Inspecting a profile¶

kubectl get glprofile
# NAME          PG-TOPOLOGY   AGE
# production    ha            5d
# staging       standalone    2d

kubectl describe glprofile production

Profile vs instance spec fields¶

Field	Profile path	Instance path
Postgres topology	`spec.defaults.postgres.topology`	`spec.postgres.topology`
Postgres nodes	`spec.defaults.postgres.nodes`	`spec.postgres.nodes`
Redis topology	`spec.defaults.redis.topology`	`spec.redis.topology`
Redis nodes	`spec.defaults.redis.nodes`	`spec.redis.nodes`
Elasticsearch nodes	`spec.defaults.elasticsearch.nodes`	`spec.elasticsearch.nodes`
Backup schedule	`spec.defaults.backupSchedule`	`spec.backups.schedule`

All other GitlabInstance spec fields (domains, edition, version, object storage, SMTP, placement, helm escape hatch) have no profile equivalent — they are instance-specific.