[ferhimedamine]

Chart 0.12.1 for Dakera server v0.12.1, released 2026-10-05; ghcr.io/dakera-ai/dakera:0.12.1 is on GHCR. Merging this publishes the chart: a push touching charts/** on main runs helm-release.yml and helm-publish-oci.yml.

Why this is a PR. The release's automatic bump (run 37282664638) failed. sync-on-release.yml committed the bump, but main is protected: GH006 … Changes must be made through a pull request. Nothing was published, and the registry still lists only 0.12.0. The workflow will fail the same way on every release until it opens a PR instead of pushing. That fix is a separate change.

Security: the dashboard no longer gets the root API key

The chart deployed dakera-dashboard:0.3.29 (dashboard.enabled: true by default) and passed DAKERA_ROOT_API_KEY to it as DAKERA_API_KEY. Dashboard 0.3.x writes that key into every page it serves. Anyone who could load the dashboard therefore held a super_admin key. This is the problem Dashboard 0.4.0 fixed (Dakera-AI/dakera-deploy#296); the chart never picked that fix up.

• dashboard.image.tag is now 0.5.0. Operators sign in at /login with their own key, which the dashboard keeps in server memory.
• The dashboard pod gets no key.
• Probes now use /_session/healthz.
• New optional value dashboard.sessionTtlHours sets DAKERA_SESSION_TTL_HOURS.
• scripts/validate-chart.sh (run by Chart CI) now fails if the dashboard pod is given an API key.
• CHANGELOG, an Artifact Hub kind: security entry and NOTES.txt (on upgrade) say: rotate dakera.rootApiKey if the dashboard was reachable by anyone who should not hold it.

Server 0.12.1

• Versions. version and appVersion are 0.12.1. The image tag follows appVersion. The artifacthub.io/changes annotation is rewritten the same way sync-on-release.yml does it.
• Cluster secret.
  • Server 0.12.1 makes every cluster node without DAKERA_CLUSTER_SECRET exit with code 78, upgraded or not.
  • The chart now refuses at render time when cluster mode (DAKERA_CLUSTER_MODE in dakera.extraEnv) has no secret.
  • It also refuses a secret under 16 characters after trimming (checked in the schema and the template), and a secret set two ways.
  • It does not generate one: one release is one node, so a per-release random secret would differ between nodes and split the cluster.
  • The README's "Cluster mode" section has the one-window and rolling procedures, adapted to Helm.
• Full-text indexes. The v0.12.0 "rebuild the full-text indexes" step is removed from NOTES.txt. In the READMEs it is kept only for servers still on 0.12.0, because 0.12.1 re-analyses the indexes at startup.
• Model change. Changing DAKERA_MODEL (e.g. features.multilingual on an existing store) now re-embeds in the background. Late interaction, vision and DAKERA_TIERED=1 still need the manual path.
• Statistics totals. Memory and session totals change meaning on the server. The alert rules and Grafana dashboard read Prometheus metrics, not those fields, so they are unchanged; a header comment says so.
• Docs. New "Upgrading from chart 0.12.0" sections, a CHANGELOG entry, and values.yaml comments updated.

Testing

• scripts/validate-chart.sh passes on Helm 3.14.4 (the CI version) and 3.16.2. That includes:
  • 16 cluster-secret refusal and acceptance checks;
  • the new dashboard check, which I confirmed fails when a key is injected into the dashboard pod.
• helm lint charts/dakera: 0 failed.
• helm template:
  • Defaults render dakera:0.12.1 and dakera-dashboard:0.5.0.
  • The dashboard has no key and its probes use /_session/healthz.
  • sessionTtlHours=24 renders the variable; abc is rejected by the schema.
  • Cluster mode with no secret fails with the explanatory message.
• kubeconform v0.6.7 (-strict, Kubernetes 1.30): 10/10 resources valid.
• helm package: OK.
• Not run: a live-cluster or kind install.

🤖 Generated with Claude Code

https://claude.ai/code/session_01511QNzJs2hyQ641pwyh68o

---

Generated by Claude Code