This CNPG Recipe explores the latest enhancements to CloudNativePG’s softwaresupply chain and image management. Learn how our new, fully controlled buildprocess—complete with Snyk scanning, image signing, and SBOMs—delivers smaller,more secure PostgreSQL images. We also detail how to leverage the newlystreamlined image catalogs for simplified, declarative cluster management andsafer fleet-wide upgrades in Kubernetes.

The container image is the most fundamental building block of a database inKubernetes. As theData on Kubernetes (DoK) communitycontinues to grow and mature, managing the source, version, and security ofthis supply chain is critical for any production-grade data service.

That’s why I’m thrilled to announce a foundational improvement in how we buildand source the officialPostgreSQL operand imagesfor CloudNativePG.

This evolution significantly enhances security and reliability, improves theuser experience around image management, and paves a more modular future forPostgreSQL on Kubernetes.

In line with this, we have also converted ourPostGIS container imagesto follow the same high standards as the main PostgreSQL images.

Taking Full Control of Our PostgreSQL Images#

First, we at CloudNativePG are making a landmark change to the operand images.We have definitively moved away from using the officialpostgres image fromDocker Hub, which has accompanied the project since it was open-sourced.

Instead, we have transitioned to anew software supply chain, built from theground up withdocker bake, that is entirely under the control of theCloudNativePG project. While the images continue to be hosted at the standardregistry, their origin and build process are now fundamentally more secure androbust.

This new, transparent, and secure supply chain provides several key guarantees:

• Vulnerability Scanning: Every image is continuously scanned forvulnerabilities withSnyk, allowing us to react faster to newlydiscovered CVEs.
• Image Signing: All images are cryptographically signed usingsigstore/cosign. This provides a guarantee that the images you use werebuilt by our pipeline and have not been tampered with.
• Software Bill of Materials (SBOM): We generate and distribute an SBOM foreach image, providing a complete inventory of every software component anddependency for full transparency.
• Optimised Multi-Arch Builds: Our newdocker bake pipeline is designedfrom the start to efficiently produce multi-architecture images (amd64andarm64), ensuring first-class support for diverse Kubernetesenvironments.

Image Catalogs, Perfected: A Reliable New Distribution Pipeline#

Image Catalogshave been a powerful feature in CloudNativePG for over two years, allowing youto decouple your cluster configuration from specific image tags. However, theresponsibility of creating and maintaining the catalog manifests often fellto you, the user.

Today, we are removing that friction completely. Our new, trusted distributionpipeline now provides a reliable, central source for these catalogs. Now,instead of managing these files yourself, you can install the complete,officially maintained catalogwith a single command:

# Deploy all supported PostgreSQL version catalogs to your clusterkubectl apply -k\  https://github.com/cloudnative-pg/artifacts/image-catalogs?ref=main

Once applied, you can verify that the catalogs have been successfully createdin your cluster with the following command:

kubectl get clusterimagecatalogs.postgresql.cnpg.io

You should see an output similar to this, listing all the available catalogueoptions with formatpostgresql-<type>-<debian_version>:

NAME                         AGEpostgresql-minimal-bookworm  19spostgresql-minimal-bullseye  19spostgresql-minimal-trixie    19spostgresql-standard-bookworm 19spostgresql-standard-bullseye 19spostgresql-standard-trixie   19spostgresql-system-bookworm   19spostgresql-system-bullseye   19spostgresql-system-trixie     19s

To inspect a specific catalog and see the exact image versions it contains, youcan usekubectl describe:

kubectl describe clusterimagecatalogs.postgresql.cnpg.io\  postgresql-minimal-trixie

This reveals the mapping between each major PostgreSQL version and the precise,immutable container image digest that will be used:

Name:         postgresql-minimal-trixie...Spec:  Images:    Image:  ghcr.io/cloudnative-pg/postgresql:16.10-202509290807-minimal-trixie@sha256:f69b49dc63c2988a358c58f8a1311ac98719846f91d8e97186eaf65c7085cf28    Major:  16    Image:  ghcr.io/cloudnative-pg/postgresql:17.6-202509290807-minimal-trixie@sha256:f3e24407db6eb8c3c9a7cb433cfe81cbff006ba1f97ae9844a58c7d3cd8048d7    Major:  17    Image:  ghcr.io/cloudnative-pg/postgresql:18.0-202509290807-minimal-trixie@sha256:dd7c678167cc6d06c2caf4e6ea7bc7a89e39754bc7e0111a81f5d75ac3068f70    Major:  18...

