Configuration variables

How configuration is resolved

Each Go process reads environment variables directly. A code default only applies after the variable reaches the process; Docker Compose and the Helm chart expose smaller, different subsets of the complete runtime surface.

Code default

The value selected by shared/config when the process environment does not contain the variable.

Docker wiring

A variable explicitly listed beneath a service in docker-compose.yml. The root .env file is used for Compose interpolation, but it is not passed wholesale into containers.

Helm wiring

A chart value rendered into a workload environment. The chart has no general extraEnv escape hatch in the current dev state.

Local-process wiring

Defaults exported by scripts/start-local-services.sh before it launches locally built binaries.

Common service variables

Where a table row below says a variable is “not exposed” by a deployment method, it means there is no dedicated Compose declaration or Helm value for it. In Helm, any such variable can still be injected without template changes via extraEnv (all workloads) or <service>.extraEnv — see Helm values. In Compose, add it to the service environment block explicitly.

API authentication, sessions, and audit

The access cookie is HttpOnly and SameSite=Lax. ADMIN_COOKIE_SECURE controls its Secure attribute. Access and refresh TTL values are only parsed as integers; the loader does not reject zero or negative values, so use deliberate positive settings.

Public URLs and private-location authorization

OIDC single sign-on

Compose includes development-oriented Dex defaults under its optional profile. Helm exposes the platform OIDC settings and stores the client secret separately. In production, register an exact HTTPS callback and choose the least-privileged JIT role.

Encryption-at-rest keys

openssl rand -base64 32

API queues, local AI, mesh, and artifacts

Local AI uses one evaluated Probara checkpoint, served by the installation-owned inference service (ai-service/), for every AI surface: incident analysis, automatic alert triage and dependency suggestions. Range errors in the service variables stop the service at startup; Helm checks threads, queueCapacity, queueTimeoutSeconds, maxInferenceSeconds and timeoutSeconds (and that the queue timeout is below the client timeout) at render time instead. Workspace rows store only effective enablement: explicit enabled/disabled settings are preserved and absent settings default enabled. External providers and LLM_* execution are retired; old columns are retained for rollback. Explanations come from measured evidence and maintained templates.

Scheduler and result-ingest variables

Worker execution and network-policy variables

Worker AI and asynchronous notifications

The database-connected worker uses the same LOCAL_AI_* client variables as the API; Compose and Helm wire them to both, and Helm wires SMTP_* through its smtp values block. The AI_RCA_* variables and the AI_TRIAGE_* stream names are not wired, so their code defaults apply; set them through extraEnv only to rename the streams. AI_TRIAGE_ENABLED is wired to the worker, the alerter and the API. Only database-connected platform workers read AI_TRIAGE_*: they run the triage relay and consumer, and location workers never do. Private-location workers receive no database or AI credentials and execute checks independently. Notification-mode variables still require extraEnv.

Alerter and SMTP variables

The SMTP_* variables are read identically by three services, and each one needs them for a different reason: the alerter delivers alert email from its evaluation loop, the worker delivers it when asynchronous dispatch is enabled, and the API serves POST /api/v1/alert-channels/{id}/test, which runs the same email plugin in-process. An install that sets SMTP only on the alerter delivers alerts correctly but fails every email channel test with mailer not configured. The Helm smtp values block renders the variables into all three at once; set it there rather than in a single service's extraEnv.

The same three services also read the notification egress policy, because each one can deliver through a channel plugin. It is independent of the worker's HTTP_BLOCK_PRIVATE_IPS and, unlike it, blocks by default.

Status-page and live-update variables

The restricted proxy permits GET under /api/v1/monitors and PATCH under /api/v1/status-pages/…; it is not a general API proxy. Helm currently wires only basic status values and the status base URL, not the API proxy, cache, preview, timeout, or update-subject variables.

Frontend variables

Collector agent settings

The host agent is probara-collector, an OpenTelemetry Collector distribution started as probara-collector --config <path>. Its generated configuration contains no secrets; credentials are supplied through the environment (systemd EnvironmentFile, launchd runner script, or the Windows service registry Environment value).

Discovery collector settings

The Kubernetes discovery collector (probara-discovery-collector) runs in the cluster from the manifest the setup form generates, which sets PROBARA_URL and PROBARA_DISCOVERY_ID and mounts the token Secret at the default PROBARA_DISCOVERY_TOKEN_FILE path; you only need these when writing your own manifest. It reaches the Kubernetes API through the in-cluster KUBERNETES_SERVICE_HOST/KUBERNETES_SERVICE_PORT and the mounted service-account CA and token.

The collector reads its configuration (active and pending namespaces) at the start of every cycle and waits five minutes between cycles, or the Retry-After delay (1 second to 1 hour) when the API answers 409, 429 or 503; the API sends a 10-second Retry-After with a 409 when a namespace was removed during the scan, and none for a stale revision. A refused request is logged with the HTTP status and up to 512 bytes of the response body, which carries the API's reason (for example rate_limited or inventory_limit). Pending namespaces are scanned after the active ones and stop 30 seconds before the two-minute cycle deadline; each one skipped is logged as Pending namespace <ns> skipped (<reason>): <hint> (see Change namespaces).

Probara origin behind an internal CA: store the CA certificate in a ConfigMap in the collector's namespace (the integration's home namespace, the first one entered at setup), mount it, and point SSL_CERT_FILE at it. A bundle holding only that CA is enough, since the Probara origin is the only peer verified against it. The generated manifest does not include this, so reapply the patch after applying a regenerated manifest (reinstall rotates the token).

kubectl -n <home-namespace> create configmap probara-ca --from-file=ca.crt=internal-ca.pem
kubectl -n <home-namespace> patch deployment probara-discovery-<integration-prefix> -p '{"spec":{"template":{"spec":{
  "volumes":[{"name":"probara-ca","configMap":{"name":"probara-ca"}}],
  "containers":[{"name":"collector",
    "env":[{"name":"SSL_CERT_FILE","value":"/etc/probara-ca/ca.crt"}],
    "volumeMounts":[{"name":"probara-ca","mountPath":"/etc/probara-ca","readOnly":true}]}]}}}}'

Maintenance, build, and test variables

GitHub’s PR_TITLE, PR_BODY, TARGET_BRANCH, GITHUB_OUTPUT, and GITHUB_STEP_SUMMARY variables are workflow-internal inputs for release-preview classification, not product runtime configuration. Docker build workflow values such as REGISTRY and IMAGE_PREFIX are likewise CI-owned defaults.

Deployment wiring summary