Helm values reference

Cloudkeel-DD installs from the d-detective Helm chart. This page covers the values you’ll most often set. Run helm show values <chart> for the complete, authoritative list shipped with your version.

Images

Value	Default	Notes
images.backend.repository	driftdetective/ddetective-backend	Backend/worker/beat image (one image, three commands)
images.backend.tag	chart appVersion	Pin to a specific version in production
images.frontend.repository	driftdetective/ddetective-frontend	UI image
images.frontend.tag	chart appVersion
imagePullSecrets	[]	Only needed for a private registry without workload-identity pull

Ingress (optional)

The frontend proxies /api to the backend itself at runtime, so no Ingress controller is required to reach a fully working app: helm install then kubectl port-forward svc/<release>-frontend 3000:3000 is enough. Enable ingress for a stable, TLS-terminated hostname instead of port-forwarding (typical for production).

Value	Default	Notes
ingress.enabled	false	Set true for a stable hostname/TLS
ingress.className	""	Your ingress controller’s class (only used when enabled)
ingress.host	d-detective.example.com	Set this to your DNS name (only used when enabled)
ingress.tls.enabled / .secretName	false / ""	Enable and supply a TLS secret in production
frontend.service.type	ClusterIP	Set LoadBalancer/NodePort for external access without ingress

Secrets

Value	Notes
secrets.fernetKey	Immutable credential-encryption key. Set once; never change. See Secrets
secrets.jwtSecret	Signs user session tokens. Rotating it logs everyone out

The Fernet key is immutable

Changing secrets.fernetKey after install makes every stored cloud credential undecryptable. Keep it in your secret manager and pass the same value on every upgrade.

Database & cache

Value	Notes
postgresql.enabled	Set false in production and point at managed PostgreSQL
postgresql.auth.password	Bundled-PostgreSQL password (pilot only)
External DB / Redis	Supply host/port/credentials per your chart version’s keys

Scanning

Value	Notes
Scan schedule	Configurable per integration in the UI, or a global cadence
Worker replicas	Increase for more parallel scans; beat stays at 1

The pilot timer

On chart 0.3.4 and newer, an unkeyed install scans unmetered for its trial window and then converts to Free: 1 enabled scope, 3 users and every feature. The timer uses a local date comparison against the values below: nothing phones home, there is no licence server, and an air-gapped install behaves identically. Charts 0.3.0–0.3.3 instead stopped new scans when the window ended.

Value	Default	Notes
config.licenseTrialDays	30	Days from the later of the first workspace or the first enforcing upgrade before the window closes
config.licenseExpiresAt	""	An explicit UTC date (2026-12-31 or 2026-12-31T23:59:59Z). When set it wins over licenseTrialDays: this is how a window is extended
config.licenseEnforcementEnabled	true	Set false to run the timer in reporting-only mode: state is still computed and shown, nothing is blocked
secrets.licenseKey	""	A licence key, applied at install/upgrade time. Optional - without one the install runs its pilot window and then the Free allowance. Wins over a key entered in Settings. Chart 0.3.4+. See Licensing

The three config.* timer values live in the ConfigMap. The licence key is passed through a Kubernetes Secret; handle it as a bearer token.

Changing them is a plain helm upgrade. The backend, worker and beat pods carry a checksum annotation over this ConfigMap, so they roll themselves; there is no separate restart to remember.

What happens when the trial ends

On current releases, one scope keeps scanning on its normal schedule. Scopes beyond the Free allowance are held back with an explanation and resume when a key raises the limit or another scope is disabled. Findings, history, connected integrations and login keep working, running scans finish, and nothing is deleted.

An upgrade cannot cut an existing install short

The window is anchored on whichever is later: your first workspace, or the first time this install ran a version that enforces the timer. An install that predates enforcement gets a full window from the upgrade, never a retroactive expiry.

Applying values

Keep a version-controlled production-values.yaml (secrets referenced from your secret manager, never committed) and apply with helm upgrade --install ... -f production-values.yaml. See Upgrades.