Helm Chart Reference
Versioning, compatibility, and upgrade reference for the Deepchecks llm-stack Helm chart
The Deepchecks application is distributed as a Helm chart named llm-stack, hosted as an OCI artifact at oci://registry.cdn.deepchecks.com/deepchecks/llm-stack. The chart packages the application image, all background workers, and the Kubernetes resources required to run them.
This page covers the chart's contents, the versioning relationship between the chart and the application, supported version combinations, and notable upgrade considerations.
Chart Contents
Installing the chart deploys the following Kubernetes resources into your namespace:
- One Deployment for the web server.
- One Deployment per background worker (13 workers by default; see Resource Defaults for the list).
- One Service for the web server (
ClusterIPon port8000). - One Ingress for the web server (created when
web.ingress.enabled: true). - One ServiceAccount for the application, plus a Role and RoleBinding (created when
serviceAccount.create: true). - One ConfigMap containing all non-sensitive environment variables passed via
global.env. - One Job that runs once on install to populate the storage bucket with model artefacts (controlled by
modelsSync.enabled). - KEDA
ScaledObjects andTriggerAuthentications for queue-driven worker autoscaling (created whenkedaAutoscaling.enabled: true).
Versioning
The chart and the application are versioned independently. A given chart version is typically compatible with a range of application versions — chart releases tend to be infrequent, while the application releases on a faster cadence. The chart's appVersion field is not authoritative for determining application compatibility; refer to the Compatibility Matrix below.
Selecting versions:
- Pick the application version you want to deploy. The application version corresponds to the version of these docs (e.g.
0.43.xfor thev0.43docs). - Look up the chart version that supports it in the matrix.
- If multiple chart versions support your target application version, prefer the highest one — it includes the latest fixes and chart-side improvements.
Compatibility Matrix
The following table tracks the supported combinations of chart and application versions. Rows are grouped by compatibility family — when chart-side changes affect application compatibility, a new row is added.
| Chart version | Supported application versions | Notes |
|---|---|---|
2.2.1 – 2.3.0 | 0.43.0+ | 2.3.0 adds optional topologySpreadConstraints support (non-breaking) |
Breaking Changes & Upgrade Notes
Chart upgrades that change values keys, default behaviour, or required configuration are listed here. Patch and minor releases that do not change compatibility are intentionally omitted.
No breaking changes are recorded for the chart versions tracked in the Compatibility Matrix.
Resource Defaults
The chart ships with default CPU and memory requests for the web server, each background worker, and the models-sync job. The full breakdown — useful for sizing your cluster — is documented in the Minimum Resource Requirements table on the Self-Hosted Deployments page. All defaults are overridable per component via web.resources, workers.<name>.resources, and modelsSync.resources.
Values Reference
To inspect the full values schema for a specific chart version, pull it directly from the OCI registry:
helm show values oci://registry.cdn.deepchecks.com/deepchecks/llm-stack --version <CHART_VERSION>The chart's README (rendered from helm show readme) documents each value in detail.
The most commonly customised top-level keys are:
| Key | Purpose |
|---|---|
global.image.repository | Container registry to pull the application image from (override for air-gapped) |
global.image.tag | Application image tag (matches the application version) |
global.imagePullSecrets | Image pull secrets for private registries |
global.secretName | Kubernetes Secret holding sensitive environment variables |
global.env | Non-sensitive environment variables passed to all pods |
web.ingress | Ingress configuration for the web application |
workers.<name>.replicaCount | Per-worker replica count (see KEDA Autoscaling for queue-driven scaling) |
kedaAutoscaling | KEDA-based queue autoscaling configuration |
modelsSync.enabled | Toggle for the post-install model sync job (disable for air-gapped deployments) |
For working values.yaml examples for each provider, see Example Configurations on the Self-Hosted Deployments page. For the full environment variable reference, see Environment Variables.
Updated 2 days ago