cnpglisted

# cnpg Provision and run CloudNativePG (CNPG) Postgres on Kubernetes as GitOps. Every concrete identifier below is a placeholder — substitute your own: `<project>`, `<gcp-sa>`, `<backups-bucket>`, `<cluster>`, `<ns>`, `<svc>`, `<db>`, `<owner>`, `<env>`, `<s3-endpoint>`, `<objstore-secret>`, `<app-ns>`. **Two platforms, one operator.** The Cluster spec, bootstrap, pgvector, PITR, clone, and most gotchas are identical everywhere. Only **backup auth** and **NetworkPolicy** differ: - **Managed cloud (GKE + GCS):** backup auth = Workload Identity (no keys). Steps below default to this. - **Self-hosted (K3s / bare-metal + S3-compatible store: MinIO, Ceph, R2, B2):** backup auth = an access-key Secret; plus a default-deny cluster needs explicit NetworkPolicies. See **`references/self-hosted-and-networkpolicy.md`** — read it whenever there's no cloud Workload Identity or the cluster enforces default-deny. ## Mental model — two halves that MUST share one string A CNPG database on GKE is two halves that have to agree on exactly one string, `<ns>/<cluster>`: 1. **GitOps half (k8s YAML):** a CNPG `Cluster` whose `serviceAccountTemplate` annotation points the auto-created **pod KSA** at the GCP backup SA. CNPG names that pod KSA after the **cluster** (`<cluster>`) in `<ns>`. Any standalone `ServiceAccount` named `cnpg-backup-sa` you find in a folder is a **decoy/legacy** resource — CNPG does **not** use it for backup auth. 2. **GCP half (Terraform):** an IAM `wo