Merge 78d02d6803 into 1e13020fe5

chore(main): release 0.14.0 (#964 )
Signed-off-by: Peggie <info@cloudnative-pg.io>
2026-09-06 15:02:21 +02:00 · 2026-07-31 21:07:30 +02:00 · 2026-07-29 12:00:23 +02:00 · 2026-07-29 11:26:55 +02:00 · 2026-07-28 19:27:14 +02:00 · 2026-07-28 19:17:29 +02:00
27 changed files with 2796 additions and 119 deletions
--- a/.release-please-manifest.json
+++ b/.release-please-manifest.json
@ -1,3 +1,3 @@
 {
-  ".": "0.13.0"
+  ".": "0.14.0"
 }
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@ -1,5 +1,36 @@
 # Changelog
 ## [0.14.0](https://github.com/cloudnative-pg/plugin-barman-cloud/compare/v0.13.0...v0.14.0) (2026-07-29)
 ### Features
 * Honor the operator's check_empty_wal_archive decision ([#1009](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/1009)) ([7bcb74b](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/7bcb74b987a3cca232c6f8021157eb711a1289b0))
 ### Bug Fixes
 * **deps:** Update all non-major go dependencies ([#963](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/963)) ([f949241](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/f94924105b51b7b015338d4ec2c71904ef8d095c))
 * **deps:** Update all non-major go dependencies ([#979](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/979)) ([bf52833](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/bf5283359478071f116464c14a7a3d3d0a358eea))
 * **deps:** Update all non-major go dependencies ([#982](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/982)) ([5f84ecc](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/5f84ecce4a9433da27346d194f6a4b456d59f75f))
 * **deps:** Update all non-major go dependencies to 53ffbf0 ([#973](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/973)) ([7190349](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/719034947061f72ce8fcc919f5e209aa7fd7d874))
 * **deps:** Update all non-major go dependencies to 592f761 ([#972](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/972)) ([2fa63c4](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/2fa63c4bc28c03fbb79e3751a001868e991b8917))
 * **deps:** Update all non-major go dependencies to 8d9302e ([#975](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/975)) ([0c687cb](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/0c687cbbf13f4ce5ca1690d4dcf768d76cb4731a))
 * **deps:** Update all non-major go dependencies to v2.30.0 ([#957](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/957)) ([61b82ce](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/61b82ce250e95f04d49d0fb427e79364f2d900c0))
 * **deps:** Update documentation dependencies to v3.10.2 ([#1001](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/1001)) ([88f2e29](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/88f2e296746f495d3e7b27cd7297e772d53f61e9))
 * **deps:** Update github.com/cloudnative-pg/barman-cloud digest to 950b0f5 ([#1022](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/1022)) ([98537c4](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/98537c4d0e899e136e85237b29020a9bbbf9f5aa))
 * **deps:** Update k8s.io/utils digest to a95e086 ([#968](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/968)) ([f7f0136](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/f7f0136520b1032698b26e33e6eff1caa01173f5))
 * **deps:** Update k8s.io/utils digest to be93311 ([#986](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/986)) ([2cc4e99](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/2cc4e9905db6b1d1c5788dd6093a1a7d330d9064))
 * **deps:** Update kubernetes monorepo to v0.36.2 ([#958](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/958)) ([030b28c](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/030b28c4b9aee205f7a43f1fcc4da363b50839d9))
 * **deps:** Update kubernetes monorepo to v0.36.3 ([#1031](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/1031)) ([ce81794](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/ce8179442b49e0686ec05505b4ba79360b54ec8c))
 * **deps:** Update module github.com/cloudnative-pg/cnpg-i to v0.6.0 ([#1021](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/1021)) ([13450a3](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/13450a370d16fda87c128fc3a2f420f5b0cc442b))
 * **deps:** Update module google.golang.org/grpc to v1.82.1 ([#1008](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/1008)) ([3c27364](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/3c273641e3fb8027011be74ebb09d0ba91f71c7b))
 * **docs:** Fix broken anchor link in concepts.md ([#1013](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/1013)) ([9c84d06](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/9c84d069edc39c2848813aff5fd13c13c2ac8ff9))
 * Inject barman sidecar in replica clusters bootstrapped with pg_basebackup ([#965](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/965)) ([eb5e860](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/eb5e8607752d60bf36b4a9ddcaa5bb447f323012))
 * Reduce startupProbe periodSeconds without losing failure tolerance ([#992](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/992)) ([bf95543](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/bf955430cb58987bbbe3cd2925ea06700cf85609)), refs [#991](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/991)
 * Restore WAL from replica source during designated primary promotion ([#966](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/966)) ([c34b232](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/c34b2329ea39f9a1030d9d1225aa4d0a276255eb))
 * **walrestore:** Serve pg_rewind without prefetching and flag machinery ([#1007](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/1007)) ([fb3f0f9](https://github.com/cloudnative-pg/plugin-barman-cloud/commit/fb3f0f9dabba85d87af85418d58b2f8224ed6305))
 ## [0.13.0](https://github.com/cloudnative-pg/plugin-barman-cloud/compare/v0.12.0...v0.13.0) (2026-06-10)
--- a/containers/sidecar-requirements.txt
+++ b/containers/sidecar-requirements.txt
@ -22,19 +22,19 @@ barman==3.19.1 \
    --hash=sha256:0a6a9e1babf97687732d8b2a3eb79ea95d55246a5257b9433865cb6e755221c0 \
    --hash=sha256:2f71c4a1f1ba53f694cbdf838bb9906d8ba02b97d1fd3041196e8999bec7a1ee
    # via -r sidecar-requirements.in
-boto3==1.43.51 \
+boto3==1.43.56 \
-    --hash=sha256:a97057bb609fd38c80448db6a93db770786775dabd651401debf09816d4553d7 \
+    --hash=sha256:57c90df9fb026f2e6ae22530861198130203733c5c9ec4e5cca3a4037f5a8db4 \
-    --hash=sha256:b5a416cc703db73b69b22bef563c89c1fb14a4b10a93628d3c7abc4dd1aaf979
+    --hash=sha256:feb699d4ab241ef5c1b80bb58277be2aaad365cd4b672d7817e0bc59ee45131b
    # via barman
-botocore==1.43.51 \
+botocore==1.43.56 \
-    --hash=sha256:7c2c538c932bddc95834e177ce6f91dcc388c6a7934b4f8d0db13caa30e3e543 \
+    --hash=sha256:6c01f85f0ff9863076f4c761e74ee3aa96c5ccc1ad09fc1efd62ef8f2d22bf57 \
-    --hash=sha256:e0e5e88585fdb01dcb6b533ac2dd3f18d5d45092a14ccbfd330e3576a4152128
+    --hash=sha256:aafc741f1b10f6fd63253eaf6ea029680c1ff436d87e1b8969d62aefa0c76976
    # via
    #   boto3
    #   s3transfer
-certifi==2026.6.17 \
+certifi==2026.7.22 \
-    --hash=sha256:024c88eeec92ca068db80f02b8b07c9cef7b9fe261d1d535abfd5abd6f6af432 \
+    --hash=sha256:62f22742b58a1a33014a2b6b706588a8d7e2a88ae7bd1a6ebe8c992928483775 \
-    --hash=sha256:2227dcbaafe0d2f59279d1762ddddc37783ed4354594f194ffc31d20f41fc3db
+    --hash=sha256:741e2c3b351ddf169a738da9f2c048608ff7f2c5cc02f1ebc6b118bb090d5d55
    # via requests
 cffi==2.1.0 \
    --hash=sha256:02cb7ff33ded4f1532476731f89ede53e2e488a8e6205515a82144246ffa7dcc \
@ -423,15 +423,15 @@ cryptography==49.0.0 \
    #   google-auth
    #   msal
    #   pyjwt
-google-api-core==2.32.0 \
+google-api-core==2.33.0 \
-    --hash=sha256:2b33aad226b19272458c46abfe5c5a38d9531ece0c44502129a1463ce83674ac \
+    --hash=sha256:3a36bcc3e319783f4c97da41f6f45ea6ffcaa55848e341de16e09cb70243c2bb \
-    --hash=sha256:ae1f0d58a6c8869350bf469f8eb3092e7f8c494a942d9525494afb6c162b0904
+    --hash=sha256:a2e22a0c1d0f03eafff1858b38cf46f832d5902b0c052235bf0ab8402929fbdc
    # via
    #   google-cloud-core
    #   google-cloud-storage
-google-auth==2.56.0 \
+google-auth==2.56.2 \
-    --hash=sha256:6e88c10217e07a92bfd01cac8ee99e32ccfb08414c3102e6c5b8d58f37a0d1e0 \
+    --hash=sha256:c8270ea95b2697b74e3d8438ae9c5b898e38b623b915c7b5c5635921e7de68a6 \
-    --hash=sha256:f90fa030b569a92654b9d690665a073841df33d57487be53db583a9a0867a553
+    --hash=sha256:e28f103ca8091fb7012b99c44243d7366c29863713b8e34a220c3322b7a07051
    # via
    #   google-api-core
    #   google-cloud-core
@ -572,9 +572,9 @@ msal-extensions==1.3.1 \
    --hash=sha256:96d3de4d034504e969ac5e85bae8106c8373b5c6568e4c8fa7af2eca9dbe6bca \
    --hash=sha256:c5b0fd10f65ef62b5f1d62f4251d51cbcaf003fcedae8c91b040a488614be1a4
    # via azure-identity
-proto-plus==1.28.1 \
+proto-plus==1.28.2 \
-    --hash=sha256:6660f5f1970874bdcfc3088b435188a36a37bd3596668f7d726417c4ae8cfbed \
+    --hash=sha256:26d843eb99c1e32fdf1d20ff0faae56607f7748fe774acf9ecd5cfe6c6472501 \
-    --hash=sha256:832e68e7fe064cf90ab153b6e5eb935b27891bb89aaeb68b115e9b702f6cb168
+    --hash=sha256:b874236fcac2358f601e4330bcb76cb8b89c851303ccf4078408b3d4774d1c52
    # via google-api-core
 protobuf==7.35.1 \
    --hash=sha256:11d6b0ec246892d85215b0a13ca6e0233cf5284b68f0ac02646427f4ff88a799 \
@ -634,9 +634,9 @@ requests==2.34.2 \
    #   google-api-core
    #   google-cloud-storage
    #   msal
-s3transfer==0.19.1 \
+s3transfer==0.19.2 \
-    --hash=sha256:d3d6371dc3f1e5c5427b2b457bcf13bcf87bec334c95aed18642eae61f6926f3 \
+    --hash=sha256:ba0309fd86be3c27dbf78cdd813c13c5e1df16e5874b99d2535ebbdfb9892993 \
-    --hash=sha256:d5fd7005ee39307455ad5f310b5ea67f4b1960d7fed5b3671ee50c249de675de
+    --hash=sha256:d8168eccca828cbb2cd573675333f3bddd254313a9c42494b84c76b539e8ba25
    # via boto3
 six==1.17.0 \
    --hash=sha256:4721f391ed90541fddacab5acf947aa0d3dc7d27b2e1e8eda2be8970586c3274 \
--- a/go.mod
+++ b/go.mod
@ -16,10 +16,10 @@ require (
 	github.com/spf13/viper v1.21.0
 	google.golang.org/grpc v1.82.1
 	gopkg.in/yaml.v3 v3.0.1
-	k8s.io/api v0.36.2
+	k8s.io/api v0.36.3
-	k8s.io/apiextensions-apiserver v0.36.2
+	k8s.io/apiextensions-apiserver v0.36.3
-	k8s.io/apimachinery v0.36.2
+	k8s.io/apimachinery v0.36.3
-	k8s.io/client-go v0.36.2
+	k8s.io/client-go v0.36.3
 	k8s.io/utils v0.0.0-20260707023825-cf1189d6abe3
 	sigs.k8s.io/controller-runtime v0.24.1
 	sigs.k8s.io/kustomize/api v0.21.1
@ -125,11 +125,11 @@ require (
 	google.golang.org/protobuf v1.36.12-0.20260120151049-f2248ac996af // indirect
 	gopkg.in/evanphx/json-patch.v4 v4.13.0 // indirect
 	gopkg.in/inf.v0 v0.9.1 // indirect
-	k8s.io/apiserver v0.36.2 // indirect
+	k8s.io/apiserver v0.36.3 // indirect
-	k8s.io/component-base v0.36.2 // indirect
+	k8s.io/component-base v0.36.3 // indirect
 	k8s.io/klog/v2 v2.140.0 // indirect
 	k8s.io/kube-openapi v0.0.0-20260603220949-865597e52e25 // indirect
-	k8s.io/streaming v0.36.2 // indirect
+	k8s.io/streaming v0.36.3 // indirect
 	sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.34.0 // indirect
 	sigs.k8s.io/gateway-api v1.6.0 // indirect
 	sigs.k8s.io/json v0.0.0-20250730193827-2d320260d730 // indirect
--- a/go.sum
+++ b/go.sum
@ -308,24 +308,24 @@ gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
 gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
 gopkg.in/yaml.v3 v3.0.1 h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA=
 gopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM=
-k8s.io/api v0.36.2 h1:TF6YDLIzKfccK7cq9YpTcGX8TJmEkHVRv78DM51fRYY=
+k8s.io/api v0.36.3 h1:NxB+05W2UGqXWFXcLO0RB5cnqnUPP5v5sVlaOH0Iz4w=
-k8s.io/api v0.36.2/go.mod h1:F4LbMO4brjZYh7yFkXWhynSvtB7YauxV4c+HHkNRGNg=
+k8s.io/api v0.36.3/go.mod h1:JzLQKqRHC5+I8RVj/lS3lCg0mg6nWI9Fo/Sk3ElxHzg=
-k8s.io/apiextensions-apiserver v0.36.2 h1:3O5gqOj/dt2XWWbpMe+TXWpE9yU6pjM/tXxtHHJT/K4=
+k8s.io/apiextensions-apiserver v0.36.3 h1:dPmOAPhwTtqb1bTxbFPsy18KHPhktQeO3WUPXunZIB0=
-k8s.io/apiextensions-apiserver v0.36.2/go.mod h1:cL1tBWe8XSaP1H30iWKGo7hf6iAUUUJPEU70dskmAnA=
+k8s.io/apiextensions-apiserver v0.36.3/go.mod h1:KTXFqgXiuw2pRoL+Wpmttqc+up9Xt/GohadPWeLLOa4=
-k8s.io/apimachinery v0.36.2 h1:0PE/W/WNy1UX61NLbXY5TMbJ6UwLL6E6lAPkYrKFxbQ=
+k8s.io/apimachinery v0.36.3 h1:PkzMRBRG8joFD8EhCuQAtNPvJlxb82FwplP26HIzvAM=
-k8s.io/apimachinery v0.36.2/go.mod h1:fvf/HOLXq9RId0rnDIbN1OEBvHXdQbLMM8nu0LcBUf4=
+k8s.io/apimachinery v0.36.3/go.mod h1:cTSjBWgPe/6CQyBKzY/hDIRWCQQQeK0mfLbml0UYFHE=
-k8s.io/apiserver v0.36.2 h1:6vMnkmHZPeBloNkHUhmZYq7Ylv8WIB8xjyEl+eSt26E=
+k8s.io/apiserver v0.36.3 h1:MGSg2SkdfuytiDEcRylT5mQFmmSsbx90XFUO67Y4bsQ=
-k8s.io/apiserver v0.36.2/go.mod h1:9PoQ2ikCytrZyZg11mGhLEF5m8Rgsb5FJmYJ4Wvnl1k=
+k8s.io/apiserver v0.36.3/go.mod h1:fVH7zv9EUNUA7Fl7LtDKh8aB9W7u1VQPSGtWV5SjUxg=
-k8s.io/client-go v0.36.2 h1:bfgxmFKc9CgqsgX4xKLAAdmTQlWee7Ob/HlDOrJ5TBI=
+k8s.io/client-go v0.36.3 h1:M4JdVzXxYcZk4fGpfDdYnxSwhLKWCFoQsHW6t+z8Hfg=
-k8s.io/client-go v0.36.2/go.mod h1:1vgO4OAlfPnoLcb+Rze2GF5rAr14w8qjrYMoyXJzQj0=
+k8s.io/client-go v0.36.3/go.mod h1:gcPwr0c87vjjG6HB6pWEqOeuYVoXSsREjzux2j6GF30=
-k8s.io/component-base v0.36.2 h1:Z0VH80O7Ng0HDZnZj3WRR3urEGa0kTwmO8CwEwjVK1w=
+k8s.io/component-base v0.36.3 h1:vc/UFvPCkW0irPz84LAodAL1j3f4xktPM6dDJIEheAY=
-k8s.io/component-base v0.36.2/go.mod h1:mGfFOA7Gwpdm1VW2cwSQYbiDIlz8GD2WGwH88QSeCyA=
+k8s.io/component-base v0.36.3/go.mod h1:hZbNFG+gCMl9EbykDGEu73feKP9/Cq6JsV4pTo9GTO8=
 k8s.io/klog/v2 v2.140.0 h1:Tf+J3AH7xnUzZyVVXhTgGhEKnFqye14aadWv7bzXdzc=
 k8s.io/klog/v2 v2.140.0/go.mod h1:o+/RWfJ6PwpnFn7OyAG3QnO47BFsymfEfrz6XyYSSp0=
 k8s.io/kube-openapi v0.0.0-20260603220949-865597e52e25 h1:mPMaPMpBij2V1Wv/fR+HW124vVGXXvOSS9ver/9yjWs=
 k8s.io/kube-openapi v0.0.0-20260603220949-865597e52e25/go.mod h1:V/QaCUYDa+0QpcHhVVc5l99Uz56wEMEXBSj9oCDkNDY=
-k8s.io/streaming v0.36.2 h1:NSKthPPg9UFSKsRauVJUVGH2Dvn8fhKmY4qrMkw/p98=
+k8s.io/streaming v0.36.3 h1:9rAaqBk0C0Pc7+/fqGekj07NV+/Xrew58p647A0JT8w=
-k8s.io/streaming v0.36.2/go.mod h1:z6fV3D+NVkoeqRMtWwlUZK6U17SY/LqNzOxWL6GyR/s=
+k8s.io/streaming v0.36.3/go.mod h1:z6fV3D+NVkoeqRMtWwlUZK6U17SY/LqNzOxWL6GyR/s=
 k8s.io/utils v0.0.0-20260707023825-cf1189d6abe3 h1:jVkFFVfXdXP74B/zbO3hM3hpSFD0xvhQ5U686DPurkE=
 k8s.io/utils v0.0.0-20260707023825-cf1189d6abe3/go.mod h1:M2s5JB1lIYP3jzZdorPLHXIPJzt9vv2muW5a6L9DtNM=
 sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.34.0 h1:hSfpvjjTQXQY2Fol2CS0QHMNs/WI1MOSGzCm1KhM5ec=
--- a/internal/cnpgi/metadata/constants.go
+++ b/internal/cnpgi/metadata/constants.go
@ -63,7 +63,7 @@ const (
 // Data is the metadata of this plugin.
 var Data = identity.GetPluginMetadataResponse{
 	Name:          PluginName,
-	Version:       "0.13.0", // x-release-please-version
+	Version:       "0.14.0", // x-release-please-version
 	DisplayName:   "BarmanCloudInstance",
 	ProjectUrl:    "https://github.com/cloudnative-pg/plugin-barman-cloud",
 	RepositoryUrl: "https://github.com/cloudnative-pg/plugin-barman-cloud",
--- a/test/e2e/internal/objectstore/azurite.go
+++ b/test/e2e/internal/objectstore/azurite.go
@ -73,7 +73,7 @@ func newAzuriteDeployment(namespace, name string) *appsv1.Deployment {
 							Name: name,
 							// renovate: datasource=docker depName=mcr.microsoft.com/azure-storage/azurite versioning=docker
 							// Version: 3.36.0
-							Image: "mcr.microsoft.com/azure-storage/azurite@sha256:37493d0f2e764467421ffe16eb3caa39277e5fa7f6adea18eb5bbfb3c5247f98",
+							Image: "mcr.microsoft.com/azure-storage/azurite@sha256:76b8127d608fab8287a14a4bfeb9a5502cdcffb4bf1e86f09f324ebb0e70edba",
 							Args: []string{
 								"azurite-blob",
 								"--blobHost",
--- a/test/e2e/internal/tests/walrestore/fixtures.go
+++ b/test/e2e/internal/tests/walrestore/fixtures.go
@ -121,8 +121,8 @@ func newS3ClientDeployment(namespace string) *appsv1.Deployment {
 						{
 							Name: s3ClientName,
 							// renovate: datasource=docker depName=amazon/aws-cli versioning=docker
-							// Version: 2.36.3
+							// Version: 2.36.9
-							Image:   "docker.io/amazon/aws-cli@sha256:bdd02067a00c354684086071b475955c54caa7bd88b851aac99a51326fe19652",
+							Image:   "docker.io/amazon/aws-cli@sha256:00dee8ccaf669721f8163944ea9e6ac13183851b23d5b7a9868a608bc932cfdb",
 							Command: []string{"sleep", "infinity"},
 							Env: []corev1.EnvVar{
 								{
--- a/web/versioned_docs/version-0.14.0/compression.md
+++ b/web/versioned_docs/version-0.14.0/compression.md
@ -0,0 +1,45 @@
 ---
 sidebar_position: 80
 ---
 # Compression
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 By default, backups and WAL files are archived **uncompressed**. However, the
 Barman Cloud Plugin supports multiple compression algorithms via
 `barman-cloud-backup` and `barman-cloud-wal-archive`, allowing you to optimize
 for space, speed, or a balance of both.
 ### Supported Compression Algorithms
 - `bzip2`
 - `gzip`
 - `lz4`
 - `snappy`
 - `xz` (WAL only)
 - `zstd` (WAL only)
 Compression settings for base backups and WAL archives are configured
 independently. For implementation details, refer to the corresponding API
 definitions:
 - [`DataBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#DataBackupConfiguration)
 - [`WALBackupConfiguration`](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#WalBackupConfiguration)
 :::important
 Compression impacts both performance and storage efficiency. Choose the right
 algorithm based on your recovery time objectives (RTO), storage capacity, and
 network throughput.
 :::
 ## Compression Benchmark (on MinIO)
 | Compression | Backup Time (ms) | Restore Time (ms) | Uncompressed Size (MB) | Compressed Size (MB) | Ratio |
 | ----------- | ---------------- | ----------------- | ---------------------- | -------------------- | ----- |
 | None        | 10,927           | 7,553             | 395                    | 395                  | 1.0:1 |
 | bzip2       | 25,404           | 13,886            | 395                    | 67                   | 5.9:1 |
 | gzip        | 116,281          | 3,077             | 395                    | 91                   | 4.3:1 |
 | snappy      | 8,134            | 8,341             | 395                    | 166                  | 2.4:1 |
 Numbers come from a 2021 Barman proof of concept ([EnterpriseDB/barman#344](https://github.com/EnterpriseDB/barman/issues/344#issuecomment-992547396)), which predates `lz4` support for base backups. `lz4` is not yet benchmarked.
--- a/web/versioned_docs/version-0.14.0/concepts.md
+++ b/web/versioned_docs/version-0.14.0/concepts.md
@ -0,0 +1,177 @@
 ---
 sidebar_position: 10
 ---
 # Main Concepts
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 :::important
 Before proceeding, make sure to review the following sections of the
 CloudNativePG documentation:
 - [**Backup**](https://cloudnative-pg.io/documentation/current/backup/)
 - [**WAL Archiving**](https://cloudnative-pg.io/documentation/current/wal_archiving/)
 - [**Recovery**](https://cloudnative-pg.io/documentation/current/recovery/)
 :::
 The **Barman Cloud Plugin** enables **hot (online) backups** of PostgreSQL
 clusters in CloudNativePG through [`barman-cloud`](https://pgbarman.org),
 supporting continuous physical backups and WAL archiving to an **object
 store**—without interrupting write operations.
 It also supports both **full recovery** and **Point-in-Time Recovery (PITR)**
 of a PostgreSQL cluster.
 ## The Object Store
 At the core is the [`ObjectStore` custom resource (CRD)](plugin-barman-cloud.v1.md#objectstorespec),
 which acts as the interface between the PostgreSQL cluster and the target
 object storage system. It allows you to configure:
 - **Authentication and bucket location** via the `.spec.configuration` section
 - **WAL archiving** settings—such as compression type, parallelism, and
  server-side encryption—under `.spec.configuration.wal`
 - **Base backup options**—with similar settings for compression, concurrency,
  and encryption—under `.spec.configuration.data`
 - **Retention policies** to manage the life-cycle of archived WALs and backups
  via `.spec.configuration.retentionPolicy`
 WAL files are archived in the `wals` directory, while base backups are stored
 as **tarballs** in the `base` directory, following the
 [Barman Cloud convention](https://docs.pgbarman.org/cloud/latest/usage/#object-store-layout).
 The plugin also offers advanced capabilities, including
 [backup tagging](misc.md#backup-object-tagging) and
 [extra options for backups and WAL archiving](misc.md#extra-options-for-backup-wal-archiving-and-restore).
 :::tip
 For details, refer to the
 [API reference for the `ObjectStore` resource](plugin-barman-cloud.v1.md#objectstorespec).
 :::
 ## Integration with a CloudNativePG Cluster
 CloudNativePG can delegate continuous backup and recovery responsibilities to
 the **Barman Cloud Plugin** by configuring the `.spec.plugins` section of a
 `Cluster` resource. This setup requires a corresponding `ObjectStore` resource
 to be defined.
 :::important
 While it is technically possible to reuse the same `ObjectStore` for multiple
 `Cluster` resources within the same namespace, it is strongly recommended to
 dedicate one object store per PostgreSQL cluster to ensure data isolation and
 operational clarity.
 :::
 The following example demonstrates how to configure a CloudNativePG cluster
 named `cluster-example` to use a previously defined `ObjectStore` (also named
 `cluster-example`) in the same namespace. Setting `isWALArchiver: true` enables
 WAL archiving through the plugin:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:
  name: cluster-example
 spec:
  # Other cluster settings...
  plugins:
    - name: barman-cloud.cloudnative-pg.io
      isWALArchiver: true
      parameters:
        barmanObjectName: cluster-example
 ```
 ## Backup of a Postgres Cluster
 Once the object store is defined and the `Cluster` is configured to use the
 Barman Cloud Plugin, **WAL archiving is activated immediately** on the
 PostgreSQL primary.
 Physical base backups are seamlessly managed by CloudNativePG using the
 `Backup` and `ScheduledBackup` resources, respectively for
 [on-demand](https://cloudnative-pg.io/documentation/current/backup/#on-demand-backups)
 and
 [scheduled](https://cloudnative-pg.io/documentation/current/backup/#scheduled-backups)
 backups.
 To use the Barman Cloud Plugin, you must set the `method` to `plugin` and
 configure the `pluginConfiguration` section as shown:
 ```yaml
 [...]
 spec:
  method: plugin
  pluginConfiguration:
    name: barman-cloud.cloudnative-pg.io
  [...]
 ```
 With this configuration, CloudNativePG supports:
 - Backups from both **primary** and **standby** instances
 - Backups from **designated primaries** in a distributed topology using
  [replica clusters](https://cloudnative-pg.io/documentation/current/replica_cluster/)
 :::tip
 For details on how to back up from a standby, refer to the official documentation:
 [Backup from a standby](https://cloudnative-pg.io/documentation/current/backup/#backup-from-a-standby).
 :::
 :::important
 Both backup and WAL archiving operations are executed by sidecar containers
 running in the same pod as the PostgreSQL `Cluster` primary instance—except
 when backups are taken from a standby, in which case the sidecar runs alongside
 the standby pod.
 The sidecar containers use a [dedicated container image](images.md) that
 includes only the supported version of Barman Cloud.
 :::
 ## Recovery of a Postgres Cluster
 In PostgreSQL, *recovery* refers to the process of starting a database instance
 from an existing backup.  The Barman Cloud Plugin integrates with CloudNativePG
 to support both **full recovery** and **Point-in-Time Recovery (PITR)** from an
 object store.
 Recovery in this context is *not in-place*: it bootstraps a brand-new
 PostgreSQL cluster from a backup and replays the necessary WAL files to reach
 the desired recovery target.
 To perform a recovery, define an *external cluster* that references the
 appropriate `ObjectStore`, and use it as the source in the `bootstrap` section
 of the target cluster:
 ```yaml
 [...]
 spec:
  [...]
  bootstrap:
    recovery:
      source: source
  externalClusters:
  - name: source
    plugin:
      name: barman-cloud.cloudnative-pg.io
      parameters:
        barmanObjectName: cluster-example
        serverName: cluster-example
  [...]
 ```
 The critical element here is the `externalClusters` section of the `Cluster`
 resource, where the `plugin` stanza instructs CloudNativePG to use the Barman
 Cloud Plugin to access the object store for recovery.
 This same mechanism can be used for a variety of scenarios enabled by the
 CloudNativePG API, including:
 * **Full cluster recovery** from the latest backup
 * **Point-in-Time Recovery (PITR)**
 * Bootstrapping **replica clusters** in a distributed topology
 :::tip
 For complete instructions and advanced use cases, refer to the official
 [Recovery documentation](https://cloudnative-pg.io/documentation/current/recovery/).
 :::
--- a/web/versioned_docs/version-0.14.0/images.md
+++ b/web/versioned_docs/version-0.14.0/images.md
@ -0,0 +1,37 @@
 ---
 sidebar_position: 99
 ---
 # Container Images
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 The Barman Cloud Plugin is distributed using two container images:
 - One for deploying the plugin components
 - One for the sidecar that runs alongside each PostgreSQL instance in a
  CloudNativePG `Cluster` using the plugin
 ## Plugin Container Image
 The plugin image contains the logic required to operate the Barman Cloud Plugin
 within your Kubernetes environment with CloudNativePG. It is published on the
 GitHub Container Registry at `ghcr.io/cloudnative-pg/plugin-barman-cloud`.
 This image is built from the
 [`Dockerfile.plugin`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.plugin)
 in the plugin repository.
 ## Sidecar Container Image
 The sidecar image is used within each PostgreSQL pod in the cluster. It
 includes the latest supported version of Barman Cloud and is responsible for
 performing WAL archiving and backups on behalf of CloudNativePG.
 It is available at `ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar` and is
 built from the
 [`Dockerfile.sidecar`](https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.sidecar).
 These sidecar images are designed to work seamlessly with the
 [`minimal` PostgreSQL container images](https://github.com/cloudnative-pg/postgres-containers?tab=readme-ov-file#minimal-images)
 maintained by the CloudNativePG Community.
--- a/web/versioned_docs/version-0.14.0/installation.mdx
+++ b/web/versioned_docs/version-0.14.0/installation.mdx
@ -0,0 +1,109 @@
 ---
 sidebar_position: 20
 ---
 # Installation
 :::important
 1. The plugin **must** be installed in the same namespace as the CloudNativePG
   operator (typically `cnpg-system`).
 2. Keep in mind that the operator's **listening namespaces** may differ from its
   installation namespace. Double-check this to avoid configuration issues.
 :::
 ## Verifying the Requirements
 Before installing the plugin, make sure the [requirements](intro.md#requirements) are met.
 ### CloudNativePG Version
 Ensure you're running a version of CloudNativePG that is compatible with the
 plugin. If installed in the default `cnpg-system` namespace, you can verify the
 version with:
 ```sh
 kubectl get deployment -n cnpg-system cnpg-controller-manager \
  -o jsonpath="{.spec.template.spec.containers[*].image}"
 ```
 Example output:
 ```output
 ghcr.io/cloudnative-pg/cloudnative-pg:1.26.0
 ```
 The version **must be 1.26 or newer**.
 ### cert-manager
 Use the [cmctl](https://cert-manager.io/docs/reference/cmctl/#installation)
 tool to confirm that `cert-manager` is installed and available:
 ```sh
 cmctl check api
 ```
 Example output:
 ```output
 The cert-manager API is ready
 ```
 Both checks are required before proceeding with the installation.
 ## Installing the Barman Cloud Plugin
 import { InstallationSnippet } from '@site/src/components/Installation';
 Install the plugin using `kubectl` by applying the manifest for the latest
 release:
 <InstallationSnippet />
 Example output:
 ```output
 customresourcedefinition.apiextensions.k8s.io/objectstores.barmancloud.cnpg.io created
 serviceaccount/plugin-barman-cloud created
 role.rbac.authorization.k8s.io/leader-election-role created
 clusterrole.rbac.authorization.k8s.io/metrics-auth-role created
 clusterrole.rbac.authorization.k8s.io/metrics-reader created
 clusterrole.rbac.authorization.k8s.io/objectstore-editor-role created
 clusterrole.rbac.authorization.k8s.io/objectstore-viewer-role created
 clusterrole.rbac.authorization.k8s.io/plugin-barman-cloud created
 rolebinding.rbac.authorization.k8s.io/leader-election-rolebinding created
 clusterrolebinding.rbac.authorization.k8s.io/metrics-auth-rolebinding created
 clusterrolebinding.rbac.authorization.k8s.io/plugin-barman-cloud-binding created
 secret/plugin-barman-cloud-8tfddg42gf created
 service/barman-cloud created
 deployment.apps/barman-cloud configured
 certificate.cert-manager.io/barman-cloud-client created
 certificate.cert-manager.io/barman-cloud-server created
 issuer.cert-manager.io/selfsigned-issuer created
 ```
 Finally, check that the deployment is up and running:
 ```sh
 kubectl rollout status deployment \
  -n cnpg-system barman-cloud
 ```
 Example output:
 ```output
 deployment "barman-cloud" successfully rolled out
 ```
 This confirms that the plugin is deployed and ready to use.
 ## Testing the latest development snapshot
 You can also test the latest development snapshot of the plugin with the
 following command:
 ```sh
 kubectl apply -f \
  https://raw.githubusercontent.com/cloudnative-pg/plugin-barman-cloud/refs/heads/main/manifest.yaml
 ```
--- a/web/versioned_docs/version-0.14.0/intro.md
+++ b/web/versioned_docs/version-0.14.0/intro.md
@ -0,0 +1,86 @@
 ---
 sidebar_position: 1
 sidebar_label: "Introduction"
 ---
 # Barman Cloud Plugin
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 The **Barman Cloud Plugin** for [CloudNativePG](https://cloudnative-pg.io/)
 enables online continuous physical backups of PostgreSQL clusters to object storage
 using the `barman-cloud` suite from the [Barman](https://docs.pgbarman.org/release/latest/)
 project.
 :::important
 If you plan to migrate your existing CloudNativePG cluster to the new
 plugin-based approach using the Barman Cloud Plugin, see
 ["Migrating from Built-in CloudNativePG Backup"](migration.md)
 for detailed instructions.
 :::
 ## Requirements
 Before using the Barman Cloud Plugin, ensure that the following components are
 installed and properly configured:
 - [CloudNativePG](https://cloudnative-pg.io) version 1.26 or later
  - We strongly recommend version 1.27.0 or later, which includes improved
    error handling and status reporting for the plugin.
  - If you are running an earlier release, refer to the
    [upgrade guide](https://cloudnative-pg.io/documentation/current/installation_upgrade).
 - [cert-manager](https://cert-manager.io/)
  - The recommended way to enable secure TLS communication between the plugin
    and the operator.
  - Alternatively, you can provide your own certificate bundles. See the
    [CloudNativePG documentation on TLS configuration](https://cloudnative-pg.io/documentation/current/cnpg_i/#configuring-tls-certificates).
 - [`kubectl-cnpg`](https://cloudnative-pg.io/documentation/current/kubectl-plugin/)
  plugin (optional but recommended)
  - Simplifies debugging and monitoring with additional status and inspection
    commands.
  - Multiple installation options are available in the
    [installation guide](https://cloudnative-pg.io/documentation/current/kubectl-plugin/#install).
 ## Key Features
 This plugin provides the following capabilities:
 - Physical online backup of the data directory
 - Physical restore of the data directory
 - Write-Ahead Log (WAL) archiving
 - WAL restore
 - Full cluster recovery
 - Point-in-Time Recovery (PITR)
 - Seamless integration with replica clusters for bootstrap and WAL restore from archive
 :::important
 The Barman Cloud Plugin is designed to **replace the in-tree object storage support**
 previously provided via the `.spec.backup.barmanObjectStore` section in the
 `Cluster` resource.
 Backups created using the in-tree approach are fully supported and compatible
 with this plugin.
 :::
 ## Supported Object Storage Providers
 The plugin works with all storage backends supported by `barman-cloud`, including:
 - **Amazon S3**
 - **Google Cloud Storage**
 - **Microsoft Azure Blob Storage**
 In addition, the following S3-compatible and simulator solutions have been
 tested and verified:
 - [MinIO](https://min.io/) – An S3-compatible storage solution
 - [Azurite](https://github.com/Azure/Azurite) – A simulator for Azure Blob Storage
 - [fake-gcs-server](https://github.com/fsouza/fake-gcs-server) – A simulator for Google Cloud Storage
 :::tip
 For more details, refer to [Object Store Providers](object_stores.md).
 :::
--- a/web/versioned_docs/version-0.14.0/migration.md
+++ b/web/versioned_docs/version-0.14.0/migration.md
@ -0,0 +1,274 @@
 ---
 sidebar_position: 40
 ---
 # Migrating from Built-in CloudNativePG Backup
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 The in-tree support for Barman Cloud in CloudNativePG is **deprecated starting
 from version 1.26** and will be removed in a future release.
 If you're currently relying on the built-in Barman Cloud integration, you can
 migrate seamlessly to the new **plugin-based architecture** using the Barman
 Cloud Plugin, without data loss. Follow these steps:
 - [Install the Barman Cloud Plugin](installation.mdx)
 - Create an `ObjectStore` resource by translating the contents of the
  `.spec.backup.barmanObjectStore` section from your existing `Cluster`
  definition
 - Modify the `Cluster` resource in a single atomic change to switch from
  in-tree backup to the plugin
 - Update any `ScheduledBackup` resources to use the plugin
 - Update the `externalClusters` configuration, where applicable
 :::tip
 For a working example, refer to [this commit](https://github.com/cloudnative-pg/cnpg-playground/commit/596f30e252896edf8f734991c3538df87630f6f7)
 from the [CloudNativePG Playground project](https://github.com/cloudnative-pg/cnpg-playground),
 which demonstrates a full migration.
 :::
 ---
 ## Step 1: Define the `ObjectStore`
 Begin by creating an `ObjectStore` resource in the same namespace as your
 PostgreSQL `Cluster`.
 There is a **direct mapping** between the `.spec.backup.barmanObjectStore`
 section in CloudNativePG and the `.spec.configuration` field in the
 `ObjectStore` CR. The conversion is mostly mechanical, with one key difference:
 :::warning
 In the plugin architecture, retention policies are defined as part of the `ObjectStore`.
 In contrast, the in-tree implementation defined them at the `Cluster` level.
 :::
 If your `Cluster` used `.spec.backup.retentionPolicy`, move that configuration
 to `.spec.retentionPolicy` in the `ObjectStore`.
 ---
 ### Example
 Here’s an excerpt from a traditional in-tree CloudNativePG backup configuration
 taken from the CloudNativePG Playground project:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:
  name: pg-eu
 spec:
  # [...]
  backup:
    barmanObjectStore:
      destinationPath: s3://backups/
      endpointURL: http://minio-eu:9000
      s3Credentials:
        accessKeyId:
          name: minio-eu
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: minio-eu
          key: ACCESS_SECRET_KEY
      wal:
        compression: gzip
 ```
 This configuration translates to the following `ObjectStore` resource for the
 plugin:
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: minio-eu
 spec:
  configuration:
    destinationPath: s3://backups/
    endpointURL: http://minio-eu:9000
    s3Credentials:
      accessKeyId:
        name: minio-eu
        key: ACCESS_KEY_ID
      secretAccessKey:
        name: minio-eu
        key: ACCESS_SECRET_KEY
    wal:
      compression: gzip
 ```
 As you can see, the contents of `barmanObjectStore` have been copied directly
 under the `configuration` field of the `ObjectStore` resource, using the same
 secret references.
 ## Step 2: Update the `Cluster` for plugin WAL archiving
 Once the `ObjectStore` resource is in place, update the `Cluster` resource as
 follows in a single atomic change:
 - Remove the `.spec.backup.barmanObjectStore` section
 - Remove `.spec.backup.retentionPolicy` if it was defined (as it is now in the
  `ObjectStore`)
 - Remove the entire `spec.backup` section if it is now empty
 - Add `barman-cloud.cloudnative-pg.io` to the `plugins` list, as described in
  [Configuring WAL archiving](usage.md#configuring-wal-archiving)
 This will trigger a rolling update of the `Cluster`, switching continuous
 backup from the in-tree implementation to the plugin-based approach.
 ### Example
 The updated `pg-eu` cluster will have this configuration instead of the
 previous `backup` section:
 ```yaml
  plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      barmanObjectName: minio-eu
 ```
 ---
 ## Step 3: Update the `ScheduledBackup`
 After switching the `Cluster` to use the plugin, update your `ScheduledBackup`
 resources to match.
 Set the backup `method` to `plugin` and reference the plugin name via
 `pluginConfiguration`, as shown in ["Performing a base backup"](usage.md#performing-a-base-backup).
 ### Example
 Original in-tree `ScheduledBackup`:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: ScheduledBackup
 metadata:
  name: pg-eu-backup
 spec:
  cluster:
    name: pg-eu
  schedule: '0 0 0 * * *'
  backupOwnerReference: self
 ```
 Updated version using the plugin:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: ScheduledBackup
 metadata:
  name: pg-eu-backup
 spec:
  cluster:
    name: pg-eu
  schedule: '0 0 0 * * *'
  backupOwnerReference: self
  method: plugin
  pluginConfiguration:
    name: barman-cloud.cloudnative-pg.io
 ```
 ---
 ## Step 4: Update the `externalClusters` configuration
 If your `Cluster` relies on one or more external clusters that use the in-tree
 Barman Cloud integration, you need to update those configurations to use the
 plugin-based architecture.
 When a replica cluster fetches WAL files or base backups from an external
 source that used the built-in backup method, follow these steps:
 1. Create a corresponding `ObjectStore` resource for the external cluster, as
   shown in [Step 1](#step-1-define-the-objectstore)
 2. Update the `externalClusters` section of your replica cluster to use the
   plugin instead of the in-tree `barmanObjectStore` field
 ### Example
 Consider the original configuration using in-tree Barman Cloud:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:
  name: pg-us
 spec:
  # [...]
  externalClusters:
  - name: pg-eu
    barmanObjectStore:
      destinationPath: s3://backups/
      endpointURL: http://minio-eu:9000
      serverName: pg-eu
      s3Credentials:
        accessKeyId:
          name: minio-eu
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: minio-eu
          key: ACCESS_SECRET_KEY
      wal:
        compression: gzip
 ```
 Create the `ObjectStore` resource for the external cluster:
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: minio-eu
 spec:
  configuration:
    destinationPath: s3://backups/
    endpointURL: http://minio-eu:9000
    s3Credentials:
    accessKeyId:
        name: minio-eu
        key: ACCESS_KEY_ID
    secretAccessKey:
        name: minio-eu
        key: ACCESS_SECRET_KEY
    wal:
      compression: gzip
 ```
 Update the external cluster configuration to use the plugin:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:
  name: pg-us
 spec:
  # [...]
  externalClusters:
  - name: pg-eu
    plugin:
      name: barman-cloud.cloudnative-pg.io
      parameters:
        barmanObjectName: minio-eu
        serverName: pg-eu
 ```
 ## Step 5: Verify your metrics
 When migrating from the in-core solution to the plugin-based approach, you need
 to monitor a different set of metrics, as described in the
 ["Observability"](observability.md) section.
 The table below summarizes the name changes between the old in-core metrics and
 the new plugin-based ones:
 | Old metric name                                  | New metric name                                                  |
 | ------------------------------------------------ | ---------------------------------------------------------------- |
 | `cnpg_collector_last_failed_backup_timestamp`    | `barman_cloud_cloudnative_pg_io_last_failed_backup_timestamp`    |
 | `cnpg_collector_last_available_backup_timestamp` | `barman_cloud_cloudnative_pg_io_last_available_backup_timestamp` |
 | `cnpg_collector_first_recoverability_point`      | `barman_cloud_cloudnative_pg_io_first_recoverability_point`      |
--- a/web/versioned_docs/version-0.14.0/misc.md
+++ b/web/versioned_docs/version-0.14.0/misc.md
@ -0,0 +1,126 @@
 ---
 sidebar_position: 90
 ---
 # Miscellaneous
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 ## Backup Object Tagging
 You can attach key-value metadata tags to backup artifacts—such as base
 backups, WAL files, and history files—via the `.spec.configuration` section of
 the `ObjectStore` resource.
 - `tags`: applied to base backups and WAL files
 - `historyTags`: applied to history files only
 ### Example
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: my-store
 spec:
  configuration:
    [...]
    tags:
      backupRetentionPolicy: "expire"
    historyTags:
      backupRetentionPolicy: "keep"
  [...]
 ```
 ## Extra Options for Backup, WAL Archiving, and Restore
 You can pass additional command-line arguments to the underlying
 `barman-cloud-*` commands using the corresponding fields in the `ObjectStore`
 configuration.
 - `.spec.configuration.data.additionalCommandArgs`: for `barman-cloud-backup`
 - `.spec.configuration.data.restoreAdditionalCommandArgs`: for `barman-cloud-restore`
 - `.spec.configuration.wal.archiveAdditionalCommandArgs`: for `barman-cloud-wal-archive`
 - `.spec.configuration.wal.restoreAdditionalCommandArgs`: for `barman-cloud-wal-restore`
 Each field accepts a list of string arguments. If an argument conflicts with
 one already set by the plugin, the user-provided value will be ignored. These
 fields are intended to pass options the plugin does not configure automatically.
 ### Example: Extra Backup Options
 ```yaml
 kind: ObjectStore
 metadata:
  name: my-store
 spec:
  configuration:
    data:
      additionalCommandArgs:
        - "--min-chunk-size=5MB"
        - "--read-timeout=60"
 ```
 ### Example: Extra Restore Options
 ```yaml
 kind: ObjectStore
 metadata:
  name: my-store
 spec:
  configuration:
    data:
      restoreAdditionalCommandArgs:
        - "--read-timeout=900"
 ```
 ### Example: Extra WAL Archive Options
 ```yaml
 kind: ObjectStore
 metadata:
  name: my-store
 spec:
  configuration:
    wal:
      archiveAdditionalCommandArgs:
        - "--max-concurrency=1"
        - "--read-timeout=60"
 ```
 ### Example: Extra WAL Restore Options
 ```yaml
 kind: ObjectStore
 metadata:
  name: my-store
 spec:
  configuration:
    wal:
      restoreAdditionalCommandArgs:
        - "--read-timeout=60"
 ```
 For a complete list of supported options, refer to the
 [official Barman Cloud documentation](https://docs.pgbarman.org/release/latest/).
 ## Enable the pprof debug server for the sidecar
 You can enable the instance sidecar's pprof debug HTTP server by adding the `--pprof-server=<address>` flag to the container's
 arguments via `.spec.instanceSidecarConfiguration.additionalContainerArgs`.
 Pass a bind address in the form `<host>:<port>` (for example, `0.0.0.0:6061`).
 An empty value disables the server (disabled by default).
 ### Example
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: my-store
 spec:
  instanceSidecarConfiguration:
    additionalContainerArgs:
      - "--pprof-server=0.0.0.0:6061"
 ```
--- a/web/versioned_docs/version-0.14.0/object_stores.md
+++ b/web/versioned_docs/version-0.14.0/object_stores.md
@ -0,0 +1,497 @@
 ---
 sidebar_position: 50
 ---
 # Object Store Providers
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 The Barman Cloud Plugin enables the storage of PostgreSQL cluster backup files
 in any object storage service supported by the
 [Barman Cloud infrastructure](https://docs.pgbarman.org/release/latest/).
 Currently, Barman Cloud supports the following providers:
 - [Amazon S3](#aws-s3)
 - [Microsoft Azure Blob Storage](#azure-blob-storage)
 - [Google Cloud Storage](#google-cloud-storage)
 You may also use any S3- or Azure-compatible implementation of the above
 services.
 To configure object storage with Barman Cloud, you must define an
 [`ObjectStore` object](plugin-barman-cloud.v1.md#objectstore), which
 establishes the connection between your PostgreSQL cluster and the object
 storage backend.
 Configuration details — particularly around authentication — will vary depending on
 the specific object storage provider you are using.
 The following sections detail the setup for each.
 :::note Authentication Methods
 The Barman Cloud Plugin does not independently test all authentication methods
 supported by `barman-cloud`. The plugin's responsibility is limited to passing
 the provided credentials to `barman-cloud`, which then handles authentication
 according to its own implementation. Users should refer to the
 [Barman Cloud documentation](https://docs.pgbarman.org/release/latest/) to
 verify that their chosen authentication method is supported and properly
 configured.
 :::
 ---
 ## AWS S3
 [AWS Simple Storage Service (S3)](https://aws.amazon.com/s3/) is one of the
 most widely adopted object storage solutions.
 The Barman Cloud plugin for CloudNativePG integrates with S3 through two
 primary authentication mechanisms:
 - [IAM Roles for Service Accounts (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) —
  recommended for clusters running on EKS
 - Access keys — using `ACCESS_KEY_ID` and `ACCESS_SECRET_KEY` credentials
 ### Access Keys
 To authenticate using access keys, you’ll need:
 - `ACCESS_KEY_ID`: the public key used to authenticate to S3
 - `ACCESS_SECRET_KEY`: the corresponding secret key
 - `ACCESS_SESSION_TOKEN`: (optional) a temporary session token, if required
 These credentials must be stored securely in a Kubernetes secret:
 ```sh
 kubectl create secret generic aws-creds \
  --from-literal=ACCESS_KEY_ID=<access key here> \
  --from-literal=ACCESS_SECRET_KEY=<secret key here>
 # --from-literal=ACCESS_SESSION_TOKEN=<session token here> # if required
 ```
 The credentials will be encrypted at rest if your Kubernetes environment
 supports it.
 You can then reference the secret in your `ObjectStore` definition:
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: aws-store
 spec:
  configuration:
    destinationPath: "s3://BUCKET_NAME/path/to/folder"
    s3Credentials:
      accessKeyId:
        name: aws-creds
        key: ACCESS_KEY_ID
      secretAccessKey:
        name: aws-creds
        key: ACCESS_SECRET_KEY
  [...]
 ```
 ### IAM Role for Service Account (IRSA)
 To use IRSA with EKS, configure the service account of the PostgreSQL cluster
 with the appropriate annotation:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:
  [...]
 spec:
  serviceAccountTemplate:
    metadata:
      annotations:
        eks.amazonaws.com/role-arn: arn:[...]
        [...]
 ```
 ### S3 Lifecycle Policy
 Barman Cloud uploads backup files to S3 but does not modify them afterward.
 To enhance data durability and protect against accidental or malicious loss,
 it's recommended to implement the following best practices:
 - Enable object versioning
 - Enable object locking to prevent objects from being deleted or overwritten
  for a defined period or indefinitely (this provides an additional layer of
  protection against accidental deletion and ransomware attacks)
 - Set lifecycle rules to expire current versions a few days after your Barman
  retention window
 - Expire non-current versions after a longer period
 These strategies help you safeguard backups without requiring broad delete
 permissions, ensuring both security and compliance with minimal operational
 overhead.
 ### S3-Compatible Storage Providers
 You can use S3-compatible services like **MinIO**, **Linode (Akamai) Object Storage**,
 or **DigitalOcean Spaces** by specifying a custom `endpointURL`.
 Example with Linode (Akamai) Object Storage (`us-east1`):
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: linode-store
 spec:
  configuration:
    destinationPath: "s3://BUCKET_NAME/"
    endpointURL: "https://us-east1.linodeobjects.com"
    s3Credentials:
    [...]
  [...]
 ```
 Recent changes to the [boto3 implementation](https://github.com/boto/boto3/issues/4392)
 of [Amazon S3 Data Integrity Protections](https://docs.aws.amazon.com/sdkref/latest/guide/feature-dataintegrity.html)
 may lead to the `x-amz-content-sha256` error when using the Barman Cloud
 Plugin.
 If you encounter this issue (see [GitHub issue #393](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/393)),
 you can apply the following workaround by setting specific environment
 variables in the `ObjectStore` resource:
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: linode-store
 spec:
  instanceSidecarConfiguration:
    env:
      - name: AWS_REQUEST_CHECKSUM_CALCULATION
        value: when_required
      - name: AWS_RESPONSE_CHECKSUM_VALIDATION
        value: when_required
  [...]
 ```
 These settings ensure that checksum calculations and validations are only
 applied when explicitly required, avoiding compatibility issues with certain
 S3-compatible storage providers.
 Example with DigitalOcean Spaces (SFO3, path-style):
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: digitalocean-store
 spec:
  configuration:
    destinationPath: "s3://BUCKET_NAME/path/to/folder"
    endpointURL: "https://sfo3.digitaloceanspaces.com"
    s3Credentials:
    [...]
  [...]
 ```
 ### Using Object Storage with a Private CA
 For object storage services (e.g., MinIO) that use HTTPS with certificates
 signed by a private CA, set the `endpointCA` field in the `ObjectStore`
 definition. Unless you already have it, create a Kubernetes `Secret` with the
 CA bundle:
 ```sh
 kubectl create secret generic my-ca-secret --from-file=ca.crt
 ```
 Then reference it:
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: minio-store
 spec:
  configuration:
    endpointURL: <myEndpointURL>
    endpointCA:
      name: my-ca-secret
      key: ca.crt
  [...]
 ```
 <!-- TODO: does this also apply to the plugin? -->
 :::note
 If you want `ConfigMaps` and `Secrets` to be **automatically** reloaded by
 instances, you can add a label with the key `cnpg.io/reload` to the
 `Secrets`/`ConfigMaps`. Otherwise, you will have to reload the instances using the
 `kubectl cnpg reload` subcommand.
 :::
 ---
 ## Azure Blob Storage
 [Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/)
 is Microsoft’s cloud-based object storage solution.
 Barman Cloud supports the following authentication methods:
 - [Connection String](https://learn.microsoft.com/en-us/azure/storage/common/storage-configure-connection-string)
 - Storage Account Name + [Storage Account Access Key](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage)
 - Storage Account Name + [Storage Account SAS Token](https://learn.microsoft.com/en-us/azure/storage/blobs/sas-service-create)
 - [Azure AD Managed Identity](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview)
 - [Default Azure Credentials](https://learn.microsoft.com/en-us/dotnet/api/azure.identity.defaultazurecredential?view=azure-dotnet)
 ### Azure AD Managed Identity
 This method avoids storing credentials in Kubernetes by enabling the
 usage of [Azure Managed Identities](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview) authentication mechanism.
 This can be enabled by setting the `inheritFromAzureAD` option to `true`.
 Managed Identity can be configured for the AKS Cluster by following
 the [Azure documentation](https://learn.microsoft.com/en-us/azure/aks/use-managed-identity?pivots=system-assigned).
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: azure-store
 spec:
  configuration:
    destinationPath: "<destination path here>"
    azureCredentials:
      inheritFromAzureAD: true
  [...]
 ```
 ### Default Azure Credentials
 The `useDefaultAzureCredentials` option enables the default Azure credentials
 flow, which uses [`DefaultAzureCredential`](https://learn.microsoft.com/en-us/python/api/azure-identity/azure.identity.defaultazurecredential)
 to automatically discover and use available credentials in the following order:
 1. **Environment Variables** — `AZURE_CLIENT_ID`, `AZURE_CLIENT_SECRET`, and `AZURE_TENANT_ID` for Service Principal authentication
 2. **Managed Identity** — Uses the managed identity assigned to the pod
 3. **Azure CLI** — Uses credentials from the Azure CLI if available
 4. **Azure PowerShell** — Uses credentials from Azure PowerShell if available
 This approach is particularly useful for getting started with development and testing; it allows
 the SDK to attempt multiple authentication mechanisms seamlessly across different environments.
 However, this is not recommended for production. Please refer to the
 [official Azure guidance](https://learn.microsoft.com/en-us/dotnet/azure/sdk/authentication/credential-chains?tabs=dac#usage-guidance-for-defaultazurecredential)
 for a comprehensive understanding of `DefaultAzureCredential`.
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: azure-store
 spec:
  configuration:
    destinationPath: "<destination path here>"
    azureCredentials:
      useDefaultAzureCredentials: true
  [...]
 ```
 ### Access Key, SAS Token, or Connection String
 Store credentials in a Kubernetes secret:
 ```sh
 kubectl create secret generic azure-creds \
  --from-literal=AZURE_STORAGE_ACCOUNT=<storage account name> \
  --from-literal=AZURE_STORAGE_KEY=<storage account key> \
  --from-literal=AZURE_STORAGE_SAS_TOKEN=<SAS token> \
  --from-literal=AZURE_STORAGE_CONNECTION_STRING=<connection string>
 ```
 Then reference the required keys in your `ObjectStore`:
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: azure-store
 spec:
  configuration:
    destinationPath: "<destination path here>"
    azureCredentials:
      connectionString:
        name: azure-creds
        key: AZURE_CONNECTION_STRING
      storageAccount:
        name: azure-creds
        key: AZURE_STORAGE_ACCOUNT
      storageKey:
        name: azure-creds
        key: AZURE_STORAGE_KEY
      storageSasToken:
        name: azure-creds
        key: AZURE_STORAGE_SAS_TOKEN
  [...]
 ```
 For Azure Blob, the destination path format is:
 ```
 <http|https>://<account-name>.<service-name>.core.windows.net/<container>/<blob>
 ```
 ### Azure-Compatible Providers
 If you're using a different implementation (e.g., Azurite or emulator):
 ```
 <http|https>://<local-machine-address>:<port>/<account-name>/<container>/<blob>
 ```
 ---
 ## Google Cloud Storage
 [Google Cloud Storage](https://cloud.google.com/storage/) is supported with two
 authentication modes:
 - **GKE Workload Identity** (recommended inside Google Kubernetes Engine)
 - **Service Account JSON key** via the `GOOGLE_APPLICATION_CREDENTIALS` environment variable
 ### GKE Workload Identity
 Use the [Workload Identity authentication](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
 when running in GKE:
 1. Set `googleCredentials.gkeEnvironment` to `true` in the `ObjectStore`
   resource
 2. Annotate the `serviceAccountTemplate` in the `Cluster` resource with the GCP
   service account
 For example, in the `ObjectStore` resource:
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: google-store
 spec:
  configuration:
    destinationPath: "gs://<bucket>/<folder>"
    googleCredentials:
      gkeEnvironment: true
 ```
 And in the `Cluster` resource:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 spec:
  serviceAccountTemplate:
    metadata:
      annotations:
        iam.gke.io/gcp-service-account: [...].iam.gserviceaccount.com
 ```
 ### Service Account JSON Key
 Follow Google’s [authentication setup](https://cloud.google.com/docs/authentication/getting-started),
 then:
 ```sh
 kubectl create secret generic backup-creds --from-file=gcsCredentials=gcs_credentials_file.json
 ```
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: google-store
 spec:
  configuration:
    destinationPath: "gs://<bucket>/<folder>"
    googleCredentials:
      applicationCredentials:
        name: backup-creds
        key: gcsCredentials
  [...]
 ```
 :::important
 This authentication method generates a JSON file within the container
 with all the credentials required to access your Google Cloud Storage
 bucket. As a result, if someone gains access to the `Pod`, they will also have
 write permissions to the bucket.
 :::
 ---
 ## MinIO Object Store
 In order to use the Tenant resource you first need to deploy the
 [MinIO operator](https://docs.min.io/community/minio-object-store/operations/deployments/installation.html).
 For the latest documentation of MinIO, please refer to the
 [MinIO official documentation](https://docs.min.io/community/minio-object-store/).
 MinIO Object Store's API is compatible with S3, and the default configuration of the Tenant
 will create these services:
 - `<tenant>-console` on port 9090 (with autocert) or 9443 (without autocert)
 - `<tenant>-hl` on port 9000
 Where `<tenant>` is the `metadata.name` you assigned to your Tenant resource.
 :::note
 The `<tenant>-console` service will only be available if you have enabled the
 [MinIO Console](https://docs.min.io/community/minio-object-store/administration/minio-console.html).
 For example, the following Tenant:
 ```yml
 apiVersion: minio.min.io/v2
 kind: Tenant
 metadata:
  name: cnpg-backups
 spec:
  [...]
 ```
 would have services called `cnpg-backups-console` and `cnpg-backups-hl` respectively.
 The `console` service is for managing the tenant, while the `hl` service exposes the S3
 compatible API. If your tenant is configured with `requestAutoCert` you will communicate
 to these services over HTTPS, if not you will use HTTP.
 For authentication you can use your username and password, or create an access key.
 Whichever method you choose, it has to be stored as a secret.
 ```sh
 kubectl create secret generic minio-creds \
  --from-literal=MINIO_ACCESS_KEY=<minio access key or username> \
  --from-literal=MINIO_SECRET_KEY=<minio secret key or password>
 ```
 Finally, create the Barman ObjectStore:
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: minio-store
 spec:
  configuration:
    destinationPath: s3://BUCKET_NAME/
    endpointURL: http://<tenant>-hl:9000
    s3Credentials:
      accessKeyId:
        name: minio-creds
        key: MINIO_ACCESS_KEY
      secretAccessKey:
        name: minio-creds
        key: MINIO_SECRET_KEY
  [...]
 ```
 :::important
 Verify on `s3://BUCKET_NAME/` the presence of archived WAL files before
 proceeding with a backup.
 :::
 ---
--- a/web/versioned_docs/version-0.14.0/observability.md
+++ b/web/versioned_docs/version-0.14.0/observability.md
@ -0,0 +1,24 @@
 ---
 sidebar_position: 55
 ---
 # Observability
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 The Barman Cloud Plugin exposes the following metrics through the native
 Prometheus exporter of the instance manager:
 - `barman_cloud_cloudnative_pg_io_last_failed_backup_timestamp`:
  the UNIX timestamp of the most recent failed backup.
 - `barman_cloud_cloudnative_pg_io_last_available_backup_timestamp`:
  the UNIX timestamp of the most recent successfully available backup.
 - `barman_cloud_cloudnative_pg_io_first_recoverability_point`:
  the UNIX timestamp representing the earliest point in time from which the
  cluster can be recovered.
 These metrics supersede the previously available in-core metrics that used the
 `cnpg_collector` prefix. The new metrics are exposed under the
 `barman_cloud_cloudnative_pg_io` prefix instead.
--- a/web/versioned_docs/version-0.14.0/parameters.md
+++ b/web/versioned_docs/version-0.14.0/parameters.md
@ -0,0 +1,19 @@
 ---
 sidebar_position: 100
 ---
 # Parameters
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 The following parameters are available for the Barman Cloud Plugin:
 - `barmanObjectName`: references the `ObjectStore` resource to be used by the
  plugin.
 - `serverName`: Specifies the server name in the object store.
 :::important
 The `serverName` parameter in the `ObjectStore` resource is retained solely for
 API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
 When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
 :::
--- a/web/versioned_docs/version-0.14.0/plugin-barman-cloud.v1.md
+++ b/web/versioned_docs/version-0.14.0/plugin-barman-cloud.v1.md
@ -0,0 +1,108 @@
 # API Reference
 ## Packages
 - [barmancloud.cnpg.io/v1](#barmancloudcnpgiov1)
 ## barmancloud.cnpg.io/v1
 Package v1 contains API Schema definitions for the barmancloud v1 API group
 ### Resource Types
 - [ObjectStore](#objectstore)
 #### InstanceSidecarConfiguration
 InstanceSidecarConfiguration defines the configuration for the sidecar that runs in the instance pods.
 _Appears in:_
 - [ObjectStoreSpec](#objectstorespec)
 | Field | Description | Required | Default | Validation |
 | --- | --- | --- | --- | --- |
 | `env` _[EnvVar](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#envvar-v1-core) array_ | The environment to be explicitly passed to the sidecar |  |  |  |
 | `retentionPolicyIntervalSeconds` _integer_ | The retentionCheckInterval defines the frequency at which the<br />system checks and enforces retention policies. |  | 1800 |  |
 | `resources` _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#resourcerequirements-v1-core)_ | Resources define cpu/memory requests and limits for the sidecar that runs in the instance pods. |  |  |  |
 | `additionalContainerArgs` _string array_ | AdditionalContainerArgs is an optional list of command-line arguments<br />to be passed to the sidecar container when it starts.<br />The provided arguments are appended to the container’s default arguments. |  |  |  |
 | `logLevel` _string_ | The log level for PostgreSQL instances. Valid values are: `error`, `warning`, `info` (default), `debug`, `trace` |  | info | Enum: [error warning info debug trace] <br /> |
 #### ObjectStore
 ObjectStore is the Schema for the objectstores API.
 | Field | Description | Required | Default | Validation |
 | --- | --- | --- | --- | --- |
 | `apiVersion` _string_ | `barmancloud.cnpg.io/v1` | True | | |
 | `kind` _string_ | `ObjectStore` | True | | |
 | `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | True |  |  |
 | `spec` _[ObjectStoreSpec](#objectstorespec)_ | Specification of the desired behavior of the ObjectStore.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status | True |  |  |
 | `status` _[ObjectStoreStatus](#objectstorestatus)_ | Most recently observed status of the ObjectStore. This data may not be up to<br />date. Populated by the system. Read-only.<br />More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status |  |  |  |
 #### ObjectStoreSpec
 ObjectStoreSpec defines the desired state of ObjectStore.
 _Appears in:_
 - [ObjectStore](#objectstore)
 | Field | Description | Required | Default | Validation |
 | --- | --- | --- | --- | --- |
 | `configuration` _[BarmanObjectStoreConfiguration](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration)_ | The configuration for the barman-cloud tool suite | True |  |  |
 | `retentionPolicy` _string_ | RetentionPolicy is the retention policy to be used for backups<br />and WALs (i.e. '60d'). The retention policy is expressed in the form<br />of `XXu` where `XX` is a positive integer and `u` is in `[dwm]` -<br />days, weeks, months. |  |  | Pattern: `^[1-9][0-9]*[dwm]$` <br /> |
 | `instanceSidecarConfiguration` _[InstanceSidecarConfiguration](#instancesidecarconfiguration)_ | The configuration for the sidecar that runs in the instance pods |  |  |  |
 #### ObjectStoreStatus
 ObjectStoreStatus defines the observed state of ObjectStore.
 _Appears in:_
 - [ObjectStore](#objectstore)
 | Field | Description | Required | Default | Validation |
 | --- | --- | --- | --- | --- |
 | `serverRecoveryWindow` _object (keys:string, values:[RecoveryWindow](#recoverywindow))_ | ServerRecoveryWindow maps each server to its recovery window | True |  |  |
 #### RecoveryWindow
 RecoveryWindow represents the time span between the first
 recoverability point and the last successful backup of a PostgreSQL
 server, defining the period during which data can be restored.
 _Appears in:_
 - [ObjectStoreStatus](#objectstorestatus)
 | Field | Description | Required | Default | Validation |
 | --- | --- | --- | --- | --- |
 | `firstRecoverabilityPoint` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The first recoverability point in a PostgreSQL server refers to<br />the earliest point in time to which the database can be<br />restored. | True |  |  |
 | `lastSuccessfulBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last successful backup time | True |  |  |
 | `lastFailedBackupTime` _[Time](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#time-v1-meta)_ | The last failed backup time | True |  |  |
--- a/web/versioned_docs/version-0.14.0/resource-name-migration.md
+++ b/web/versioned_docs/version-0.14.0/resource-name-migration.md
@ -0,0 +1,219 @@
 ---
 sidebar_position: 90
 ---
 # Resource name migration guide
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 :::warning
 Before proceeding with the migration process, please:
 1. **Read this guide in its entirety** to understand what changes will be made
 2. **Test in a non-production environment** first if possible
 3. **Ensure you have proper backups** of your cluster configuration
 This migration will delete old RBAC resources only after the
 `plugin-barman-cloud` upgrade. While the operation is designed to be safe, you
 should review and understand the changes before proceeding. The maintainers of
 this project are not responsible for any issues that may arise during
 migration.
 **Note:** This guide assumes you are using the default `cnpg-system` namespace.
 :::
 ## Overview
 Starting from version **0.8.0**, the `plugin-barman-cloud` deployment manifests
 use more specific, prefixed resource names to avoid conflicts with other
 components deployed in the same Kubernetes cluster.
 ## What Changed
 The following resources have been renamed to use proper prefixes.
 ### Cluster-scoped Resources
 | Old Name                   | New Name                                 |
 |----------------------------|------------------------------------------|
 | `metrics-auth-role`        | `barman-plugin-metrics-auth-role`        |
 | `metrics-auth-rolebinding` | `barman-plugin-metrics-auth-rolebinding` |
 | `metrics-reader`           | `barman-plugin-metrics-reader`           |
 | `objectstore-viewer-role`  | `barman-plugin-objectstore-viewer-role`  |
 | `objectstore-editor-role`  | `barman-plugin-objectstore-editor-role`  |
 ### Namespace-scoped Resources
 | Old Name                      | New Name                                    | Namespace     |
 |-------------------------------|---------------------------------------------|---------------|
 | `leader-election-role`        | `barman-plugin-leader-election-role`        | `cnpg-system` |
 | `leader-election-rolebinding` | `barman-plugin-leader-election-rolebinding` | `cnpg-system` |
 ## Why This Change?
 Using generic names for cluster-wide resources is discouraged as they may
 conflict with other components deployed in the same cluster. The new names make
 it clear that these resources belong to the Barman Cloud plugin and help avoid
 naming collisions.
 ## Migration Instructions
 This three steps migration process is straightforward and can be completed with
 a few `kubectl` commands.
 ### Step 1: Upgrade plugin-barman-cloud
 Please refer to the [Installation](installation.mdx) section to deploy the new
 `plugin-barman-cloud` release.
 ### Step 2: Delete Old Cluster-scoped Resources
 :::danger Verify Resources Before Deletion
 **IMPORTANT**: The old resource names are generic and could potentially belong
 to other components in your cluster.
 **Before deleting each resource, verify it belongs to the Barman Cloud plugin
 by checking:**
 - For `objectstore-*` roles: Look for `barmancloud.cnpg.io` in the API groups
 - For `metrics-*` roles: Check if they reference the `plugin-barman-cloud`
  ServiceAccount in `cnpg-system` namespace
 - For other roles: Look for labels like `app.kubernetes.io/name: plugin-barman-cloud`
 If a resource doesn't have these indicators, **DO NOT DELETE IT** as it may
 belong to another application.
 Carefully review the output of each verification command before proceeding with
 the `delete`.
 :::
 :::tip Dry Run First
 You can add `--dry-run=client` to any `kubectl delete` command to preview what
 would be deleted without actually removing anything.
 :::
 **Only proceed if you've verified these resources belong to the Barman Cloud
 plugin (see warning above).**
 For each resource below, first verify it belongs to Barman Cloud, then delete
 it:
 ```bash
 # 1. Check metrics-auth-rolebinding FIRST (we'll check the role after)
 # Look for references to plugin-barman-cloud ServiceAccount
 kubectl describe clusterrolebinding metrics-auth-rolebinding
 # If it references plugin-barman-cloud ServiceAccount in cnpg-system namespace,
 # delete it:
 kubectl delete clusterrolebinding metrics-auth-rolebinding
 # 2. Check metrics-auth-role
 # Look for references to authentication.k8s.io and authorization.k8s.io
 kubectl describe clusterrole metrics-auth-role
 # Verify it's not being used by any other rolebindings:
 kubectl get clusterrolebinding -o json \
  | jq -r '.items[] | select(.roleRef.name=="metrics-auth-role") \
  | .metadata.name'
 # If the above returns nothing (role is not in use) and the role looks like the
 # Barman Cloud one, delete it (see warnings section):
 kubectl delete clusterrole metrics-auth-role
 # 3. Check objectstore-viewer-role
 # Look for barmancloud.cnpg.io API group or
 # for `app.kubernetes.io/name: plugin-barman-cloud` label
 kubectl describe clusterrole objectstore-viewer-role
 # If it shows barmancloud.cnpg.io in API groups, delete it:
 kubectl delete clusterrole objectstore-viewer-role
 # 4. Check objectstore-editor-role
 # Look for barmancloud.cnpg.io API group or
 # for `app.kubernetes.io/name: plugin-barman-cloud` label
 kubectl describe clusterrole objectstore-editor-role
 # If it shows barmancloud.cnpg.io in API groups, delete it:
 kubectl delete clusterrole objectstore-editor-role
 # 5. Check metrics-reader (MOST DANGEROUS - very generic name)
 # First, check if it's being used by any rolebindings OTHER than barman's:
 kubectl get clusterrolebinding -o json | jq -r '.items[] \
  | select(.roleRef.name=="metrics-reader") \
  | "\(.metadata.name) -> \(.subjects[0].name) in \(.subjects[0].namespace)"'
 # If this shows ANY rolebindings, review them carefully. Only proceed if
 # they're all Barman-related.  Then check the role itself:
 kubectl describe clusterrole metrics-reader
 # If it ONLY has nonResourceURLs: /metrics and NO other rolebindings use it,
 # delete it:
 kubectl delete clusterrole metrics-reader
 ```
 :::warning
 The `metrics-reader` role is particularly dangerous to delete blindly. Many
 monitoring systems use this exact name. Only delete it if:
 1. You've verified it ONLY grants access to `/metrics`
 2. No other rolebindings reference it (checked with the jq command above)
 3. You're certain it was created by the Barman Cloud plugin
 If you're unsure, it's safer to leave it and let the new
 `barman-plugin-metrics-reader` role coexist with it.
 :::
 If any resource is not found during the `describe` command, that's okay - it
 means it was never created or already deleted. Simply skip the delete command
 for that resource.
 ### Step 3: Delete Old Namespace-scoped Resources
 Delete the old namespace-scoped resources in the `cnpg-system` namespace:
 ```bash
 # Delete the old leader-election resources
 kubectl delete role leader-election-role -n cnpg-system
 kubectl delete rolebinding leader-election-rolebinding -n cnpg-system
 ```
 If any resource is not found, that's okay - it means it was never created or
 already deleted.
 ## Impact
 - **Permissions:** If you have custom RBAC rules or tools that reference the
  old resource names, they will need to be updated.
 - **External Users:** If end users have been granted the
  `objectstore-viewer-role` or `objectstore-editor-role`, they will need to be
  re-granted the new role names (`barman-plugin-objectstore-viewer-role` and
  `barman-plugin-objectstore-editor-role`).
 ## Verification
 After migration, verify that the new resources are created:
 ```bash
 # Check cluster-scoped resources
 kubectl get clusterrole | grep barman
 kubectl get clusterrolebinding | grep barman
 # Check namespace-scoped resources
 kubectl get role,rolebinding -n cnpg-system | grep barman
 ```
 You should see the new prefixed resource names.
 ## Troubleshooting
 ### Plugin Not Starting After Migration
 If the plugin fails to start after migration, check:
 1. **ServiceAccount permissions:** Ensure the `plugin-barman-cloud` ServiceAccount is bound to the new roles:
   ```bash
   kubectl get clusterrolebinding barman-plugin-metrics-auth-rolebinding -o yaml
   kubectl get rolebinding barman-plugin-leader-election-rolebinding -n cnpg-system -o yaml
   ```
 2. **Role references:** Verify that the rolebindings reference the correct role names:
   ```bash
   kubectl describe rolebinding barman-plugin-leader-election-rolebinding -n cnpg-system
   kubectl describe clusterrolebinding barman-plugin-metrics-auth-rolebinding
   ```
 ## Support
 If you encounter issues during migration, please open an issue on the [GitHub
 repository](https://github.com/cloudnative-pg/plugin-barman-cloud/issues).
--- a/web/versioned_docs/version-0.14.0/retention.md
+++ b/web/versioned_docs/version-0.14.0/retention.md
@ -0,0 +1,38 @@
 ---
 sidebar_position: 60
 ---
 # Retention Policies
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 The Barman Cloud Plugin supports **automated cleanup of obsolete backups** via
 retention policies, configured in the `.spec.retentionPolicy` field of the
 `ObjectStore` resource.
 :::note
 This feature uses the `barman-cloud-backup-delete` command with the
 `--retention-policy "RECOVERY WINDOW OF {{ value }} {{ unit }}"` syntax.
 :::
 #### Example: 30-Day Retention Policy
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: my-store
 spec:
  [...]
  retentionPolicy: "30d"
 ````
 :::note
 A **recovery window retention policy** ensures the cluster can be restored to
 any point in time between the calculated *Point of Recoverability* (PoR) and
 the latest WAL archive. The PoR is defined as `current time - recovery window`.
 The **first valid backup** is the most recent backup completed before the PoR.
 Backups older than that are marked as *obsolete* and deleted after the next
 backup completes.
 :::
--- a/web/versioned_docs/version-0.14.0/troubleshooting.md
+++ b/web/versioned_docs/version-0.14.0/troubleshooting.md
@ -0,0 +1,591 @@
 ---
 sidebar_position: 90
 ---
 # Troubleshooting
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 This guide helps you diagnose and resolve common issues with the Barman Cloud
 plugin.
 :::important
 We are continuously improving the integration between CloudNativePG and the
 Barman Cloud plugin as it moves toward greater stability and maturity. For this
 reason, we recommend using the latest available version of both components.
 See the [*Requirements* section](intro.md#requirements) for details.
 :::
 :::note
 The following commands assume you installed the CloudNativePG operator in
 the default `cnpg-system` namespace. If you installed it in a different
 namespace, adjust the commands accordingly.
 :::
 ## Viewing Logs
 To troubleshoot effectively, you’ll often need to review logs from multiple
 sources:
 ```sh
 # View operator logs (includes plugin interaction logs)
 kubectl logs -n cnpg-system deployment/cnpg-controller-manager -f
 # View plugin manager logs
 kubectl logs -n cnpg-system deployment/barman-cloud -f
 # View sidecar container logs (Barman Cloud operations)
 kubectl logs -n <namespace> <cluster-pod-name> -c plugin-barman-cloud -f
 # View all containers in a pod
 kubectl logs -n <namespace> <cluster-pod-name> --all-containers=true
 # View previous container logs (if container restarted)
 kubectl logs -n <namespace> <cluster-pod-name> -c plugin-barman-cloud --previous
 ```
 ## Common Issues
 ### Plugin Installation Issues
 #### Plugin pods not starting
 **Symptoms:**
 - Plugin pods stuck in `CrashLoopBackOff` or `Error`
 - Plugin deployment not ready
 **Possible causes and solutions:**
 1. **Certificate issues**
   ```sh
   # Check if cert-manager is installed and running
   kubectl get pods -n cert-manager
   # Check if the plugin certificate is created
   kubectl get certificates -n cnpg-system
   ```
   If cert-manager is not installed, install it first:
   ```sh
   # Note: other installation methods for cert-manager are available
   kubectl apply -f \
     https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml
   ```
   If you are using your own certificates without cert-manager, you will need
   to verify the entire certificate chain yourself.
 2. **Image pull errors**
   ```sh
   # Check pod events for image pull errors
   kubectl describe pod -n cnpg-system -l app=barman-cloud
   ```
   Verify the image exists and you have proper credentials if using a private
   registry.
 3. **Resource constraints**
   ```sh
   # Check node resources
   kubectl top nodes
   kubectl describe nodes
   ```
   Make sure your cluster has sufficient CPU and memory resources.
 ### Backup Failures
 #### Quick Backup Troubleshooting Checklist
 When a backup fails, follow these steps in order:
 1. **Check backup status**:
   ```sh
   kubectl get backups.postgresql.cnpg.io -n <namespace>
   ```
 2. **Get error details and target pod**:
   ```sh
   kubectl describe backups.postgresql.cnpg.io \
     -n <namespace> <backup-name>
   kubectl get backups.postgresql.cnpg.io \
     -n <namespace> <backup-name> \
     -o jsonpath='{.status.instanceID.podName}'
   ```
 3. **Check the target pod’s sidecar logs**:
   ```sh
   TARGET_POD=$(kubectl get backups.postgresql.cnpg.io \
     -n <namespace> <backup-name> \
     -o jsonpath='{.status.instanceID.podName}')
   kubectl logs \
     -n <namespace> $TARGET_POD -c plugin-barman-cloud \
     --tail=100 | grep -E "ERROR|FATAL|panic"
   ```
 4. **Check cluster events**:
   ```sh
   kubectl get events -n <namespace> \
     --field-selector involvedObject.name=<cluster-name> \
     --sort-by='.lastTimestamp'
   ```
 5. **Verify plugin is running**:
   ```sh
   kubectl get pods \
     -n cnpg-system -l app=barman-cloud
   ```
 6. **Check operator logs**:
   ```sh
   kubectl logs \
     -n cnpg-system deployment/cnpg-controller-manager \
     --tail=100 | grep -i "backup\|plugin"
   ```
 7. **Check plugin manager logs**:
   ```sh
   kubectl logs \
     -n cnpg-system deployment/barman-cloud --tail=100
   ```
 #### Backup job fails immediately
 **Symptoms:**
 - Backup pods terminate with error
 - No backup files appear in object storage
 - Backup shows `failed` phase with various error messages
 **Common failure modes and solutions:**
 1. **"requested plugin is not available" errors**
   ```
   requested plugin is not available: barman
   requested plugin is not available: barman-cloud
   requested plugin is not available: barman-cloud.cloudnative-pg.io
   ```
   **Cause:** The plugin name in the Cluster configuration doesn’t match the
   deployed plugin, or the plugin isn’t registered.
   **Solution:** 
   a. **Check plugin registration:**
   ```sh
   # If you have the `cnpg` plugin installed (v1.27.0+)
   kubectl cnpg status -n <namespace> <cluster-name>
   ```
   Look for the "Plugins status" section:
   ```
   Plugins status
   Name                            Version  Status  Reported Operator Capabilities
   ----                            -------  ------  ------------------------------
   barman-cloud.cloudnative-pg.io  0.6.0    N/A     Reconciler Hooks, Lifecycle Service
   ```
   b. **Verify plugin name in `Cluster` spec**:
   ```yaml
   apiVersion: postgresql.cnpg.io/v1
   kind: Cluster
   spec:
     plugins:
       - name: barman-cloud.cloudnative-pg.io
         parameters:
           barmanObjectName: <your-objectstore-name>
   ```
   c. **Check plugin deployment is running**:
   ```sh
   kubectl get deployment -n cnpg-system barman-cloud
   ```
 2. **"rpc error: code = Unknown desc = panic caught: assignment to entry in nil map" errors**
   **Cause:** Misconfiguration in the `ObjectStore` (e.g., typo or missing field).
   **Solution:** 
   - Review sidecar logs for details
   - Verify `ObjectStore` configuration and secrets
   - Common issues include:
     - Missing or incorrect secret references
     - Typos in configuration parameters
     - Missing required environment variables in secrets
 #### Backup performance issues
 **Symptoms:**
 - Backups take extremely long
 - Backups timeout
 **Plugin-specific considerations:**
 1. **Check `ObjectStore` parallelism settings**
   - Adjust `maxParallel` in `ObjectStore` configuration
   - Monitor sidecar container resource usage during backups
 2. **Verify plugin resource allocation**
   - Check if the sidecar container has sufficient CPU/memory
   - Review plugin container logs for resource-related warnings
 :::tip
 For Barman-specific features like compression, encryption, and performance
 tuning, refer to the [Barman documentation](https://docs.pgbarman.org/latest/).
 :::
 ### WAL Archiving Issues
 #### WAL archiving stops
 **Symptoms:**
 - WAL files accumulate on the primary
 - Cluster shows WAL archiving warnings
 - Sidecar logs show WAL errors
 **Debugging steps:**
 1. **Check plugin sidecar logs for WAL archiving errors**
   ```sh
   # Check recent WAL archive operations in sidecar
   kubectl logs -n <namespace> <primary-pod> -c plugin-barman-cloud \
     --tail=50 | grep -i wal
   ```
 2. **Check ObjectStore configuration for WAL settings**
   - Ensure ObjectStore has proper WAL retention settings
   - Verify credentials have permissions for WAL operations
 ### Restore Issues
 #### Restore fails during recovery
 **Symptoms:**
 - New cluster stuck in recovery
 - Plugin sidecar shows restore errors
 - PostgreSQL won’t start
 **Debugging steps:**
 1. **Check plugin sidecar logs during restore**
   ```sh
   # Check the sidecar logs on the recovering cluster pods
   kubectl logs -n <namespace> <cluster-pod-name> \
     -c plugin-barman-cloud --tail=100
   # Look for restore-related errors
   kubectl logs -n <namespace> <cluster-pod-name> \
     -c plugin-barman-cloud | grep -E "restore|recovery|ERROR"
   ```
 2. **Verify plugin can access backups**
   ```sh
   # Check if `ObjectStore` is properly configured for restore
   kubectl get objectstores.barmancloud.cnpg.io \
     -n <namespace> <objectstore-name> -o yaml
   # Check PostgreSQL recovery logs
   kubectl logs -n <namespace> <cluster-pod> \
     -c postgres | grep -i recovery
   ```
 :::tip
 For detailed Barman restore operations and troubleshooting, refer to the
 [Barman documentation](https://docs.pgbarman.org/latest/barman-cloud-restore.html).
 :::
 #### Point-in-time recovery (PITR) configuration issues
 **Symptoms:**
 - PITR doesn’t reach target time
 - WAL access errors
 - Recovery halts early
 **Debugging steps:**
 1. **Verify PITR configuration in the `Cluster` spec**
   ```yaml
   apiVersion: postgresql.cnpg.io/v1
   kind: Cluster
   metadata:
     name: <cluster-restore-name>
   spec:
     storage:
       size: 1Gi
     bootstrap:
       recovery:
         source: origin
         recoveryTarget:
           targetTime: "2024-01-15T10:30:00Z"
     externalClusters:
       - name: origin
         plugin:
           enabled: true
           name: barman-cloud.cloudnative-pg.io
           parameters:
             barmanObjectName: <object-store-name>
             serverName: <source-cluster-name>
   ```
 2. **Check sidecar logs for WAL-related errors**
   ```sh
   kubectl logs -n <namespace> <cluster-pod> \
     -c plugin-barman-cloud | grep -i wal
   ```
 :::note
 Timestamps without an explicit timezone suffix
 (e.g., `2024-01-15 10:30:00`) are interpreted as UTC.
 :::
 :::warning
 Always specify an explicit timezone in your timestamp to avoid ambiguity.
 For example, use `2024-01-15T10:30:00Z` or `2024-01-15T10:30:00+02:00`
 instead of `2024-01-15 10:30:00`.
 :::
 :::note
 For detailed PITR configuration and WAL management, see the
 [Barman PITR documentation](https://docs.pgbarman.org/latest/).
 :::
 ### Plugin Configuration Issues
 #### Plugin cannot connect to object storage
 **Symptoms:**
 - Sidecar logs show connection errors
 - Backups fail with authentication or network errors
 - `ObjectStore` resource reports errors
 **Solution:**
 1. **Verify `ObjectStore` CRD configuration and secrets**
   ```sh
   # Check ObjectStore resource status
   kubectl get objectstores.barmancloud.cnpg.io \
     -n <namespace> <objectstore-name> -o yaml
   # Verify the secret exists and has correct keys for your provider
   kubectl get secret -n <namespace> <secret-name> \
     -o jsonpath='{.data}' | jq 'keys'
   ```
 2. **Check sidecar logs for connectivity issues**
   ```sh
   kubectl logs -n <namespace> <cluster-pod> \
     -c plugin-barman-cloud | grep -E "connect|timeout|SSL|cert"
   ```
 3. **Adjust provider-specific settings (endpoint, path style, etc.)**
   - See [Object Store Configuration](object_stores.md) for provider-specific settings
   - Ensure `endpointURL` is set correctly for your storage provider
   - Verify network policies allow egress to your storage provider
 ## Diagnostic Commands
 ### Using the `cnpg` plugin for `kubectl`
 The `cnpg` plugin for `kubectl` provides extended debugging capabilities.
 Keep it updated:
 ```sh
 # Install or update the `cnpg` plugin
 kubectl krew install cnpg
 # Or using an alternative method: https://cloudnative-pg.io/documentation/current/kubectl-plugin/#install
 # Check plugin status (requires CNPG 1.27.0+)
 kubectl cnpg status <cluster-name> -n <namespace>
 # View cluster status in detail
 kubectl cnpg status <cluster-name> -n <namespace> --verbose
 ```
 ## Getting Help
 If problems persist:
 1. **Check the documentation**
   - [Installation Guide](installation.mdx)
   - [Object Store Configuration](object_stores.md) (for provider-specific settings)
   - [Usage Examples](usage.md)
 2. **Gather diagnostic information**
   ```sh
   # Create a diagnostic bundle (⚠️ sanitize these before sharing!)
   kubectl get objectstores.barmancloud.cnpg.io -A -o yaml > /tmp/objectstores.yaml
   kubectl get clusters.postgresql.cnpg.io -A -o yaml > /tmp/clusters.yaml
   kubectl logs -n cnpg-system deployment/barman-cloud --tail=1000 > /tmp/plugin.log
   ```
 3. **Community support**
   - CloudNativePG Slack: [#cloudnativepg-users](https://cloud-native.slack.com/messages/cloudnativepg-users)
   - GitHub Issues: [plugin-barman-cloud](https://github.com/cloudnative-pg/plugin-barman-cloud/issues)
 4. **Include when reporting**
   - CloudNativePG version
   - Plugin version
   - Kubernetes version
   - Cloud provider and region
   - Relevant configuration (⚠️ sanitize/redact sensitive information)
   - Error messages and logs
   - Steps to reproduce
 ## Known Issues and Limitations
 ### Current Known Issues
 1. **Migration compatibility**: After migrating from in-tree backup to the
   plugin, the `kubectl cnpg backup` command syntax has changed
   ([#353](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/353)):
   ```sh
   # Old command (in-tree, no longer works after migration)
   kubectl cnpg backup -n <namespace> <cluster-name> \
     --method=barmanObjectStore
   # New command (plugin-based)
   kubectl cnpg backup -n <namespace> <cluster-name> \
     --method=plugin --plugin-name=barman-cloud.cloudnative-pg.io
   ```
 ### Plugin Limitations
 1. **Installation method**: Currently only supports manifest and Kustomize
   installation ([#351](https://github.com/cloudnative-pg/plugin-barman-cloud/issues/351) -
   Helm chart requested)
 2. **Sidecar resource sharing**: The plugin sidecar container shares pod
   resources with PostgreSQL
 3. **Plugin restart behavior**: Restarting the sidecar container requires
   restarting the entire PostgreSQL pod
 ## Recap of General Debugging Steps
 ### Check Backup Status and Identify the Target Instance
 ```sh
 # List all backups and their status
 kubectl get backups.postgresql.cnpg.io -n <namespace>
 # Get detailed backup information including error messages and target instance
 kubectl describe backups.postgresql.cnpg.io \
  -n <namespace> <backup-name>
 # Extract the target pod name from a failed backup
 kubectl get backups.postgresql.cnpg.io \
  -n <namespace> <backup-name> \
  -o jsonpath='{.status.instanceID.podName}'
 # Get more details including the target pod, method, phase, and error
 kubectl get backups.postgresql.cnpg.io \
  -n <namespace> <backup-name> \
  -o jsonpath='Pod: {.status.instanceID.podName}{"\n"}Method: {.status.method}{"\n"}Phase: {.status.phase}{"\n"}Error: {.status.error}{"\n"}'
 # Check the cluster status for backup-related information
 kubectl cnpg status <cluster-name> -n <namespace> --verbose
 ```
 ### Check Sidecar Logs on the Backup Target Pod
 ```sh
 # Identify which pod was the backup target (from the previous step)
 TARGET_POD=$(kubectl get backups.postgresql.cnpg.io \
  -n <namespace> <backup-name> \
  -o jsonpath='{.status.instanceID.podName}')
 echo "Backup target pod: $TARGET_POD"
 # Check the sidecar logs on the specific target pod
 kubectl logs -n <namespace> $TARGET_POD \
  -c plugin-barman-cloud --tail=100
 # Follow the logs in real time
 kubectl logs -n <namespace> $TARGET_POD \
  -c plugin-barman-cloud -f
 # Check for specific errors in the target pod around the backup time
 kubectl logs -n <namespace> $TARGET_POD \
  -c plugin-barman-cloud --since=10m | grep -E "ERROR|FATAL|panic|failed"
 # Alternative: List all cluster pods and their roles
 kubectl get pods -n <namespace> -l cnpg.io/cluster=<cluster-name> \
  -o custom-columns=NAME:.metadata.name,ROLE:.metadata.labels.cnpg\\.io/instanceRole,INSTANCE:.metadata.labels.cnpg\\.io/instanceName
 # Check sidecar logs on ALL cluster pods (if the target is unclear)
 for pod in $(kubectl get pods -n <namespace> -l cnpg.io/cluster=<cluster-name> -o name); do
  echo "=== Checking $pod ==="
  kubectl logs -n <namespace> $pod -c plugin-barman-cloud \
    --tail=20 | grep -i error || echo "No errors found"
 done
 ```
 ### Check Events for Backup-Related Issues
 ```sh
 # Check events for the cluster
 kubectl get events -n <namespace> \
  --field-selector involvedObject.name=<cluster-name>
 # Check events for failed backups
 kubectl get events -n <namespace> \
  --field-selector involvedObject.kind=Backup
 # Get all recent events in the namespace
 kubectl get events -n <namespace> --sort-by='.lastTimestamp' | tail -20
 ```
 ### Verify `ObjectStore` Configuration
 ```sh
 # Check the ObjectStore resource
 kubectl get objectstores.barmancloud.cnpg.io \
  -n <namespace> <objectstore-name> -o yaml
 # Verify the secret exists and has the correct keys
 kubectl get secret -n <namespace> <secret-name> -o yaml
 # Alternatively
 kubectl get secret -n <namespace> <secret-name> -o jsonpath='{.data}' | jq 'keys'
 ```
 ### Common Error Messages and Solutions
 * **"AccessDenied" or "403 Forbidden"** — Check cloud credentials and bucket permissions.
 * **"NoSuchBucket"** — Verify the bucket exists and the endpoint URL is correct.
 * **"Connection timeout"** — Check network connectivity and firewall rules.
 * **"SSL certificate problem"** — For self-signed certificates, verify the CA bundle configuration.
--- a/web/versioned_docs/version-0.14.0/upgrades.mdx
+++ b/web/versioned_docs/version-0.14.0/upgrades.mdx
@ -0,0 +1,16 @@
 ---
 sidebar_position: 25
 ---
 # Upgrades
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 You can upgrade the plugin simply by installing the new version. Unless
 explicitly stated below or in the release notes, no special steps are required.
 ## Upgrading to version 0.8.x from previous versions
 Version **0.8.0** introduces breaking changes to resource naming.
 To complete the upgrade successfully, follow the instructions in the
 ["Resource name migration guide"](resource-name-migration.md).
--- a/web/versioned_docs/version-0.14.0/usage.md
+++ b/web/versioned_docs/version-0.14.0/usage.md
@ -0,0 +1,283 @@
 ---
 sidebar_position: 30
 ---
 # Using the Barman Cloud Plugin
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 After [installing the plugin](installation.mdx) in the same namespace as the
 CloudNativePG operator, enabling your PostgreSQL cluster to use the Barman
 Cloud Plugin involves just a few steps:
 - Defining the object store containing your WAL archive and base backups, using
  your preferred [provider](object_stores.md)
 - Instructing the Postgres cluster to use the Barman Cloud Plugin
 From that moment, you’ll be able to issue on-demand backups or define a backup
 schedule, as well as rely on the object store for recovery operations.
 The rest of this page details each step, using MinIO as object store provider.
 ## Defining the `ObjectStore`
 An `ObjectStore` resource must be created for each object store used in your
 PostgreSQL architecture. Here's an example configuration using MinIO:
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: minio-store
 spec:
  configuration:
    destinationPath: s3://backups/
    endpointURL: http://minio:9000
    s3Credentials:
      accessKeyId:
        name: minio
        key: ACCESS_KEY_ID
      secretAccessKey:
        name: minio
        key: ACCESS_SECRET_KEY
    wal:
      compression: gzip
 ```
 The `.spec.configuration` schema follows the same format as the
 [in-tree barman-cloud support](https://pkg.go.dev/github.com/cloudnative-pg/barman-cloud/pkg/api#BarmanObjectStoreConfiguration).
 Refer to [the CloudNativePG documentation](https://cloudnative-pg.io/documentation/current/appendixes/backup_barmanobjectstore/)
 for additional details.
 :::important
 The `serverName` parameter in the `ObjectStore` resource is retained solely for
 API compatibility with the in-tree `barmanObjectStore` and must always be left empty.
 When needed, use the `serverName` plugin parameter in the Cluster configuration instead.
 :::
 ## Configuring WAL Archiving
 Once the `ObjectStore` is defined, you can configure your PostgreSQL cluster
 to archive WALs by referencing the store in the `.spec.plugins` section:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:
  name: cluster-example
 spec:
  instances: 3
  imagePullPolicy: Always
  plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      barmanObjectName: minio-store
  storage:
    size: 1Gi
 ```
 This configuration enables both WAL archiving and data directory backups.
 ## Performing a Base Backup
 Once WAL archiving is enabled, the cluster is ready for backups. Backups can be
 created either declaratively (with YAML manifests) or imperatively (with the
 `cnpg` plugin).
 ### Declarative approach (YAML manifest)
 Create a backup resource by applying a YAML manifest:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Backup
 metadata:
  name: backup-example
 spec:
  cluster:
    name: cluster-example
  method: plugin
  pluginConfiguration:
    name: barman-cloud.cloudnative-pg.io
 ```
 ### Imperative approach (using the `cnpg` plugin)
 The quickest way to trigger an on-demand backup is with the `cnpg` plugin:
 ```bash
 kubectl cnpg backup -n <namespace> <cluster-name> \
  --method=plugin \
  --plugin-name=barman-cloud.cloudnative-pg.io
 ```
 :::note Migration from in-tree backups
 If you are migrating from the in-tree backup system, note the change in syntax:
 ```bash
 # Old command (in-tree backup)
 kubectl cnpg backup -n <namespace> <cluster-name> --method=barmanObjectStore
 # New command (plugin-based backup)
 kubectl cnpg backup -n <namespace> <cluster-name> \
  --method=plugin \
  --plugin-name=barman-cloud.cloudnative-pg.io
 ```
 :::
 ## Restoring a Cluster
 To restore a cluster from an object store, create a new `Cluster` resource that
 references the store containing the backup. Below is an example configuration:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:
  name: cluster-restore
 spec:
  instances: 3
  imagePullPolicy: IfNotPresent
  bootstrap:
    recovery:
      source: source
  externalClusters:
  - name: source
    plugin:
      name: barman-cloud.cloudnative-pg.io
      parameters:
        barmanObjectName: minio-store
        serverName: cluster-example
  storage:
    size: 1Gi
 ```
 :::important
 The above configuration does **not** enable WAL archiving for the restored cluster.
 :::
 To enable WAL archiving for the restored cluster, include the `.spec.plugins`
 section alongside the `externalClusters.plugin` section, as shown below:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:
  name: cluster-restore
 spec:
  instances: 3
  imagePullPolicy: IfNotPresent
  bootstrap:
    recovery:
      source: source
  plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      # Backup Object Store (push, read-write)
      barmanObjectName: minio-store-bis
  externalClusters:
  - name: source
    plugin:
      name: barman-cloud.cloudnative-pg.io
      parameters:
        # Recovery Object Store (pull, read-only)
        barmanObjectName: minio-store
        serverName: cluster-example
  storage:
    size: 1Gi
 ```
 The same object store may be used for both transaction log archiving and
 restoring a cluster, or you can configure separate stores for these purposes.
 ## Configuring Replica Clusters
 You can set up a distributed topology by combining the previously defined
 configurations with the `.spec.replica` section. Below is an example of how to
 define a replica cluster:
 ```yaml
 apiVersion: postgresql.cnpg.io/v1
 kind: Cluster
 metadata:
  name: cluster-dc-a
 spec:
  instances: 3
  primaryUpdateStrategy: unsupervised
  storage:
    storageClass: csi-hostpath-sc
    size: 1Gi
  plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      barmanObjectName: minio-store-a
  replica:
    self: cluster-dc-a
    primary: cluster-dc-a
    source: cluster-dc-b
  externalClusters:
  - name: cluster-dc-a
    plugin:
      name: barman-cloud.cloudnative-pg.io
      parameters:
        barmanObjectName: minio-store-a
  - name: cluster-dc-b
    plugin:
      name: barman-cloud.cloudnative-pg.io
      parameters:
        barmanObjectName: minio-store-b
 ```
 ## Configuring the plugin instance sidecar
 The Barman Cloud Plugin runs as a sidecar container next to each PostgreSQL
 instance pod. It manages backup, WAL archiving, and restore processes.
 Configuration comes from multiple `ObjectStore` resources:
 1. The one referenced in the
   `.spec.plugins` section of the `Cluster`. This is the
   object store used for WAL archiving and base backups.
 2. The one referenced in the external cluster
   used in the `.spec.replica.source` section of the `Cluster`. This is
   used by the log-shipping designated primary to get the WAL files.
 3. The one referenced in the
   `.spec.bootstrap.recovery.source` section of the `Cluster`. Used by
   the initial recovery job to create the cluster from an existing backup.
 You can fine-tune sidecar behavior in the `.spec.instanceSidecarConfiguration`
 of your ObjectStore. These settings apply to all PostgreSQL instances that use
 this object store. Any updates take effect at the next `Cluster` reconciliation,
 and could generate a rollout of the `Cluster`.
 ```yaml
 apiVersion: barmancloud.cnpg.io/v1
 kind: ObjectStore
 metadata:
  name: minio-store
 spec:
  configuration:
  # [...]
  instanceSidecarConfiguration:
    retentionPolicyIntervalSeconds: 1800
    resources:
      requests:
        memory: "XXX"
        cpu: "YYY"
      limits:
        memory: "XXX"
        cpu: "YYY"
 ```
 :::note
 If more than one `ObjectStore` applies, the `instanceSidecarConfiguration` of
 the one set in `.spec.plugins` has priority.
 :::
--- a/web/versioned_sidebars/version-0.14.0-sidebars.json
+++ b/web/versioned_sidebars/version-0.14.0-sidebars.json
@ -0,0 +1,8 @@
 {
  "docs": [
    {
      "type": "autogenerated",
      "dirName": "."
    }
  ]
 }
--- a/web/versions.json
+++ b/web/versions.json
@ -1,4 +1,5 @@
 [
  "0.14.0",
  "0.13.0",
  "0.12.0",
  "0.11.0",
--- a/web/yarn.lock
+++ b/web/yarn.lock
@ -2017,24 +2017,24 @@
    tslib "^2.4.0"
 "@emnapi/core@^1.4.3":
-  version "1.11.2"
+  version "1.11.3"
-  resolved "https://registry.yarnpkg.com/@emnapi/core/-/core-1.11.2.tgz#fab0a0f3c492d11f5a9ac9065d0d73955ee1c1c9"
+  resolved "https://registry.yarnpkg.com/@emnapi/core/-/core-1.11.3.tgz#5e95348a42cd1e06f0b9aa380cd74091daa4d520"
-  integrity sha512-TC8MkTuZUtcTSiFeuC0ksCh9QIJ5+F21MvZ4Wn4ORfYaFJ/0dsiudv5tVkejgwZlwQ39jL9WWDe2lz8x0WglOA==
+  integrity sha512-zLpS5asjEb7lq8jYLq37N6XKaE41DIexlY1rF/z4/tIl3wo13Sqm28fRyfIsKZD+NZ8mM5RoKkpW/rBcuoSZSg==
  dependencies:
-    "@emnapi/wasi-threads" "1.2.2"
+    "@emnapi/wasi-threads" "1.2.3"
    tslib "^2.4.0"
 "@emnapi/runtime@^1.4.3":
-  version "1.11.2"
+  version "1.11.3"
-  resolved "https://registry.yarnpkg.com/@emnapi/runtime/-/runtime-1.11.2.tgz#eb22f04d76febfdf4f87fdaff54c8a53f6bf0dbd"
+  resolved "https://registry.yarnpkg.com/@emnapi/runtime/-/runtime-1.11.3.tgz#84257ae3b0531eb2aec1ffa23d70700da007ba95"
-  integrity sha512-kyOl3X0DuTiT1h2ft8r2fYO8JYtU9a9Xis/zBSiGArNaagCOWx90N1k2wxp18czFDH+OgcWGb5ZP/XMt3dcyPA==
+  integrity sha512-Xz4Tpyki7XyrpbUK1jR1AhdAdaXyhhY4lZ3neLodmhpuWfy2PAQN5B46sAiU4liOXGLkHypn/qU+jvfWSCYYLA==
  dependencies:
    tslib "^2.4.0"
-"@emnapi/wasi-threads@1.2.2":
+"@emnapi/wasi-threads@1.2.3":
-  version "1.2.2"
+  version "1.2.3"
-  resolved "https://registry.yarnpkg.com/@emnapi/wasi-threads/-/wasi-threads-1.2.2.tgz#4c93becf5bfa3b13d1bbdcc06aee38321ad8139a"
+  resolved "https://registry.yarnpkg.com/@emnapi/wasi-threads/-/wasi-threads-1.2.3.tgz#c9bf72fd4be5b928aee894820e8d814ed73916e9"
-  integrity sha512-c95qOXkHdydNKhscBTebqEC1CVAZpyqOfVfBzQ1qgzyl3gfeldUjIggDbIZgDKsHLgnsM+igH7TJ/eAasaVuMA==
+  integrity sha512-ELEBe8PsLvvJ6QMr0zLt8ffvOHW/dc1m3CEzNMg7aJUv3bMaoDtw2TXyDAwkYBuroxxuHEwhRTLJSe5sya547g==
  dependencies:
    tslib "^2.4.0"
@ -3318,11 +3318,6 @@ accepts@~1.3.8:
    mime-types "~2.1.34"
    negotiator "0.6.3"
 acorn-import-phases@^1.0.3:
  version "1.0.4"
  resolved "https://registry.yarnpkg.com/acorn-import-phases/-/acorn-import-phases-1.0.4.tgz#16eb850ba99a056cb7cbfe872ffb8972e18c8bd7"
  integrity sha512-wKmbr/DDiIXzEOiWrTTUcDm24kQ2vGfZQvM2fwg2vXqR5uW6aapr7ObPtj1th32b9u90/Pf4AItvdTh42fBmVQ==
 acorn-jsx@^5.0.0:
  version "5.3.2"
  resolved "https://registry.yarnpkg.com/acorn-jsx/-/acorn-jsx-5.3.2.tgz#7ed5bb55908b3b2f1bc55c6af1653bada7f07937"
@ -3568,10 +3563,10 @@ balanced-match@^1.0.0:
  resolved "https://registry.yarnpkg.com/balanced-match/-/balanced-match-1.0.2.tgz#e83e3a7e3f300b34cb9d87f615fa0cbf357690ee"
  integrity sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==
-baseline-browser-mapping@^2.10.42:
+baseline-browser-mapping@^2.10.44:
-  version "2.10.43"
+  version "2.11.4"
-  resolved "https://registry.yarnpkg.com/baseline-browser-mapping/-/baseline-browser-mapping-2.10.43.tgz#7b5d11590ce5acdbe4859443e3c940e81ce8c02d"
+  resolved "https://registry.yarnpkg.com/baseline-browser-mapping/-/baseline-browser-mapping-2.11.4.tgz#3da1a877a8be2ec06495123ce994b43af58cc55e"
-  integrity sha512-AjYpR78kDWAY3Efj+cDTFH9t9SCoL7OoTp1BOb0mQV7S+6CiLwnWM3FyxhJtdPufDFKzmCSFoUncKjWgJEZTCQ==
+  integrity sha512-s4+sLr9mZ/CyqeRritFeYV/Zx73OAtmaHn6kkBS1XRoJn1hrg3xIDUcpicAEX68tkcIN0iBCgti31C8zxtkhsQ==
 batch@0.6.1:
  version "0.6.1"
@ -3663,13 +3658,13 @@ braces@^3.0.3, braces@~3.0.2:
    fill-range "^7.1.1"
 browserslist@^4.0.0, browserslist@^4.23.0, browserslist@^4.24.0, browserslist@^4.28.1, browserslist@^4.28.6:
-  version "4.28.6"
+  version "4.28.7"
-  resolved "https://registry.yarnpkg.com/browserslist/-/browserslist-4.28.6.tgz#7cf83afcd69c55fde6fb2dcc5039ff0f4ba42610"
+  resolved "https://registry.yarnpkg.com/browserslist/-/browserslist-4.28.7.tgz#409046517fccd2e51cdc20f077454b7141184028"
-  integrity sha512-FQBYNK15VMslhLHpA7+n+n1GOlF1kId2xcCg7/j95f24AOF6VDYMNH4mFxF7KuaTdv627faazpOAjFzMrfJOUw==
+  integrity sha512-JxV13hNrFxqjOc8alRbq9dK1MM79NEXYpma2B2J4wAtpWS5zIEIKqWPGCl7N4o7Uc7B7itylh7SuDujATRyyTw==
  dependencies:
-    baseline-browser-mapping "^2.10.42"
+    baseline-browser-mapping "^2.10.44"
-    caniuse-lite "^1.0.30001803"
+    caniuse-lite "^1.0.30001806"
-    electron-to-chromium "^1.5.389"
+    electron-to-chromium "^1.5.393"
    node-releases "^2.0.51"
    update-browserslist-db "^1.2.3"
@ -3777,7 +3772,7 @@ caniuse-api@^3.0.0:
    lodash.memoize "^4.1.2"
    lodash.uniq "^4.5.0"
-caniuse-lite@^1.0.0, caniuse-lite@^1.0.30001803, caniuse-lite@^1.0.30001806:
+caniuse-lite@^1.0.0, caniuse-lite@^1.0.30001806:
  version "1.0.30001806"
  resolved "https://registry.yarnpkg.com/caniuse-lite/-/caniuse-lite-1.0.30001806.tgz#1bc8e502b723fa393455dfbedd5ccec0c29bb74e"
  integrity sha512-72Cuvd95zbSYPKq6Fhg8eDJRlzgWDf7/mtoZv6Qe/DYNCEBdNxoA3+rZAU2ZhGCpZlns3EssFavaZomckT5Uuw==
@ -4572,10 +4567,10 @@ ee-first@1.1.1:
  resolved "https://registry.yarnpkg.com/ee-first/-/ee-first-1.1.1.tgz#590c61156b0ae2f4f0255732a158b266bc56b21d"
  integrity sha512-WMwm9LhRUo+WUaRN+vRuETqG89IgZphVSNkdFgeb6sS/E4OrDIN7t48CAewSHXc6C8lefD8KKfr5vY61brQlow==
-electron-to-chromium@^1.5.389:
+electron-to-chromium@^1.5.393:
-  version "1.5.393"
+  version "1.5.396"
-  resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.5.393.tgz#aec971df2a6f4f7e51fbacb200d66cebfc7d3c17"
+  resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.5.396.tgz#4aa96428486c8d1c9c8aeb205b2d6e04928ca046"
-  integrity sha512-kiDJdIUawuEIcp9XoICKp1iTYDEbgguIPq526N1Q7jIQDeQ3CqoMx71025PI/7E48Ddtw2HuWsVjY7afEgNxmg==
+  integrity sha512-yHiw2Y3C3H9U6TMbOfoWK/BPreiOPXRfTWPBwQBoZG6/8TB6eOPnsy5oaRYuatR7Fw2SJ4kKforgufeo7fq0EQ==
 emoji-regex@^8.0.0:
  version "8.0.0"
@ -4615,10 +4610,10 @@ encoding-sniffer@^0.2.1:
    iconv-lite "^0.6.3"
    whatwg-encoding "^3.1.1"
-enhanced-resolve@^5.22.2:
+enhanced-resolve@^5.24.2:
-  version "5.24.2"
+  version "5.24.3"
-  resolved "https://registry.yarnpkg.com/enhanced-resolve/-/enhanced-resolve-5.24.2.tgz#f25d703a24431cb1e02f944adb74aefa4fcb8d7e"
+  resolved "https://registry.yarnpkg.com/enhanced-resolve/-/enhanced-resolve-5.24.3.tgz#406bbf1ec20971265a30254f08030fce6a8207fe"
-  integrity sha512-rpsZEGT1jFuve6QlpyRp9ckQ+kN61hvF9BzCPyMdaKTm8UJce96KBn3sorXOFXlzjPrs3Vc4T1NsSroZ3PxlFw==
+  integrity sha512-PwKooW9JUzh5chmYfHM3IQl5OkK2u2Nm011MgeZrss3JmFraUx/fqrf78kk8GUMYoibx/14MdwTl/1WKkG7TpQ==
  dependencies:
    graceful-fs "^4.2.4"
    tapable "^2.3.3"
@ -5043,9 +5038,9 @@ fs-extra@^10.0.0:
    universalify "^2.0.0"
 fs-extra@^11.1.1, fs-extra@^11.2.0:
-  version "11.3.6"
+  version "11.4.0"
-  resolved "https://registry.yarnpkg.com/fs-extra/-/fs-extra-11.3.6.tgz#f7cb80e9df550cd1db6f537fa5cdd568d3e70d10"
+  resolved "https://registry.yarnpkg.com/fs-extra/-/fs-extra-11.4.0.tgz#f88ed6d180ac9e14b61b08e679468f0b1b6b4730"
-  integrity sha512-w8ZNZr2mKIc7qeNaQ9AVPT1+iFaI+Avd4xudVOvdDJ8VytREi1Ft5Ih7hd9jjehod8vAM5GMsfQ/TpPf4EyoEA==
+  integrity sha512-EQsFzMUJkCKGr1ePqlYADkIUmHW1s3ZXr5Yqy6wbGrfUCphpl2maM/kyOIRA2HpP3AaFQTZXD4ldjek+nccddA==
  dependencies:
    graceful-fs "^4.2.0"
    jsonfile "^6.0.1"
@ -5417,9 +5412,9 @@ html-void-elements@^3.0.0:
  integrity sha512-bEqo66MRXsUGxWHV5IP0PUiAWwoEjba4VCzg0LjFJBpchPaTfyfCKTG6bc5F8ucKec3q5y6qOdGyYTSBEvhCrg==
 html-webpack-plugin@^5.6.0:
-  version "5.6.7"
+  version "5.6.8"
-  resolved "https://registry.yarnpkg.com/html-webpack-plugin/-/html-webpack-plugin-5.6.7.tgz#429bab4e12abf3c07e1c608886608e2df2c06b11"
+  resolved "https://registry.yarnpkg.com/html-webpack-plugin/-/html-webpack-plugin-5.6.8.tgz#5425dbc63eb533ffa59e92342be94894a125fc23"
-  integrity sha512-md+vXtdCAe60s1k6AU3dUyMJnDxUyQAwfwPKoLisvgUF1IXjtlLsk2se54+qfL9Mdm26bbwvjJybpNx48NKRLw==
+  integrity sha512-MZmKQcTnhEh1SPSyMiEytIeDZDUoBZVorNHivQGXMASHf/BSGGOrKa2xQ5bGx3TCe1n109ecCt+cpww7wwWhKA==
  dependencies:
    "@types/html-minifier-terser" "^6.0.0"
    html-minifier-terser "^6.0.2"
@ -5980,11 +5975,6 @@ lines-and-columns@^1.1.6:
  resolved "https://registry.yarnpkg.com/lines-and-columns/-/lines-and-columns-1.2.4.tgz#eca284f75d2965079309dc0ad9255abb2ebc1632"
  integrity sha512-7ylylesZQ/PV29jhEDl3Ufjo6ZX7gCqJr5F7PKrqc93v7fzSymt1BpwEU8nAUXs8qzzvqhbjhK5QZg6Mt/HkBg==
 loader-runner@^4.3.2:
  version "4.3.2"
  resolved "https://registry.yarnpkg.com/loader-runner/-/loader-runner-4.3.2.tgz#9913d3a15971f8f635915e601fb5c9d495d918e9"
  integrity sha512-DFEqQ3ihfS9blba08cLfYf1NRAIEm+dDjic073DRDc3/JspI/8wYmtDsHwd3+4hwvdxSK7PGaElfTmm0awWJ4w==
 loader-utils@^2.0.0:
  version "2.0.4"
  resolved "https://registry.yarnpkg.com/loader-utils/-/loader-utils-2.0.4.tgz#8b5cb38b5c34a9a018ee1fc0e6a066d1dfcc528c"
@ -7818,9 +7808,9 @@ postcss-zindex@^6.0.2:
  integrity sha512-5BxW9l1evPB/4ZIc+2GobEBoKC+h8gPGCMi+jxsYvd2x0mjq7wazk6DrP71pStqxE9Foxh5TVnonbWpFZzXaYg==
 postcss@^8.4.21, postcss@^8.4.24, postcss@^8.4.33, postcss@^8.5.4:
-  version "8.5.20"
+  version "8.5.23"
-  resolved "https://registry.yarnpkg.com/postcss/-/postcss-8.5.20.tgz#316a139da79484ce55969fa7bb6f2f1abcc14060"
+  resolved "https://registry.yarnpkg.com/postcss/-/postcss-8.5.23.tgz#3493550116f478487298301d2c2e8dc5a56e6594"
-  integrity sha512-lW616l85ucIQL+FocMmL7pQFPqBmwejrCMg+iPxyImlrANNJG9NHq/RkyCZopDhd8C3LA03PHRJDjkbGu8vvug==
+  integrity sha512-g50586zr4bZmwFiTlflMu8E0bDTb5I5gertgwAKmsdUlTQIhZtunzUlD1WSzwcVWPoAVpsrA6vlfCD7oXvRwgg==
  dependencies:
    nanoid "^3.3.16"
    picocolors "^1.1.1"
@ -7970,9 +7960,9 @@ rc@1.2.8:
    strip-json-comments "~2.0.1"
 react-dom@^19.0.0:
-  version "19.2.7"
+  version "19.2.8"
-  resolved "https://registry.yarnpkg.com/react-dom/-/react-dom-19.2.7.tgz#0450dc9ae9ddbff76ef196401cd8b8c7fb466ccc"
+  resolved "https://registry.yarnpkg.com/react-dom/-/react-dom-19.2.8.tgz#3b46b9eeda877cdff2cf13d2770fff4ae36c2ec2"
-  integrity sha512-t0BRVXvbiE/o20Hfw669rLbMCDWtYZLvmJigy2f0MxsXF+71pxhR3xOkspmsO8h3ZlNzyibAmtCa3l4lYKk6gQ==
+  integrity sha512-rVprimfGBG3DR+Tq0IQG2DT5PxKth1WIGDmj5yPmlzr4YBe7uyE+Du4oVqTDXZSHGGGXRtTJEGSSePyQCMBglQ==
  dependencies:
    scheduler "^0.27.0"
@ -8052,9 +8042,9 @@ react-router@5.3.4, react-router@^5.3.4:
    tiny-warning "^1.0.0"
 react@^19.0.0:
-  version "19.2.7"
+  version "19.2.8"
-  resolved "https://registry.yarnpkg.com/react/-/react-19.2.7.tgz#1f47a1bfc06f8ec885752c6f4af14369a9f8260b"
+  resolved "https://registry.yarnpkg.com/react/-/react-19.2.8.tgz#a80663dbb58d69c6fe3fd291d3cb324e8a7dff2d"
-  integrity sha512-HNe9WslTbXmFK8o8cmwgAeJFSBvt1bPdHCVKtaaV+WlAN36mpT4hcRpwbf3fY56ar2oIXzsBpOAiIRHAdY0OlQ==
+  integrity sha512-PWaYA1L/q9u2u7xYQi+Y3L3Yfnie7XyLeaJICV1MGD6LprsBxcAqGjYyr0eY3p+QdsA+x/Irkt4Qif8D63+Sbw==
 readable-stream@^2.0.1:
  version "2.3.8"
@ -8390,9 +8380,9 @@ safe-buffer@~5.1.0, safe-buffer@~5.1.1:
  integrity sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==
 sax@^1.2.4, sax@^1.5.0:
-  version "1.6.0"
+  version "1.6.1"
-  resolved "https://registry.yarnpkg.com/sax/-/sax-1.6.0.tgz#da59637629307b97e7c4cb28e080a7bc38560d5b"
+  resolved "https://registry.yarnpkg.com/sax/-/sax-1.6.1.tgz#4c23cf608c0b693ab54b4b5888e92cfe977b9843"
-  integrity sha512-6R3J5M4AcbtLUdZmRv2SygeVaM7IhrLXu9BmnOGmmACak8fiUtOsYNWUS4uK7upbmHIBbLBeFeI//477BKLBzA==
+  integrity sha512-42tBVwLWnaQvW5zc4HbZrTuWccECCZfBi92FDuwtqxasH+JbPB3/FOKb1m222K42R4WxuxzzMsTswfzgtSu64Q==
 scheduler@^0.27.0:
  version "0.27.0"
@ -8914,9 +8904,9 @@ terser@^5.10.0, terser@^5.15.1, terser@^5.31.1:
    source-map-support "~0.5.20"
 thingies@^2.5.0:
-  version "2.6.0"
+  version "2.6.1"
-  resolved "https://registry.yarnpkg.com/thingies/-/thingies-2.6.0.tgz#e09b98b9e6f6caf8a759eca8481fea1de974d2b1"
+  resolved "https://registry.yarnpkg.com/thingies/-/thingies-2.6.1.tgz#4eb28e2585a75288f1765a0b08f1dfa020357a6f"
-  integrity sha512-rMHRjmlFLM1R96UYPvpmnc3LYtdFrT33JIB7L9hetGue1qAPfn1N2LJeEjxUSidu1Iku+haLZXDuEXUHNGO/lg==
+  integrity sha512-cV/CMGTK3M4MlnJ/0At6ismOw/A0EEniDNScajjz/Br3c1sqE72YD01rGpPTKwd27wAxI5Pr+6+0w8yofzFRYw==
 thunky@^1.0.2:
  version "1.1.0"
@ -9044,9 +9034,9 @@ undici-types@~8.3.0:
  integrity sha512-j375ScV60dom+YkPFIfTLcOiPxkN/buHz5GobjLhixFuANaNs3C9l4GmrWqejgXWJ7BbJcFYpTEUkS1Ge8bpZQ==
 undici@^7.19.0:
-  version "7.28.0"
+  version "7.29.0"
-  resolved "https://registry.yarnpkg.com/undici/-/undici-7.28.0.tgz#97d64564198b285bc281f0e8e29597e3d11fe7ec"
+  resolved "https://registry.yarnpkg.com/undici/-/undici-7.29.0.tgz#ae0f6f62e06e057a9cbb7b2b5fde2bb74f791b8f"
-  integrity sha512-cRZYrTDwWznlnRiPjggAGxZXanty6M8RV1ff8Wm4LWXBp7/IG8v5DnOm74DtUBp9OONpK75YlPnIjQqX0dBDtA==
+  integrity sha512-IDxfleLmmbSskfWSUATiN1nfn2rDuvnMOqb5CWR92iIfojA0Ud+ulOAAEQ57LPr9rWmsreUyf5lwyao+7GNNVw==
 unicode-canonical-property-names-ecmascript@^2.0.0:
  version "2.0.1"
@ -9355,15 +9345,15 @@ webpack-merge@^6.0.1:
    flat "^5.0.2"
    wildcard "^2.0.1"
-webpack-sources@^3.5.0:
+webpack-sources@^3.5.1:
  version "3.5.1"
  resolved "https://registry.yarnpkg.com/webpack-sources/-/webpack-sources-3.5.1.tgz#76c2418486dcc02b2aa0694c104176c2858fe84a"
  integrity sha512-jyuiGJdtvY434z5bUZrjz67v76/ePNvFZTp9Mdz29IlH4+GPsgyGjiv0fKI+M7BdkU6ADjulUcKAd3tUK3WlEw==
 webpack@^5.88.1, webpack@^5.95.0:
-  version "5.108.4"
+  version "5.109.0"
-  resolved "https://registry.yarnpkg.com/webpack/-/webpack-5.108.4.tgz#141818a411662773a0bb32dc5536acc5409943b7"
+  resolved "https://registry.yarnpkg.com/webpack/-/webpack-5.109.0.tgz#871d8eee5e2d5e6eaf5ec8d1a6db74ea65491030"
-  integrity sha512-yur8LyJoeiWh47dErD+Ok7vlbmDsJ3UbbRPAoxbGJ54WpE2y5yVo5G/inUzujnYgw3tPmBRdn+G7PoxXaYC33w==
+  integrity sha512-vomrngskVVXEZF9sMZfYAd4pXZUnfaWdJGlF+BTNF+gJBCKYCQBnOeVPlrh39Ewl7nlCsirDplMy6o5g9xJHBg==
  dependencies:
    "@types/estree" "^1.0.8"
    "@types/json-schema" "^7.0.15"
@ -9371,22 +9361,20 @@ webpack@^5.88.1, webpack@^5.95.0:
    "@webassemblyjs/wasm-edit" "^1.14.1"
    "@webassemblyjs/wasm-parser" "^1.14.1"
    acorn "^8.16.0"
    acorn-import-phases "^1.0.3"
    browserslist "^4.28.1"
    chrome-trace-event "^1.0.2"
-    enhanced-resolve "^5.22.2"
+    enhanced-resolve "^5.24.2"
    es-module-lexer "^2.1.0"
    eslint-scope "5.1.1"
    events "^3.2.0"
    graceful-fs "^4.2.11"
    loader-runner "^4.3.2"
    mime-db "^1.54.0"
    minimizer-webpack-plugin "^5.6.1"
    neo-async "^2.6.2"
    schema-utils "^4.3.3"
    tapable "^2.3.0"
    watchpack "^2.5.2"
-    webpack-sources "^3.5.0"
+    webpack-sources "^3.5.1"
 webpackbar@^7.0.0:
  version "7.0.0"
Author	SHA1	Message	Date
Max Eisner	dfa6987016	Merge `78d02d6803` into `1e13020fe5`	2026-07-31 21:07:30 +02:00
Peggie	1e13020fe5	chore(main): release 0.14.0 (#964 ) Signed-off-by: Peggie <info@cloudnative-pg.io>	2026-07-29 12:00:23 +02:00
Marco Nenciarini	bfa7fe024c	docs(release): documentation for release 0.14.0 (#1037 ) Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>	2026-07-29 11:26:55 +02:00
renovate[bot]	f38a3e3a08	chore(deps): update amazon/aws-cli docker tag to v2.36.9 (#1035 ) Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>	2026-07-28 19:27:14 +02:00
renovate[bot]	5ff12acda0	chore(deps): update mcr.microsoft.com/azure-storage/azurite:3.36.0 docker digest to 76b8127 (#1036 ) Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>	2026-07-28 19:17:29 +02:00
renovate[bot]	76d4f22aa3	chore(deps): lock file maintenance (#1033 ) Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>	2026-07-27 14:53:28 +02:00
renovate[bot]	ce8a3db8c5	chore(deps): refresh pip-compile outputs (#1034 ) Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>	2026-07-27 13:23:29 +02:00
renovate[bot]	fcb0d1eaf4	chore(deps): update amazon/aws-cli docker tag to v2.36.8 (#1032 ) Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>	2026-07-27 11:13:04 +02:00
renovate[bot]	6d0aeec367	chore(deps): update amazon/aws-cli docker tag to v2.36.7 (#1029 ) Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>	2026-07-24 11:16:13 +02:00
renovate[bot]	ce8179442b	fix(deps): update kubernetes monorepo to v0.36.3 (#1031 ) Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>	2026-07-23 15:38:26 +02:00
renovate[bot]	65b028003e	chore(deps): update documentation dependencies to v19.2.8 (#1030 ) Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>	2026-07-23 12:23:12 +02:00