Putting it to Work: Referencing the Catalog in a Cluster#

Once the catalogs are installed, using them in yourCluster manifest issimple and powerful. Instead of a hardcodedimageName, you can useimageCatalogRef to select both a catalog and a specific major version fromit.

apiVersion: postgresql.cnpg.io/v1kind: Clustermetadata:  name: angusspec:  instances: 3  imageCatalogRef:    apiGroup: postgresql.cnpg.io    kind: ClusterImageCatalog    name: postgresql-minimal-trixie    major: 18  storage:    size: 1Gi

This elegant abstraction allows your manifest to declare itsintent. In thiscase, you’re requesting a cluster using thepostgresql-minimal-trixiecatalog, and pinning it specifically tomajor version 18.

After the cluster is up and running, you candescribe it to see how theoperator has resolved your request into a specific image digest in theStatussection:

kubectl describe cluster angus

Notice how theimageCatalogRef from theSpec is translated into a concreteImage in theStatus:

...Spec:  Image Catalog Ref:    API Group:  postgresql.cnpg.io    Kind:       ClusterImageCatalog    Major:      18    Name:       postgresql-minimal-trixie...Status:...  Image:  ghcr.io/cloudnative-pg/postgresql:18.0-202509290807-minimal-trixie@sha256:dd7c678167cc6d06c2caf4e6ea7bc7a89e39754bc7e0111a81f5d75ac3068f70...

The Grand Finale: Safe, Automated Fleet Upgrades#

This improved system truly shines when managing a database fleet at scale. Whenyou update the Image Catalog in your cluster, all related clusters will bescheduled for a rolling update. To prevent a “thundering herd” that couldoverwhelm your system, you can control the rollout globally.

This feature, calledspread upgrades, is configured in the operator’s mainConfigMap. By setting theCLUSTERS_ROLLOUT_DELAY variable, you instruct theoperator to wait a specific number of seconds before starting the update on thenext cluster.

For example, to set a 2-minute delay between each cluster update:

apiVersion: v1kind: ConfigMapmetadata:  name: cnpg-controller-manager-config  namespace: cnpg-systemdata:  CLUSTERS_ROLLOUT_DELAY: '120'

This is a powerful and simple way to ensure a safe, controlled, and completelyautomated rollout of updates across your entire database fleet.

A More Declarative and Modular Future#

These improvements—a fully controlled supply chain and a reliable distributionpipeline for catalogs—are more than just operational conveniences.They are foundational steps towards a more secure and modular architecture forrunning PostgreSQL on Kubernetes. Our ultimate goal is to ship “minimal”PostgreSQL images containing only the core database engine.

This vision is realised through another powerful feature called “extensionimage volumes”. Instead of bundling every possible extension into a single,monolithic image, each extension is packaged in its own separate image.

A newborn project,PostgreSQL Extension Containers,will contain these images.

When needed, CloudNativePG dynamically loads it into your PostgreSQL pod.

This combined approach is the future:

• Enhanced Security: Your core database has asmaller surface attack.
• Modularity and Flexibility: Manage, version, and update extensionsindependently of the PostgreSQL engine.

The image catalogs are the control plane that makes this modular ecosystempossible, providing the robust, declarative mechanism to manage the entiresuite of components that power your applications.

Get Started Today#

First, I want to thank the entire CloudNativePG team for completing this epicenhancement, which we started at the beginning of the year. I am really proudof the result we have achieved from every aspect: operations, security, andextensibility.

The fact that thePostgreSQL 18 minimal image is now ~230MB—45% smaller than the equivalent for PostgreSQL 17—is a major step forward. Theimage catalogue artifacts are also an important achievement forstandardisation, simplifying integration into any deployment.

I encourage you to adopt this new, simplified workflow for image catalogstoday. You can get started by applying them from ourartifacts repository.

For a deeper dive, check out the official documentation onimage catalogsandspread upgrades.

To see where this is headed, I invite you to read my previous article on“The Immutable Future of PostgreSQL Extensions”and the official docs onextension image volumes.

Stay tuned for the upcoming recipes! For the latest updates, considersubscribing to myLinkedIn andTwitter channels.

If you found this article informative, feel free to share it within yournetwork on social media using the provided links below. Your support isimmensely appreciated!