Operator configuration

The operator for Cloud Native PostgreSQL is installed from a standard deployment manifest and follows the convention over configuration paradigm. While this is fine in most cases, there are some scenarios where you want to change the default behavior, such as:

  • setting a company license key that is shared by all deployments managed by the operator
  • defining annotations and labels to be inherited by all resources created by the operator and that are set in the cluster resource
  • defining a different default image for PostgreSQL or an additional pull secret

By the default, the operator is installed in the postgresql-operator-system namespace as a Kubernetes Deployment called postgresql-operator-controller-manager.


In the examples below we assume the default name and namespace for the operator deployment.

The behavior of the operator can be customized through a ConfigMap that is located in the same namespace of the operator deployment and with postgresql-operator-controller-manager-config as the name.


Any change to the config map will not be automatically detected by the operator, - and as such, it needs to be reloaded (see below). Moreover, changes only apply to the resources created after the configuration is reloaded.

Available options

The operator looks for the following environment variables to be defined in the config map:

Name Description
EDB_LICENSE_KEY default license key (to be used only if the cluster does not define one)
INHERITED_ANNOTATIONS list of annotation names that, when defined in a Cluster metadata, will be inherited by all the generated resources, including pods
INHERITED_LABELS list of label names that, when defined in a Cluster metadata, will be inherited by all the generated resources, including pods
PULL_SECRET_NAME name of an additional pull secret to be defined in the operator's namespace and to be used to download images

By default, the above variables are not set.

Values in INHERITED_ANNOTATIONS and INHERITED_LABELS support path-like wildcards. For example, the value example.com/* will match both the value example.com/one and example.com/two.

Defining an operator config map

The example below customizes the behavior of the operator, by defining a default license key (namely a company key) and the label/annotation names to be inherited by the resources created by any Cluster object that is deployed at a later time.

apiVersion: v1
kind: ConfigMap
  name: postgresql-operator-controller-manager-config
  namespace: postgresql-operator-system
  INHERITED_LABELS: environment, workload, app

For the change to be effective, you need to recreate the operator pods to reload the config map. If you have installed the operator on Kubernetes using the manifest you can do that by issuing:

kubectl rollout restart deployment \
    -n postgresql-operator-system \

Otherwise, If you have installed the operator using OLM, or you are running on Openshift, run the following command specifying the namespace the operator is installed in:

kubectl delete pods -n [NAMESPACE_NAME_HERE] \
  -l app.kubernetes.io/name=cloud-native-postgresql


Customizations will be applied only to Cluster resources created after the reload of the operator deployment.

Following the above example, if the Cluster definition contains a categories annotation and any of the environment, workload, or app labels, these will be inherited by all the resources generated by the deployment.