enk21 · Oct 29, 2026 · Oct 29, 2026 · Oct 29, 2026 · Oct 29, 2026 · Oct 29, 2026
diff --git a/template-catalog/templates/cdc-pipeline.mdx b/template-catalog/templates/cdc-pipeline.mdx
@@ -194,7 +194,7 @@ postgres-highly-available:
     maxCpu: 1
     maxMemory: 2Gi
 
-  image: controlplanecorporation/patroni-postgres:0.7
+  image: controlplanecorporation/patroni-postgres:0.8 # pgvector 0.8.7 (CVE-2026-103484); tags 0.1-0.7 are refused
 
   walLevel: logical # Debezium's pgoutput decoding needs it; the chart refuses anything else
 
@@ -549,6 +549,10 @@ This upgrade path has not been verified end to end. Snapshot the database volume
 
 The bundled components move too: PostgreSQL Highly Available 2.5.0 → 2.8.0, Kafka 4.0.1 → 4.3.0 (the brokers roll, which also applies the new super user), and Kafbat UI keeps the setting your release runs with.
 
+### Upgrading from 1.1.1 or earlier
+
+1.1.2 moves the database to `controlplanecorporation/patroni-postgres:0.8`, which carries pgvector 0.8.7 (CVE-2026-103484). The database members restart and nothing limits that rollout, so expect a brief interruption of writes while the leader changes. The upgrade does not redeploy Debezium; it restarts once when the database leader changes and resumes from its failover replication slot, so changes around the leader change may be delivered twice. Upgrade in a quiet window. Existing data needs nothing. If you pinned `postgres-highly-available.image`, set it to the `0.8` tag: tags `0.1` to `0.7` are refused at render. The pipeline does not use the `vector` extension; if you created it in your database, run `ALTER EXTENSION vector UPDATE;` there, which only updates the version `\dx` reports.
+
 ### Rotating the Database Password in HA Mode
 
 The HA database needs its own order. The replication role `repl` shares the password, and a member that restarts with the old password can be promoted to leader, which splits the cluster. Move the leader to member `-0` first, so it restarts last, after every other member already has the new password. `pgx` runs a command in one member (`LOCATION` is your GVC's location, `DB_USERNAME` the secret's `username`):

diff --git a/template-catalog/templates/chatwoot.mdx b/template-catalog/templates/chatwoot.mdx
@@ -1,7 +1,7 @@
 ---
 title: Chatwoot
 icon: /template-catalog/templates/icons/chatwoot.png
-description: Deploy Chatwoot, the open-source live chat, shared inbox and omnichannel agent desk (Community Edition) with a background worker, a single-node Redis and a PostgreSQL that is highly available by default or single-instance. Needs an existing GVC and three dictionary secrets: keys, database and Redis.
+description: "Deploy Chatwoot, the open-source live chat, shared inbox and omnichannel agent desk (Community Edition) with a background worker, a single-node Redis and a PostgreSQL that is highly available by default or single-instance. Needs an existing GVC and three dictionary secrets: keys, database and Redis."
 keywords: ['chat widget', 'help desk', 'customer support', 'intercom alternative', 'zendesk alternative', 'freshdesk alternative', 'crisp alternative', 'sidekiq', 'actioncable', 'websockets', 'pgvector', 'rails', 'chatwoot template']
 ---
 
@@ -336,6 +336,7 @@ Enable exactly one of `postgresHA` (default) and `postgres` — the chart refuse
 # an HAProxy leader endpoint. Its image ships pgvector, which Chatwoot's schema REQUIRES.
 postgresHA:
   enabled: true
+  image: controlplanecorporation/patroni-postgres:0.8 # pgvector 0.8.7; tags 0.1-0.7 are refused (CVE-2026-103484)
   config:
     credentialsSecretName: my-chatwoot-db-credentials   # PREREQUISITE dictionary secret (username, password, database) — must exist BEFORE install
   replicas: 3
@@ -711,6 +712,12 @@ The current values are also in `postgres.credentials` and `redis.auth.password`
 
 The upgrade restarts the bundled PostgreSQL too (it now reads the new secret), so Chatwoot can briefly lose its database; it reconnects by itself. The new version of a workload can also wait several minutes with `is not allowed to reveal the secret` in `get-deployments` while access to the new secret propagates; the previous version keeps serving meanwhile, and it clears by itself.
 
