Backends¶

GitLab requires PostgreSQL, Redis, and (for EE) Elasticsearch. The operator supports two models for each: managed (the operator provisions it) and bring-your-own (you provide connection credentials).

The two models¶

Managed (`managed: true`)¶

The operator provisions a backend cluster using the appropriate Kubernetes operator for that technology. The provisioned cluster is not owned by the GitlabInstance — it survives instance deletion by design.

spec:
  postgres:
    managed: true
    topology: ha       # "standalone" or "ha"
    pgbouncer: true

What happens internally:

The operator checks that the backend CRD is present in the cluster (capability gating). If the CRD is absent, the instance goes to phase: Failed immediately with a clear message — there is never a silent fallback to the bundled in-chart component.
The operator applies the backend CR (e.g. PerconaPGCluster) without an owner reference. This means the data cluster persists after the GitlabInstance is deleted.
The operator requeues every 15 seconds until the backend reports ready.
Once ready, the operator extracts the connection endpoint from the backend's status and passes it into the Helm value composition.

Bring-your-own (`managed: false`)¶

You provision the backend yourself and give the operator a reference to a Kubernetes Secret containing connection parameters.

spec:
  postgres:
    managed: false
    credentialsSecret: my-pg-credentials   # must exist in the same namespace

If the referenced Secret does not exist yet, the operator sets phase: Pending and requeues after 30 seconds, waiting for it to appear.

Backend operators and capability gating¶

Backend	Technology	CRD group	When required
Postgres	Percona PG Operator (`PerconaPGCluster`)	`pgv2.percona.com`	`spec.postgres.managed: true`
Redis	OT-Container-Kit redis-operator	`redis.redis.opstreelabs.in`	`spec.redis.managed: true`
Elasticsearch	ECK (`Elasticsearch`)	`elasticsearch.k8s.elastic.co`	`spec.elasticsearch.managed: true` (EE only)

The capability gate is a hard check: if managed: true and the CRD is absent, the instance fails permanently. The operator never silently falls back to the in-chart bundled services (MinIO, Postgres sub-chart, etc.).

Elasticsearch is EE-only¶

spec.elasticsearch is only provisioned when:

spec.edition: ee, AND
spec.licenseSecret is set, AND
spec.elasticsearch.managed: true

On Community Edition the elasticsearch spec block is ignored entirely. See Editions & Licensing.

Managed backend retention¶

Managed backends survive instance deletion

When you delete a GitlabInstance, the operator's finalizer removes only the operator-owned Secrets (listed in status.secrets). The managed PerconaPGCluster, Redis CRs, and ECK Elasticsearch are not deleted — they carry no owner reference to the GitlabInstance.

This is intentional: it prevents accidental data loss if an instance CR is deleted by mistake. You must clean up managed backends manually after verifying their data is no longer needed.

See Deletion & Retention for the cleanup procedure.

Choosing managed vs BYO¶

Situation	Recommendation
New deployment, no existing database	`managed: true` — simplest, operator handles topology and readiness
Existing database to migrate from	`managed: false` with a `credentialsSecret` pointing at the existing instance
Shared database cluster across multiple GitLab instances	`managed: false` — a shared cluster should not be owned by a single instance
Maximum isolation per tenant	`managed: true` — each instance gets its own cluster
Cost optimisation, non-production	`managed: false` — share a single external Postgres/Redis across dev/staging instances

See Managed Backends for the full provisioning guide, and BYO Backends for the credentials Secret shapes.