cnpg

Solid

Create and operate CloudNativePG (CNPG) Postgres databases on Kubernetes the GitOps/Flux way - on managed cloud (GKE + GCS via Workload Identity) OR self-hosted (K3s/bare-metal + any S3-compatible store via a credentials secret). Covers Cluster + ScheduledBackup manifests, barman WAL archiving, pgvector, PITR, prod→dev clones, and the NetworkPolicies a default-deny cluster needs. Use when provisioning a new app database, cloning prod into dev, enabling pgvector, wiring backups/PITR, writing CNPG NetworkPolicies, or debugging the silent "WAL archiving failed → PVC fills → Postgres CrashLoop → app can't read data" chain on CloudNativePG.

AI & Automation 2 stars 0 forks Updated today MIT

Install

Quality Score: 78/100

Stars 20%

16

Recency 20%

100

Frontmatter 20%

70

Documentation 15%

100

Issue Health 10%

80

License 10%

100

Description 5%

100

Skill Content

# 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...

Details

Author: vanducng
Repository: vanducng/skills
Created: 2 months ago
Last Updated: today
Language: Python
License: MIT

Integrates with

Google Cloud · Cloud PostgreSQL · Database Kubernetes · Infrastructure Terraform · Infrastructure

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

API & Backend Solid

postgres-operator-cloudnative-pg-migration

Migrate PostgreSQL clusters from the Zalando postgres-operator (acid.zalan.do `postgresql` CRs, Spilo/Patroni, WAL-G) to CloudNativePG (CNPG) on Kubernetes, incl. fully air-gapped clusters. Core knowledge: the two walls (Spilo↔CNPG glibc/collation divergence that corrupts physically-copied indexes; WAL-G↔Barman archive incompatibility that strands old backups), three migration paths (logical replication default; initdb.import for small DBs/PG≤13; pg_basebackup as the discouraged same-major exception), the acid.zalan.do→Cluster manifest field map with no-equivalent gaps (preparedDatabases, sidecars, logical-backup cron), backup re-plumbing onto the barman-cloud CNPG-I plugin, HA parity (synchronous + failoverQuorum vs Patroni failsafe), consumer cutover (service/secret renames, scram, cnpg_ metrics), air-gap mirroring, stay-vs-migrate evidence.

3 Updated yesterday

AI & Automation Listed

build-and-run

Build, install, initdb, and start PostgreSQL from source in the `dev/` clone for backend hacking — covers meson setup (PG ≥ 16 default) with cassert + debug flags, the autoconf ./configure fallback, ninja install, initdb + pg_ctl start / stop, PGDATA / PATH wiring, single-user mode for postmaster startup debugging, attaching gdb / lldb under the per-connection fork model, and -O0 -g3 debug builds. Use whenever a task involves compiling PG from source in dev/, running ninja install on the dev clone, initdb-ing a fresh data directory, starting or stopping the dev cluster via pg_ctl, picking between the debug profile (5432) and ASan profile (5433), or attaching a debugger to a forked backend. Skip for brew / apt / yum / Docker / k8s installation of release PG, Aurora / Cloud SQL / Supabase / Neon-managed PG provisioning, generic CMake / make / Bazel build questions, Linux-kernel builds, Node.js / Python / Go application builds, and pgAdmin / DBeaver client installation.

0 Updated 4 days ago

AI & Automation Listed

pg-extension-lab

Develop, test, benchmark, and operate PostgreSQL extensions with reusable harnesses and reference protocols. Use for C/PGXS or Rust/pgrx extension work, planner hooks, CustomScan or index AM design, pg_regress/pg_isolation_regress TDD, filtered ANN/vector benchmarks, matched-recall and pages-per-query analysis, bounded parameter-space exploration, Pareto curves, hypothesis/evidence/report management, accelerator-vs-CPU crossover, resource Pareto tuning, Shape B microservice extensions, Shape C sidecar daemons, service-boundary contracts, async outbox workers, and SECURITY hardening. Balances docs, code evidence, and execution results. Includes copy-ready test, benchmark, contract, and ops assets. Not for projects without a PostgreSQL extension layer.

1 Updated 3 days ago