Update Helm release postgresql to v18.7.0

[renovate]

This PR contains the following updates:

Package	Update	Change
postgresql (source)	minor	18.6.9 → 18.7.0

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Configuration

📅 Schedule: (in timezone America/Los_Angeles)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[anshulg-dep-review]

Triage: YELLOW -- possible breakage, reviewer requested

Quick summary

Minor chart version bump (18.6.9 → 18.7.0) within the Bitnami PostgreSQL 18.x series. The underlying PostgreSQL engine version (appVersion: 18.4.0) is unchanged. Two documented behavior changes in 18.7.0 (TLS enforcement in backup/password-update jobs, and initdb.password credential injection) do not affect this deployment, which does not use those features. However, provenance research failed due to token limits and cannot be verified before merge — manual verification of the chart source is required.

Updates table

Package	Old	New	Breaking	Changelog	Provenance
postgresql	18.6.9	18.7.0	safe	minor version bump	failed

Required actions

1. postgresql — Provenance research failed (token limit exceeded). Before merge, manually verify that the chart version 18.7.0 on Artifact Hub corresponds to the expected Bitnami source repository and has not been tampered with. Check the chart digest and source URL at https://artifacthub.io/packages/helm/bitnami/postgresql/18.7.0.

Update summary

postgresql 18.6.9 → 18.7.0

• Minor chart version bump within the Bitnami BSI 18.x series; PostgreSQL engine version remains 18.4.0 (no migration required).
• Two documented behavior changes in 18.7.0:
  • TLS enforcement in backup CronJob and password-update Job (only active if tls.enabled=true; this deployment uses tls.enabled: false).
  • primary.initdb.password now injected via Secret secretKeyRef instead of plaintext env (only active if primary.initdb.password is set; this deployment does not set it).
• No action required for this deployment — both changes are gated on features not in use.
• New parameter tls.sslMode added (default verify-ca); does not affect current configuration.

Provenance

Provenance research failed. The provenance researcher could not complete due to token limits and cannot verify the chart's source, signature, or publisher identity. This is a required action before merge — manually confirm the chart source and integrity at the Bitnami Artifact Hub page.

Sub-agent reports — postgresql

Breaking-change impact

I now have all the information I need. Let me compile the complete analysis.

Summary of findings:

1. Official 18.7.0 upgrade notes (from Artifact Hub / README):

   • TLS change: When tls.enabled=true, backup CronJob and password-update Job now enforce TLS via PGSSLMODE. → Does NOT affect this deployment — tls.enabled is not set in k8s/kellnr/values.yaml (defaults to false).
   • initdb.password change: When primary.initdb.password is set, credential is now stored in chart Secret and injected via secretKeyRef instead of plaintext env value:. → Does NOT affect this deployment — primary.initdb.password is not set in k8s/kellnr/values.yaml.

2. App version: Both 18.6.9 and 18.7.0 use appVersion: 18.4.0 — no PostgreSQL engine version change.

3. Deployment fingerprint: GKE-only (nodeSelector cloud.google.com/gke-provisioning: standard), no ARM nodes involved. auth.existingSecret: database-secrets (SealedSecret with password and postgres-password keys). architecture: standalone. tls.enabled: false (default). No primary.initdb.password. No metrics enabled. No passwordUpdateJob. Kellnr connects via kellnr-postgresql:5432 with user kellnr, db kellnr, password from database-secrets secret key password.

4. Blast radius: Leaf app — kellnr (Rust crate registry) at crates.anshulg.com, single PostgreSQL StatefulSet in kellnr namespace. No transitive dependents.

---