+### Upgrading From 1.3.0 or Earlier
+
+1.3.1 moves the HA database (`postgresHA`) to `controlplanecorporation/patroni-postgres:0.8`, which carries pgvector 0.8.7 (CVE-2026-103484). The fix takes effect when the upgrade restarts the Patroni members; existing data needs nothing. Nothing limits that rollout, so expect a brief interruption of writes while the leader changes. Chatwoot itself restarts as on any upgrade; with a single Chatwoot web replica (the default) that is the longer interruption, because the old replica stops before the new one serves. Upgrade in a quiet window. If you pinned `postgresHA.image` in your values, set it to the `0.8` tag: tags `0.1` to `0.7` are refused at render.
+
+Chatwoot's schema creates the `vector` extension, so in the Chatwoot database `\dx` keeps reporting the old version until you run `ALTER EXTENSION vector UPDATE;` as the database user, through the proxy endpoint `RELEASE_NAME-postgres-ha-proxy.GVC_NAME.cpln.local:5432`; it only updates that record. Single-instance mode (`postgres`) is unchanged.
+
 ### Scaling and Availability
 
 - **Web tier** — `chatwoot.replicas` sets how many web replicas run. Replicas share the database and the bundled Redis, so a message received by one replica reaches a WebSocket client connected to another, and no sticky sessions are needed. Anything above `1` requires `storage.type` `s3` or `s3-compatible`; the chart refuses to render the combination with local storage.

diff --git a/template-catalog/templates/gitea.mdx b/template-catalog/templates/gitea.mdx
@@ -1,7 +1,7 @@
 ---
 title: Gitea
 icon: /template-catalog/templates/icons/gitea.png
-description: Single-replica Gitea Git server with web UI, Git-over-HTTPS, package registry and optional Git-over-SSH, backed by a bundled PostgreSQL. Deploys into an existing GVC and needs two dictionary secrets created before install: auth (admin login plus signing keys) and database credentials.
+description: "Single-replica Gitea Git server with web UI, Git-over-HTTPS, package registry and optional Git-over-SSH, backed by a bundled PostgreSQL. Deploys into an existing GVC and needs two dictionary secrets created before install: auth (admin login plus signing keys) and database credentials."
 keywords: ['self-hosted git', 'git server', 'github alternative', 'gitlab alternative', 'gogs', 'source code management', 'pull requests', 'git clone', 'git lfs', 'container registry', 'jwt secret', 'secret key', 'rootless', 'developer tools']
 ---
 

diff --git a/template-catalog/templates/glitchtip.mdx b/template-catalog/templates/glitchtip.mdx
@@ -254,6 +254,7 @@ Enable exactly one database — the chart refuses to render with both or neither
     ```yaml
     postgresHA:
       enabled: true
+      image: controlplanecorporation/patroni-postgres:0.8 # pgvector 0.8.7 (CVE-2026-103484); tags 0.1-0.7 are refused
       config:
         credentialsSecretName: my-glitchtip-db-credentials # PREREQUISITE dictionary secret (username, password, database) — must exist BEFORE install
       replicas: 3
@@ -621,6 +622,10 @@ The upgrade restarts the bundled PostgreSQL and Redis too (they now read the new
 The first Helm upgrade after an install can restart the bundled database and Redis even when their values are unchanged, so expect a brief interruption.
 </Note>
 
+### Upgrading from 1.4.0 or earlier
+
+1.4.1 moves the HA database (`postgresHA`) to `controlplanecorporation/patroni-postgres:0.8`, which carries pgvector 0.8.7 (CVE-2026-103484). The fix takes effect when the upgrade restarts the Patroni members; existing data needs nothing. Nothing limits that rollout, so expect a brief interruption of writes while the leader changes. GlitchTip itself restarts without a gap: the new replica serves before the old one stops. Upgrade in a quiet window. If you pinned `postgresHA.image` in your values, set it to the `0.8` tag: tags `0.1` to `0.7` are refused at render. GlitchTip does not use the `vector` extension; if you created it yourself in a database, `\dx` keeps reporting the old version until you run `ALTER EXTENSION vector UPDATE;` there, which only updates that record. Single-instance mode (`postgres`) is unchanged.
+
 ### Scaling and Availability
 
 `replicas` is the scaling knob. The web tier is stateless — sessions, cache, and queue live in Redis, everything durable in PostgreSQL — so `2` or more web replicas behind the single endpoint gives high availability for the UI and for event ingest with no sticky sessions.

diff --git a/template-catalog/templates/grafana.mdx b/template-catalog/templates/grafana.mdx
@@ -354,6 +354,7 @@ Exactly one of the two database modes must be enabled — the chart enforces thi
 ```yaml
 postgresHA: # default: highly available PostgreSQL app database
   enabled: true
+  image: controlplanecorporation/patroni-postgres:0.8 # pgvector 0.8.7 (CVE-2026-103484); tags 0.1-0.7 are refused
   config:
     credentialsSecretName: my-grafana-db-credentials # PREREQUISITE dictionary secret (username, password, database), must exist BEFORE install
   replicas: 3
@@ -735,6 +736,10 @@ Then upgrade with `postgres.credentials` removed and the `credentialsSecretName`
 
 The upgrade restarts the bundled PostgreSQL too (it now reads the new secret), so Grafana can briefly lose its database; it reconnects by itself. The new version of a workload can also wait several minutes with `is not allowed to reveal the secret` in `get-deployments` while access to the new secret propagates; the previous version keeps serving meanwhile, and it clears by itself.
 
