Migrate from Operator-generated or custom certificates to cert-manager¶

You can start using cert-manager for TLS certificates lifecycle management if you have previously deployed your cluster with auto-generated or custom certificates. The use of cert-manager provides automatic certificate renewal, configurable validity periods, and centralized certificate management across your Kubernetes cluster.

Read more about cert-manager in Configure TLS security with the Operator using cert-manager.

Migration steps¶

Export the cluster name and the namespace where the cluster is running as an environment variable:
```
export CLUSTER=<cluster1>
export NAMESPACE=<namespace>
```
Pause the cluster to stop reconciliation before you change TLS resources. Run the following command to patch your running cluster:
```
kubectl patch -n $NAMESPACE pg $CLUSTER --type merge --patch '{
"spec": {
  "pause": true}
  }'
```
Verify the cluster status:
```
kubectl get pg $CLUSTER -n $NAMESPACE
```
Wait until the cluster status is Paused. You can verify with kubectl get pods -n $NAMESPACE.
Deploy cert-manager. In this guide we install cert-manager with kubectl. Refer to Configure TLS security with the Operator using cert-manager for Helm installation instructions.
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.21.1/cert-manager.yaml
```
This command installs cert-manager in the default cert-manager namespace.
Verify that cert-manager is running:
```
kubectl get pods -n cert-manager
```

Delete the TLS Secrets.

Operator-generated certificatesCustom certificates

Delete the Secrets:

kubectl delete secret $CLUSTER-cluster-ca-cert $CLUSTER-cluster-cert $CLUSTER-replication-cert -n  $NAMESPACE

Example for a cluster named cluster1:

kubectl delete secret cluster1-cluster-ca-cert cluster1-cluster-cert cluster1-replication-cert -n $NAMESPACE

Update the Custom Resource and remove all references to Secrets that contain your custom certificates:

kubectl -n $NAMESPACE patch pg $CLUSTER --type merge --patch '{
  "spec": {
    "secrets": {
      "customRootCATLSSecret": null,
      "customTLSSecret": null,
      "customReplicationTLSSecret": null
    }
  }
}'

If pgBouncer also uses a custom certificate, clear the spec.proxy.pgBouncer.customTLSSecret option too.

Delete the Secrets. This includes your custom Secrets and the one generated by the Operator:

kubectl delete secret <customRootCATLSSecret-value> <customTLSSecret-value> <customReplicationTLSSecret-value> <pgbouncer.customTLSSecret> -n $NAMESPACE
kubectl delete secret $CLUSTER-cluster-ca-cert $CLUSTER-cluster-cert $CLUSTER-replication-cert $CLUSTER-pgbouncer-frontend-tls -n $NAMESPACE

Resume the cluster. Set spec.pause back to false:

kubectl patch -n $NAMESPACE pg cluster1 --type merge --patch '{
"spec": {
  "pause": false}
  }'

The Operator detects the missing Secrets, sees cert-manager installed, requests new certificates from cert-manager, creates the Secrets, and resumes the cluster.

Verify the migration¶

After the cluster is running, verify that cert-manager resources were created:

kubectl get issuers -n $NAMESPACE
kubectl get certificates -n $NAMESPACE
kubectl get secret <cluster-name>-cluster-ca-cert <cluster-name>-cluster-cert <cluster-name>-replication-cert -n $NAMESPACE

You can configure certificate validity in the Custom Resource. See Configure the certificate validity for details.

Last update: March 30, 2026
Created: March 26, 2026