fix(hosting): deploy ClickHouse from the official image instead of Bitnami#4249
fix(hosting): deploy ClickHouse from the official image instead of Bitnami#4249matt-aitken wants to merge 1 commit into
Conversation
|
WalkthroughClickHouse configuration is updated across self-hosting documentation, Docker Compose, and Helm. Docker now uses the official image, updated credentials and paths, file limits, and a compatible data-path configuration. Helm replaces the Bitnami dependency with custom ClickHouse resources, pinned image settings, explicit ports, probes, persistence, security settings, generated URLs, and updated tests. Documentation records the ClickHouse 25.8+ requirement and external service port key. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🧭 Helm Chart Prerelease PublishedVersion: Install: helm upgrade --install trigger \
oci://ghcr.io/triggerdotdev/charts/trigger \
--version "4.5.3-pr4249.4608012"
|
| {{- .Values.clickhouse.host }} | ||
| {{- else if .Values.clickhouse.deploy }} | ||
| {{- printf "%s-clickhouse" .Release.Name }} | ||
| {{- printf "%s-clickhouse" (include "trigger-v4.fullname" .) }} |
There was a problem hiding this comment.
🔍 Helm hostname helper changed from Release.Name to fullname — naming shift for existing releases
The ClickHouse hostname helper (hosting/k8s/helm/templates/_helpers.tpl:418) changed from printf "%s-clickhouse" .Release.Name to printf "%s-clickhouse" (include "trigger-v4.fullname" .). For the common case where the release name is trigger (same as chart name), fullname returns just the release name, so behavior is unchanged. However, if someone installed with a different release name (e.g., helm install my-app ...), the old helper would produce my-app-clickhouse while the new one produces my-app-trigger-clickhouse. Since the bitnami subchart is being removed entirely and replaced with the custom StatefulSet (which also uses fullname), the helper and the actual service name are now consistent with each other — this is correct. But existing releases with non-default names will see the ClickHouse URL change, potentially breaking connectivity until the new StatefulSet is ready.
Was this helpful? React with 👍 or 👎 to provide feedback.
| - name: clickhouse | ||
| version: "9.4.4" | ||
| repository: "oci://registry-1.docker.io/bitnamicharts" | ||
| condition: clickhouse.deploy | ||
| - name: minio |
There was a problem hiding this comment.
🔍 Bitnami ClickHouse subchart removal is a major Helm upgrade event
Removing the bitnami clickhouse dependency from Chart.yaml and replacing it with a custom StatefulSet means that on helm upgrade, Helm will delete all resources previously managed by the bitnami subchart (StatefulSet, Service, ConfigMaps, etc.) and create new ones from the custom template. The PVC naming convention differs between bitnami (typically data-{release}-clickhouse-shard0-0) and the new template (data-{fullname}-clickhouse-0). Existing PVCs won't be automatically reused. Users with EVENT_REPOSITORY_DEFAULT_STORE=clickhouse_v2 enabled will lose historical run event data unless they manually migrate. The persistence.retain: false default means PVCs won't even get the helm.sh/resource-policy: keep annotation.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Actionable comments posted: 2
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 5b011ec9-14cc-4db0-aa28-1d39f52766ce
⛔ Files ignored due to path filters (1)
hosting/k8s/helm/Chart.lockis excluded by!**/*.lock
📒 Files selected for processing (10)
docs/self-hosting/docker.mdxdocs/self-hosting/kubernetes.mdxhosting/docker/.env.examplehosting/docker/webapp/docker-compose.ymlhosting/k8s/helm/Chart.yamlhosting/k8s/helm/templates/_helpers.tplhosting/k8s/helm/templates/clickhouse.yamlhosting/k8s/helm/templates/tests/test-clickhouse.yamlhosting/k8s/helm/values-production-example.yamlhosting/k8s/helm/values.yaml
💤 Files with no reviewable changes (1)
- hosting/k8s/helm/Chart.yaml
📜 Review details
⏰ Context from checks skipped due to timeout. (4)
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: code-quality / code-quality
- GitHub Check: audit
- GitHub Check: audit
🧰 Additional context used
📓 Path-based instructions (1)
docs/**/*.mdx
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/*.mdx: MDX documentation pages must include frontmatter with title (required), description (required), and sidebarTitle (optional) in YAML format
Use Mintlify components for structured content: , , , , , , /, /
Always import from@trigger.dev/sdkin code examples (never from@trigger.dev/sdk/v3)
Code examples must be complete and runnable where possible
Use language tags in code fences:typescript,bash,jsonDocumentation in
docs/uses MDX conventions defined by the documentation guidance.
Files:
docs/self-hosting/docker.mdxdocs/self-hosting/kubernetes.mdx
🧠 Learnings (3)
📚 Learning: 2026-03-10T12:44:14.176Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3200
File: docs/config/config-file.mdx:353-368
Timestamp: 2026-03-10T12:44:14.176Z
Learning: In the trigger.dev repo, docs PRs are often companions to implementation PRs. When reviewing docs PRs (MDX files under docs/), check the PR description for any companion/related PR references and verify that the documented features exist in those companion PRs before flagging missing implementations. This ensures docs stay in sync with code changes across related PRs.
Applied to files:
docs/self-hosting/docker.mdxdocs/self-hosting/kubernetes.mdx
📚 Learning: 2026-04-30T20:30:29.458Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3226
File: docs/ai-chat/quick-start.mdx:13-13
Timestamp: 2026-04-30T20:30:29.458Z
Learning: In this repo’s documentation MDX files (`docs/**/*.mdx`), use `ts` and `tsx` (not `typescript`) as the code-fence language tags for TypeScript/TSX snippets. Do not flag `ts`/`tsx` code-fence language tags as incorrect in any docs MDX file, since this is the site-wide Mintlify-compatible convention.
Applied to files:
docs/self-hosting/docker.mdxdocs/self-hosting/kubernetes.mdx
📚 Learning: 2026-04-23T08:44:10.511Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3429
File: hosting/k8s/helm/values.yaml:211-218
Timestamp: 2026-04-23T08:44:10.511Z
Learning: In the Trigger.dev Helm chart helper templates, for both `trigger-v4.webappServiceAccountName` and `trigger-v4.supervisorServiceAccountName`, if `serviceAccount.create` is `false` and `serviceAccount.name` is empty, use Helm `fail` to stop rendering (raise a template error) rather than falling back to the namespace default service account or depending on documentation warnings. This prevents silently producing an invalid/undesired ServiceAccount configuration.
Applied to files:
hosting/k8s/helm/templates/_helpers.tpl
🪛 YAMLlint (1.37.1)
hosting/k8s/helm/templates/clickhouse.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (9)
docs/self-hosting/docker.mdx (1)
347-348: LGTM!docs/self-hosting/kubernetes.mdx (1)
260-272: LGTM!Also applies to: 281-281
hosting/docker/.env.example (1)
131-131: LGTM!hosting/k8s/helm/templates/clickhouse.yaml (1)
1-156: LGTM!hosting/k8s/helm/values.yaml (2)
619-686: LGTM!
626-633: 🩺 Stability & AvailabilityNo change needed for
clickhouse/clickhouse-server:26.2— the tag exists on Docker Hub, so this pin is pullable.> Likely an incorrect or invalid review comment.hosting/k8s/helm/values-production-example.yaml (1)
73-76: LGTM!hosting/docker/webapp/docker-compose.yml (1)
157-174: LGTM!hosting/k8s/helm/templates/tests/test-clickhouse.yaml (1)
19-19: LGTM!
| clickhouse: | ||
| image: bitnamilegacy/clickhouse:${CLICKHOUSE_IMAGE_TAG:-latest} | ||
| image: clickhouse/clickhouse-server:${CLICKHOUSE_IMAGE_TAG:-26.2} | ||
| restart: ${RESTART_POLICY:-unless-stopped} | ||
| logging: *logging-config | ||
| ports: | ||
| - ${CLICKHOUSE_PUBLISH_IP:-127.0.0.1}:9123:8123 | ||
| - ${CLICKHOUSE_PUBLISH_IP:-127.0.0.1}:9090:9000 | ||
| ulimits: | ||
| nofile: | ||
| soft: 262144 | ||
| hard: 262144 | ||
| environment: | ||
| CLICKHOUSE_ADMIN_USER: ${CLICKHOUSE_USER:-default} | ||
| CLICKHOUSE_ADMIN_PASSWORD: ${CLICKHOUSE_PASSWORD:-password} | ||
| CLICKHOUSE_USER: ${CLICKHOUSE_USER:-default} | ||
| CLICKHOUSE_PASSWORD: ${CLICKHOUSE_PASSWORD:-password} | ||
| CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT: 1 | ||
| volumes: | ||
| - clickhouse:/bitnami/clickhouse | ||
| - ../clickhouse/override.xml:/bitnami/clickhouse/etc/config.d/override.xml:ro | ||
| - clickhouse-data:/var/lib/clickhouse | ||
| - ../clickhouse/override.xml:/etc/clickhouse-server/config.d/override.xml:ro |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# 1. Verify override.xml exists at the expected path
fd -t f "override.xml" hosting/docker/
# 2. Search for volume migration documentation in docs
rg -i -n "clickhouse.*migrat|migrat.*clickhouse|clickhouse.*volume|volume.*clickhouse" docs/ || echo "No migration docs found — verify this is documented elsewhere"
# 3. Check for any remaining references to the old 'clickhouse' volume name
rg -n "^\s*clickhouse:" hosting/docker/webapp/docker-compose.yml || echo "Old volume name not found (good)"Repository: triggerdotdev/trigger.dev
Length of output: 1037
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Search for clickhouse-data / volume migration guidance =="
rg -n -i "clickhouse-data|clickhouse volume|volume migration|migrat.*clickhouse|clickhouse.*migrat|clickhouse.*data volume|data volume.*clickhouse" docs hosting/docker || true
echo
echo "== Relevant section of docs/self-hosting/docker.mdx =="
sed -n '340,430p' docs/self-hosting/docker.mdxRepository: triggerdotdev/trigger.dev
Length of output: 4728
Document the ClickHouse volume migration
Renaming the named volume from clickhouse to clickhouse-data will leave existing installs pointing at a fresh empty volume on upgrade. Add migration steps for docs/self-hosting/docker.mdx so users can carry over their existing ClickHouse data.
| {{- $protocol := ternary "https" "http" .Values.clickhouse.secure -}} | ||
| {{- $secure := ternary "true" "false" .Values.clickhouse.secure -}} | ||
| {{ $protocol }}://{{ .Values.clickhouse.auth.username }}:{{ .Values.clickhouse.auth.password }}@{{ include "trigger-v4.clickhouse.hostname" . }}:8123?secure={{ $secure }} | ||
| {{ $protocol }}://{{ .Values.clickhouse.auth.username }}:{{ .Values.clickhouse.auth.password }}@{{ include "trigger-v4.clickhouse.hostname" . }}:{{ .Values.clickhouse.service.ports.http }}?secure={{ $secure }} |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the Helm version and Chart.yaml apiVersion
fd -t f 'Chart.yaml' hosting/k8s/helm --exec cat {}
\;
# Also verify urlquery is a recognized built-in by rendering a test template
helm version --short 2>/dev/null || echo "Helm not installed in sandbox"Repository: triggerdotdev/trigger.dev
Length of output: 1011
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the ClickHouse URL helper blocks around the referenced lines.
file="hosting/k8s/helm/templates/_helpers.tpl"
wc -l "$file"
sed -n '420,485p' "$file"
# Locate all ClickHouse URL constructions in this file.
rg -n 'clickhouse\.(url|replication\.url|auth|external)' "$file"Repository: triggerdotdev/trigger.dev
Length of output: 5830
🌐 Web query:
Helm template built-in function urlquery Go text/template Helm docs
💡 Result:
The urlquery function in Helm is a built-in template function derived from the Go text/template package [1][2]. It is used to escape a string so that it is suitable for embedding within the query portion of a URL [3][4][1]. When used in a Helm template, it functions as follows: - Purpose: It returns the escaped version of the provided argument, ensuring special characters are encoded correctly for URL query parameters [3][4]. - Usage: It can be used as a function or in a pipeline [3][4]. For example: $var:= urlquery "string for query" or {{.Values.myParam | urlquery }} This function is native to the underlying Go template engine [1][2]. Note that in Go, the equivalent function is often referred to as URLQueryEscaper, but it is exposed in templates as urlquery [1][2]. This function is available in text/template but is generally unavailable in html/template due to security considerations regarding automatic context-aware escaping [1][2].
Citations:
- 1: https://pkg.go.dev/text/template
- 2: https://github.com/golang/go/blob/master/src/text/template/doc.go
- 3: https://github.com/helm/helm-www/blob/main/versioned_docs/version-3/chart_template_guide/function_list.md
- 4: https://helm.website.cncfstack.com/docs/next/chart_template_guide/function_list/
URL-encode the ClickHouse credentials in these URL helpers. The deploy and external branches interpolate usernames/passwords directly into the URL userinfo, so reserved characters like @, /, ?, or # can break ClickHouse connectivity. Apply | urlquery to the literal username/password values in both trigger-v4.clickhouse.url and trigger-v4.clickhouse.replication.url; keep $(CLICKHOUSE_PASSWORD) unchanged in the existing-secret branches.
…tnami The Bitnami free image catalog is EOL and its frozen bitnamilegacy archive tops out at ClickHouse 25.7.5, below the 25.8 floor the platform requires since v4.5.0. The Docker Compose stack and the Helm chart now run the official clickhouse/clickhouse-server image at 26.2, the same version the platform is developed and tested against. The Helm chart deploys ClickHouse with a chart-owned StatefulSet instead of the Bitnami subchart. Existing deployments keep their data with no manual steps: a config override keeps the on-disk layout compatible with volumes created by the Bitnami-based setup, Compose reuses the same named volume, and the Helm chart automatically adopts the data PVC left behind by the old subchart.
e2e7e33 to
4608012
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
hosting/k8s/helm/templates/clickhouse.yaml (1)
102-123: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winConsider adding a
startupProbefor ClickHouse cold starts.ClickHouse can take significantly longer to start than the
initialDelaySecondswindow when loading large datasets or replaying logs on a fresh pod. Without astartupProbe, thelivenessProbemay kill the container before it finishes initializing. AstartupProbewith a generousfailureThresholddisables liveness checks until startup succeeds.♻️ Suggested addition: startupProbe
+ {{- if .Values.clickhouse.startupProbe.enabled }} + startupProbe: + httpGet: + path: /ping + port: http + initialDelaySeconds: {{ .Values.clickhouse.startupProbe.initialDelaySeconds }} + periodSeconds: {{ .Values.clickhouse.startupProbe.periodSeconds }} + timeoutSeconds: {{ .Values.clickhouse.startupProbe.timeoutSeconds }} + failureThreshold: {{ .Values.clickhouse.startupProbe.failureThreshold }} + {{- end }} {{- if .Values.clickhouse.livenessProbe.enabled }} livenessProbe:
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 7094c57d-5101-416d-8ce8-1f031c663765
⛔ Files ignored due to path filters (1)
hosting/k8s/helm/Chart.lockis excluded by!**/*.lock
📒 Files selected for processing (11)
docs/self-hosting/docker.mdxdocs/self-hosting/kubernetes.mdxhosting/docker/.env.examplehosting/docker/clickhouse/data-paths.xmlhosting/docker/webapp/docker-compose.ymlhosting/k8s/helm/Chart.yamlhosting/k8s/helm/templates/_helpers.tplhosting/k8s/helm/templates/clickhouse.yamlhosting/k8s/helm/templates/tests/test-clickhouse.yamlhosting/k8s/helm/values-production-example.yamlhosting/k8s/helm/values.yaml
💤 Files with no reviewable changes (1)
- hosting/k8s/helm/Chart.yaml
🚧 Files skipped from review as they are similar to previous changes (4)
- hosting/docker/.env.example
- hosting/k8s/helm/templates/_helpers.tpl
- docs/self-hosting/docker.mdx
- hosting/k8s/helm/values.yaml
📜 Review details
⏰ Context from checks skipped due to timeout. (4)
- GitHub Check: code-quality / code-quality
- GitHub Check: audit
- GitHub Check: audit
- GitHub Check: Analyze (javascript-typescript)
🧰 Additional context used
📓 Path-based instructions (1)
docs/**/*.mdx
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/*.mdx: MDX documentation pages must include frontmatter with title (required), description (required), and sidebarTitle (optional) in YAML format
Use Mintlify components for structured content: , , , , , , /, /
Always import from@trigger.dev/sdkin code examples (never from@trigger.dev/sdk/v3)
Code examples must be complete and runnable where possible
Use language tags in code fences:typescript,bash,jsonDocumentation in
docs/uses MDX conventions defined by the documentation guidance.
Files:
docs/self-hosting/kubernetes.mdx
🧠 Learnings (2)
📚 Learning: 2026-03-10T12:44:14.176Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3200
File: docs/config/config-file.mdx:353-368
Timestamp: 2026-03-10T12:44:14.176Z
Learning: In the trigger.dev repo, docs PRs are often companions to implementation PRs. When reviewing docs PRs (MDX files under docs/), check the PR description for any companion/related PR references and verify that the documented features exist in those companion PRs before flagging missing implementations. This ensures docs stay in sync with code changes across related PRs.
Applied to files:
docs/self-hosting/kubernetes.mdx
📚 Learning: 2026-04-30T20:30:29.458Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3226
File: docs/ai-chat/quick-start.mdx:13-13
Timestamp: 2026-04-30T20:30:29.458Z
Learning: In this repo’s documentation MDX files (`docs/**/*.mdx`), use `ts` and `tsx` (not `typescript`) as the code-fence language tags for TypeScript/TSX snippets. Do not flag `ts`/`tsx` code-fence language tags as incorrect in any docs MDX file, since this is the site-wide Mintlify-compatible convention.
Applied to files:
docs/self-hosting/kubernetes.mdx
🪛 YAMLlint (1.37.1)
hosting/k8s/helm/templates/clickhouse.yaml
[error] 1-1: syntax error: expected the node content, but found '-'
(syntax)
🔇 Additional comments (6)
docs/self-hosting/kubernetes.mdx (1)
260-277: LGTM!Also applies to: 289-289
hosting/k8s/helm/values-production-example.yaml (1)
74-76: LGTM!hosting/docker/clickhouse/data-paths.xml (1)
1-17: LGTM!hosting/docker/webapp/docker-compose.yml (1)
158-176: LGTM! The volume name is preserved asclickhouse(not renamed toclickhouse-data), which addresses the prior review concern about existing installs losing their data volume on upgrade. Thedata-paths.xmlmount ensures on-disk layout compatibility with old Bitnami volumes, and the environment variables (CLICKHOUSE_USER,CLICKHOUSE_PASSWORD,CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT) are consistent with the Helm chart's ClickHouse container configuration.hosting/k8s/helm/templates/tests/test-clickhouse.yaml (1)
19-19: LGTM! The test correctly uses thetrigger-v4.clickhouse.hostnamehelper andclickhouse.auth.username/passwordvalues, consistent with the ClickHouse Service and auth configuration defined in the Helm chart.hosting/k8s/helm/templates/clickhouse.yaml (1)
1-88: LGTM!Also applies to: 93-101, 124-177, 179-199
| - name: CLICKHOUSE_USER | ||
| value: {{ .Values.clickhouse.auth.username | quote }} | ||
| - name: CLICKHOUSE_PASSWORD | ||
| value: {{ .Values.clickhouse.auth.password | quote }} |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
ClickHouse password is stored as a plaintext environment variable.
The password from .Values.clickhouse.auth.password is passed directly via value, making it visible in the StatefulSet manifest (kubectl describe pod) and in etcd. Using a Kubernetes Secret with valueFrom.secretKeyRef would keep it out of the pod spec while remaining compatible with the official ClickHouse image's CLICKHOUSE_PASSWORD env var.
🔒 Suggested refactor: use a Secret for the ClickHouse password
Add a conditional Secret resource (or support an existing one) and reference it in the env section:
env:
- name: CLICKHOUSE_USER
value: {{ .Values.clickhouse.auth.username | quote }}
- name: CLICKHOUSE_PASSWORD
- value: {{ .Values.clickhouse.auth.password | quote }}
+ {{- if .Values.clickhouse.auth.existingSecret }}
+ valueFrom:
+ secretKeyRef:
+ name: {{ .Values.clickhouse.auth.existingSecret }}
+ key: password
+ {{- else }}
+ valueFrom:
+ secretKeyRef:
+ name: {{ include "trigger-v4.fullname" . }}-clickhouse
+ key: password
+ {{- end }}
- name: CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT
value: "1"And add a Secret resource (conditionally generated when no existingSecret is provided):
{{- if and .Values.clickhouse.deploy (not .Values.clickhouse.auth.existingSecret) }}
apiVersion: v1
kind: Secret
metadata:
name: {{ include "trigger-v4.fullname" . }}-clickhouse
labels:
{{- include "trigger-v4.componentLabels" (dict "Chart" .Chart "Release" .Release "Values" .Values "component" "clickhouse") | nindent 4 }}
type: Opaque
stringData:
password: {{ .Values.clickhouse.auth.password | quote }}
{{- end }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: CLICKHOUSE_USER | |
| value: {{ .Values.clickhouse.auth.username | quote }} | |
| - name: CLICKHOUSE_PASSWORD | |
| value: {{ .Values.clickhouse.auth.password | quote }} | |
| - name: CLICKHOUSE_USER | |
| value: {{ .Values.clickhouse.auth.username | quote }} | |
| - name: CLICKHOUSE_PASSWORD | |
| {{- if .Values.clickhouse.auth.existingSecret }} | |
| valueFrom: | |
| secretKeyRef: | |
| name: {{ .Values.clickhouse.auth.existingSecret }} | |
| key: password | |
| {{- else }} | |
| valueFrom: | |
| secretKeyRef: | |
| name: {{ include "trigger-v4.fullname" . }}-clickhouse | |
| key: password | |
| {{- end }} |
Summary
Self-hosted deployments now run ClickHouse from the official
clickhouse/clickhouse-serverimage instead ofbitnamilegacy/clickhouse. Bitnami's free image catalog is EOL and the frozen legacy archive tops out at ClickHouse 25.7.5, below the 25.8 minimum the platform requires since v4.5.0, which broke every ClickHouse insert on chart-bundled deployments. Both stacks now default to 26.2, the same version the platform is developed and tested against.Existing deployments keep their ClickHouse data with no manual migration.
Fixes #4197.
Details
Docker Compose: the
clickhouseservice uses the official image with its native env vars, plus the recommendednofileulimits. It reuses the same named volume as before: adata-paths.xmlconfig override points ClickHouse at thedata/subdirectory of the volume, which is exactly the layout the Bitnami image used, so old volumes work in place (including SQL-created users) and fresh installs get the identical layout.Helm chart: the Bitnami ClickHouse subchart is replaced by a chart-owned single-node StatefulSet and Service running the official image (non-root, HTTP
/pingprobes, config overrides mounted intoconfig.d, and the samedata-paths.xmllayout compatibility). On upgrade, the chart automatically adopts the data PVC left behind by the old subchart (data-<release>-clickhouse-shard0-0) vialookup, andfsGrouprelabeling handles the uid change on first mount. Existingclickhouse.*values keep working:auth,persistence(includingglobal.storageClass),resources,secure,external.*, andconfigdFiles. Bitnami-only keys (shards,replicaCount,keeper,resourcesPreset) are gone. The docs now state the 25.8 minimum for bring-your-own ClickHouse.One caveat:
lookupreturns nothing when manifests are rendered without cluster access (GitOps tools that usehelm template). For that case there's a newclickhouse.persistence.existingClaimvalue, documented in the values file and the Kubernetes self-hosting docs.Verification
main(Bitnami 25.5), wrote 5,000 rows, then brought the same project up with this branch's compose file. The official 26.2 server came up healthy on the same volume with all rows intact, SQL-created users working, and writes succeeding.helm lint,helm template(default values,existingClaimset, external ClickHouse, and the production example) and kubeconform all pass, mirroring the release CI steps.input_format_json_infer_array_of_dynamic_from_array_of_different_types(the setting that fails on 25.7.5) succeed on the upgraded volume.