+### Upgrading from 1.5.0 or Earlier
+
+1.5.1 moves the HA database (`postgresHA`) to `controlplanecorporation/patroni-postgres:0.8`, which carries pgvector 0.8.7 (CVE-2026-103484). The fix takes effect when the upgrade restarts the Patroni members; existing data needs nothing. Nothing limits that rollout, so expect a brief interruption of writes while the leader changes. Grafana itself restarts without a gap (the new replica serves before the old one stops); while the leader changes, Grafana can briefly answer valid users with 401. Upgrade in a quiet window. If you pinned `postgresHA.image` in your values, set it to the `0.8` tag: tags `0.1` to `0.7` are refused at render. Grafana does not use the `vector` extension; if you created it yourself in a database, `\dx` keeps reporting the old version until you run `ALTER EXTENSION vector UPDATE;` there, which only updates that record. Single-instance mode (`postgres`) is unchanged.
+
 ### Scaling and Availability
 
 - **`replicas`** scales the Grafana tier; `2` or more requires `redis.enabled: true` — see [Alerting High Availability](#alerting-high-availability). Database replicas are set separately with `postgresHA.replicas`; the single-instance database must stay at one replica.

diff --git a/template-catalog/templates/keycloak.mdx b/template-catalog/templates/keycloak.mdx
@@ -145,7 +145,7 @@ To install using another method, follow the instructions for your preferred tool
 ### Keycloak
 
 ```yaml
-image: quay.io/keycloak/keycloak:26.6.3
+image: quay.io/keycloak/keycloak:26.8.1
 
 # Replica count. 2+ (default) forms an Infinispan cluster over JGroups JDBC_PING
 # for zero-downtime restarts. 1 = dev mode: clustering fully disabled (local cache).
@@ -192,6 +192,7 @@ postgresHA:
   config:
     credentialsSecretName: my-keycloak-db-credentials # PREREQUISITE dictionary secret (username, password, database) — must exist BEFORE install
   replicas: 3
+  image: controlplanecorporation/patroni-postgres:0.8 # pgvector 0.8.7 (CVE-2026-103484); tags 0.1-0.7 are refused
   volumeset:
     capacity: 10 # initial capacity in GiB per replica (minimum is 10)
 
@@ -480,6 +481,16 @@ Your current values are in `postgres.credentials` of the 1.4.0 release, and also
 
 The upgrade restarts the bundled PostgreSQL too (it now reads the new secret), so Keycloak can briefly lose its database; it reconnects by itself. The new version of a workload can also wait several minutes with `is not allowed to reveal the secret` in `get-deployments` while access to the new secret propagates; the previous version keeps serving meanwhile, and it clears by itself.
 
+### Upgrading From 1.5.0
+
+Version `1.5.1` moves Keycloak from 26.6.3 to 26.8.1, which fixes an unauthenticated account-takeover vulnerability in the reset-credentials flow (CVE-2026-18963). No values change: upgrade with the values you already use. If your values set `image` (installs made through the Console wizard store it), change it to `quay.io/keycloak/keycloak:26.8.1` or remove it; the chart refuses an official Keycloak image older than 26.7.2.
+
+The first 26.8.1 server to start migrates the database schema, and Keycloak cannot run an older version against a migrated database, so this upgrade cannot be rolled back to 1.5.0: a rolled-back release reports healthy, but every login page fails with HTTP 500. Take a database backup before upgrading (see [Backing Up](#backing-up)); to recover from a rollback, upgrade to 1.5.1 again or restore the backup.
+
+With 2 or more replicas Keycloak keeps serving throughout the upgrade, apart from the brief interruption of database writes in HA mode described below. With `replicas: 1`, Keycloak is unavailable while its single server restarts.
+
+In HA mode, `1.5.1` also moves the database to `controlplanecorporation/patroni-postgres:0.8`, which carries pgvector 0.8.7 (CVE-2026-103484). The database members restart, so expect a brief interruption of writes while the leader changes, even with 2 or more Keycloak replicas. Upgrade in a quiet window. Keycloak does not use the `vector` extension; if you created it yourself in a database, run `ALTER EXTENSION vector UPDATE;` there after the upgrade. If your values set `postgresHA.image`, set it to the `0.8` tag: tags `0.1` to `0.7` are refused at render.
+
 ### Scaling and Availability
 
 - **Keycloak replicas.** Change `replicas` and upgrade the release; there is deliberately no autoscaling, so cluster membership only changes when you change it. Clustered replicas (`2` or more) share realm, user and session state through the database, so one replica restarting does not interrupt sign-ins. With `replicas: 1` a restart is a short outage.