Impact verdict: postgresql 18.6.9 → 18.7.0 (PR #3329)

Verdict

safe_to_merge

Both documented changes in 18.7.0 are gated on features (tls.enabled=true and primary.initdb.password) that this deployment does not use; the PostgreSQL engine version (appVersion: 18.4.0) is unchanged from 18.6.9; blast radius is a single leaf application.

Blast radius

• Scope: leaf_app
• Direct usage: 2 files — k8s/kellnr/Chart.yaml, k8s/kellnr/Chart.lock
• Transitive dependents: 1 app
  • kellnr — Rust crate registry (crates.anshulg.com); uses this PostgreSQL instance as its sole primary database via kellnr-postgresql:5432
• User-facing exposure:
  • Public hostnames affected: crates.anshulg.com (Traefik IngressRoute, TLS via cert-manager k8s-ca ClusterIssuer)
  • Internal (oauth-gated) hostnames affected: none
  • Cron / scheduled jobs affected: kellnr-backup CronJob (daily at 13:00 UTC) — uses a standalone postgres:17.10 image for pg_dump, not the Bitnami chart's built-in backup; unaffected by this chart bump
• Failure mode if upgrade goes wrong: hard_down — PostgreSQL StatefulSet pod fails to start; kellnr application loses its database connection and becomes unavailable
• Recovery: trivial_rollback — pin chart back to 18.6.9 in Chart.yaml / Chart.lock; no data written by the new chart version that the old version cannot read (same appVersion: 18.4.0, no schema migration)

Required actions before merge

None.

Findings

F-01: TLS enforcement change in backup CronJob and passwordUpdateJob

• Severity: informational
• Category: config_schema
• What changed: When tls.enabled=true, the chart-managed backup CronJob and password-update Job now set PGSSLMODE=verify-ca (configurable via tls.sslMode).
• Why it does NOT affect this deployment: k8s/kellnr/values.yaml does not set tls.enabled; the default is false. The chart-managed backup CronJob (backup.enabled) is also not enabled — the repo uses its own custom kellnr-backup CronJob (k8s/kellnr/templates/backup.yaml) with a standalone postgres:17.10 image. Neither code path is active.
• Affected dependents: none
• Required action: no action — informational
• Source: Artifact Hub documentation for version 18.7.0 — "Upgrading → To 18.7.0"
• Confidence: documented
• Render-limited: no

F-02: initdb.password now stored in chart Secret (secretKeyRef instead of plaintext value)

• Severity: informational
• Category: config_schema
• What changed: When primary.initdb.password is set, the credential is now injected via secretKeyRef rather than a plaintext value: in the StatefulSet env spec. The upstream note explicitly states "No action required for existing deployments."
• Why it does NOT affect this deployment: k8s/kellnr/values.yaml does not set primary.initdb.password (nor primary.initdb.user). The deployment uses auth.existingSecret: database-secrets for all credential injection.
• Affected dependents: none
• Required action: no action — informational
• Source: Artifact Hub documentation for version 18.7.0 — "Upgrading → To 18.7.0"
• Confidence: documented
• Render-limited: no

F-03: appVersion unchanged — no PostgreSQL engine migration required

• Severity: informational
• Category: data_migration
• What changed: Both chart 18.6.9 and 18.7.0 ship appVersion: 18.4.0. No PostgreSQL major or minor version bump occurred.
• Why it does NOT affect this deployment: No dump/restore or pg_upgrade is required. The on-disk data format is identical.
• Affected dependents: none
• Required action: no action — informational
• Source: Artifact Hub API metadata for both versions
• Confidence: documented
• Render-limited: no

Deployment fingerprint (summary)

Surface	Value
Chart dependency	bitnami/postgresql 18.6.9 → 18.7.0 (sub-chart of k8s/kellnr)
PostgreSQL engine version	18.4.0 (unchanged across both chart versions)
Architecture	standalone
TLS	tls.enabled: false (default; not overridden)
Auth	auth.existingSecret: database-secrets (SealedSecret); keys password (user) and postgres-password (admin)
auth.enablePostgresUser	false
auth.username / auth.database	kellnr / kellnr
primary.initdb.password	not set
backup.enabled	not set (default false); custom backup CronJob used instead
passwordUpdateJob.enabled	not set (default false)
metrics.enabled	not set (default false)
Node affinity	cloud.google.com/gke-provisioning: standard (GKE standard nodes only — no ARM/rpi5)
PVC mount path	/bitnami/postgresql (chart default)
Service	kellnr-postgresql:5432 (ClusterIP)
Kellnr connection	postgres.address: kellnr-postgresql, port 5432, user kellnr, db kellnr, password from database-secrets key password
Backup CronJob	Custom (k8s/kellnr/templates/backup.yaml), uses postgres:17.10 image directly — independent of this chart bump

Cluster fit

• Architectures required by cluster: amd64 only for this workload (nodeSelector cloud.google.com/gke-provisioning: standard pins to GKE standard nodes; no rpi5/arm64 nodes in scope)
• Architectures supported by new version: Bitnami BSI images support amd64 and arm64; amd64 confirmed present. No architecture regression noted in 18.7.0 release notes.
• Kubernetes API versions used in manifest sources: StatefulSet apps/v1 (stable), Service v1 (stable) — no deprecated APIs
• Minimum K8s version stated by dep: Kubernetes 1.23+ (stated in chart README); GKE standard nodes run well above this
• Peer dependency check: No cert-manager, Prometheus Operator, or mesh dependencies activated by this chart's values configuration. common@2.40.0 dependency is unchanged from 18.6.9.

Gaps

• Chart template diff not rendered: The two documented changes in the 18.7.0 upgrade notes were cross-referenced against the deployment fingerprint directly from the upstream README. The raw templates/ diff between 18.6.9 and 18.7.0 was not fetched from the Bitnami charts source repository. Given that both documented changes are gated on features this deployment does not use, and the appVersion is unchanged, the risk of an undocumented template-level breaking change is assessed as low — but cannot be fully excluded without rendering.
• BSI image registry access: Architecture manifest list for the specific bitnami/postgresql:18.4.0 BSI image tag was not verified from the registry directly (BSI images require authentication). Assessed as low risk given GKE amd64-only node selector and no architecture regression noted in release notes.
• Changelog completeness: The Bitnami BSI 18.x chart series does not publish a machine-readable changelog on Artifact Hub (has_changelog: false). The upgrade notes embedded in the chart README are the only authoritative source; these were read in full.

Upstream changelog

I now have all the information I need. The CHANGELOG.md confirms the chart version numbering (the CHANGELOG uses a different versioning scheme — the 18.x series is the BSI chart series, while the CHANGELOG shows a separate version track). The key finding is the "To 18.7.0" section in the README which is the official upgrade guide. Let me compile the structured output.

Key findings:

1. 18.6.9 → 18.7.0 is a minor version bump (18.x.y → 18.x+1.0) within the BSI chart series
2. The README has an explicit "To 18.7.0" upgrade section documenting two behavior changes
3. appVersion remains 18.4.0 — no PostgreSQL engine version change
4. No intermediate versions between 18.6.9 and 18.7.0 (it's a direct jump)
5. has_changelog: false on Artifact Hub (the CHANGELOG.md in the repo uses a different version track, not the 18.x BSI series)
6. New parameter: tls.sslMode (configurable, defaults to verify-ca)

---

postgresql (Bitnami Helm Chart) 18.6.9 → 18.7.0

Summary

• Artifact type: Helm Chart (OCI-based, Bitnami Secure Images series)
• Input format: SemVer chart version (Bitnami BSI chart series)
• Resolved references: Chart version 18.6.9 → 18.7.0; both have appVersion: 18.4.0 (no PostgreSQL engine version change)
• Versions in range: 18.6.9, 18.7.0 (no intermediate versions)
• Source repo: Bitnami charts repository (postgresql chart)
• Primary sources used:
  • README.md "Upgrading → To 18.7.0" section from the upstream Bitnami charts repository
  • Artifact Hub API: https://artifacthub.io/api/v1/packages/helm/bitnami/postgresql?version=18.7.0
  • CHANGELOG.md from the upstream Bitnami charts repository
• Versioning scheme: Bitnami BSI chart versioning — 18.x.y where 18 tracks the BSI image series (not PostgreSQL engine version). Minor bumps (18.6.x → 18.7.0) indicate notable chart-level changes; patch bumps are routine dependency/image updates.
• Major version boundary crossed: No (18.6.x → 18.7.x, same major)
• Confidence: high — maintainer-authored upgrade guide in README explicitly covers this version with two documented behavior changes

---

Breaking Changes

TLS-enabled deployments: backup CronJob and password-update Job now enforce TLS via PGSSLMODE

• What changed: When tls.enabled=true, the backup CronJob and password-update Job now set PGSSLMODE to enforce TLS connections; the SSL mode defaults to verify-ca and is configurable via the new tls.sslMode value.
• Affects: Config key tls.sslMode (new, default verify-ca); runtime behavior of backup.cronjob and passwordUpdateJob when tls.enabled=true
• Migration: If you use tls.enabled=true and your backup or password-update jobs previously connected without TLS enforcement, they will now require a valid CA-verifiable certificate. If verify-ca is too strict for your setup, set tls.sslMode to a less restrictive value (e.g., require). No action needed if you don't use tls.enabled=true.
• Source: Upstream Bitnami charts README "Upgrading → To 18.7.0" section
• Confidence: documented
• Introduced in: 18.7.0

primary.initdb.password now stored in Secret and injected via secretKeyRef instead of plaintext env value:

• What changed: When primary.initdb.password is set, the credential is now stored in the chart-managed Secret and injected into the init container via secretKeyRef rather than as a plaintext value: in the pod spec.
• Affects: Config key primary.initdb.password; pod spec of the primary StatefulSet init container
• Migration: No action required for existing deployments — the README explicitly states "No action required for existing deployments." New deployments will automatically use the more secure injection path.
• Source: Upstream Bitnami charts README "Upgrading → To 18.7.0" section
• Confidence: documented
• Introduced in: 18.7.0

---

Other Notable Changes

• New value tls.sslMode added (default: verify-ca): controls the SSL mode used by the backup CronJob and password-update Job when tls.enabled=true. (README parameters table)
• appVersion unchanged at 18.4.0 — no PostgreSQL engine upgrade in this chart bump.
• common dependency remains at 2.40.0 — no dependency version change from 18.6.9.
• contains_security_updates: false per Artifact Hub metadata.

Deprecations Introduced

None found.

Gaps and Caveats

• The CHANGELOG.md in the upstream Bitnami charts repository uses a different version numbering scheme (currently at 17.x) that does not correspond to the 18.x BSI chart series published on Artifact Hub. The 18.x series changelog is not tracked in that file; the README "Upgrading" section is the sole official source for 18.7.0 changes.
• No migration guide beyond the two bullet points in the README "To 18.7.0" section was found. The section is terse but covers the full scope of documented changes.
• The TLS PGSSLMODE change is documented as a behavior change for the backup CronJob and password-update Job only — it does not affect the main PostgreSQL StatefulSet TLS configuration.

Provenance

RESEARCH_FAILED: provenance researcher could not complete.

Reason: Prompt error: CompletionError: ProviderError: {"error":{"message":"{\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"prompt is too long: 205503 tokens > 200000 maximum\"},\"request_id\":\"req_011Cbdhh2RE1pLh8cNUqJ6kS\"}. Received Model Group=claude-haiku-4-5\nAvailable Model Group Fallbacks=['claude-haiku-4-5-fallback']\nError doing the fallback: {\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"prompt is too long: 205335 tokens > 200000 maximum\"},\"request_id\":\"req_011Cbdhh6Je2aKkbD2aF5rNw\"}"

The categorizer must treat this as an unverified signal and downgrade the verdict accordingly (do not assume safety).