Configuration

Full Helm values reference for the Tiphys chart. The complete default-values document ships with the chart artifact (run helm show values oci://ghcr.io/intelligant-ai/charts/tiphys --version <version> to dump it locally); this page walks through each block + the settings-to-env-var mapping the ConfigMap template wires up.

Capabilities

modules:
  core:
    enabled: true              # Always on: the baseline (Lynceus)
  cloud:
    enabled: false             # Cloud reads (Aeolus)
    provider: aws              # aws | azure | gcp; inventory reads are
                               # AWS-only today. The model's region is
                               # separate: see Model below.
    billedCosts:
      enabled: false           # Actual costs from AWS Cost Explorer. AWS
                               # bills your account $0.01 per request, so
                               # it's off: costs are list-price estimates
                               # from the free Price List API. Needs the
                               # Cost Explorer IAM policy (iam-setup.md).
      dailyRequestBudget: 20   # At most this many requests a day (UTC).
      cacheHours: 12           # Each answer is reused this long.
  corePlus:
    enabled: false             # Approved changes and scaffolding (Argus)
    writeOperations:
      enabled: false           # Separate toggle: Core Plus on with writes
                               # off is a valid "scaffolding only" mode.
                               # restrictions and resources narrow writes;
                               # see the chart's values.yaml.

Module gating follows this priority order (see Modules for the long version):

Entitlement. Free installs (no license key) are entitled to every module; a license from Intelligant, if set, is authoritative (see License).
Helm values (can opt out of entitled features; never opt in to unentitled ones).
Auto-detection (optional integrations only — Prometheus, ArgoCD, metrics-server, etc.).

Agent runtime

agent:
  clusterName: ""              # Shown in tool-call footers and audit entries.
                               # Blank: the cloud's cluster name, then the
                               # control plane's hostname.
  schedule:
    healthCheckInterval: 30m   # Reporter cadence
    knowledgeGraphRefresh: 1h  # Scanner re-run
    entitlementCheck: 1h       # License re-verification
    preflightRecheck: 5m       # Model and permission probes re-run
  namespaces:                  # Reserved, not applied yet: scans read every
    include: []                # namespace Tiphys's reader can.
    exclude:
      - kube-system
      - kube-public
      - kube-node-lease

Which model handles each kind of work isn't here: it's llm.tiers (scheduled for background scans and reports, interactive for chat; each fast or smart, both fast by default), and each provider's models name the model behind a tier. Bedrock's region is llm.bedrock.region. See Model.

Model

Tiphys is tuned for Claude. Pick where it runs with llm.provider; every provider but openai-compatible serves Claude. Whatever the model, it must call tools and take at least 64k tokens of context: Tiphys works through tool calls, and its instructions and tool results are long.

`llm.provider`	Where	How Tiphys gets in
`anthropic`	The Anthropic API	An API key, from a Secret
`bedrock` (default)	Amazon Bedrock, your AWS account	Keyless: IRSA or EKS Pod Identity
`vertex`	Vertex AI, your Google Cloud project	Keyless: workload identity
`azure`	Azure AI Foundry (Claude) or Azure OpenAI	Keyless: workload identity; or the resource's key
`openai-compatible`	Any chat-completions endpoint	A bearer key, if it needs one

Prefer a keyless provider: nothing long-lived to rotate or leak. Keys come only from Secrets you create; the chart never takes a key for these providers as a value. llm.tiers picks the tier per kind of work (scheduled, interactive), and each provider's models.fast and models.smart say which model is behind each tier.

Each investigation, one issue in one chat, may run for a limited time: its model and tool time, never the time waiting on you. At 80% of it Tiphys wraps up with what it found, the evidence and the fix it proposes; at the limit it pauses and asks whether to go on, and your next message starts a new investigation that picks up from the chat. Background work (history summaries) has small fixed limits of its own.

llm:
  investigationMinutes: 10   # 0: no limit

Anthropic API

llm:
  provider: anthropic
  anthropic:
    existingSecret: tiphys-anthropic   # kubectl create secret generic tiphys-anthropic \
    secretKey: api_key                 #   --from-literal=api_key=sk-ant-...
    baseUrl: ""                        # blank: https://api.anthropic.com
    models:
      fast: ""                         # blank: claude-haiku-4-5
      smart: ""                        # blank: claude-sonnet-4-6

Amazon Bedrock

llm:
  provider: bedrock
  bedrock:
    region: us-east-1                  # a region with Claude model access
    models:
      fast: ""                         # blank: Claude Haiku 4.5
      smart: ""                        # blank: Claude Sonnet 4.6
serviceAccount:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/tiphys-irsa

The role needs bedrock:InvokeModel and bedrock:Converse on the models (IAM setup).

Vertex AI

llm:
  provider: vertex
  vertex:
    project: my-project
    region: us-east5                   # a region serving Claude, or "global"
    models:
      fast: ""                         # blank: claude-haiku-4-5@20251001
      smart: ""                        # blank: claude-sonnet-4-6
    serviceAccount: tiphys@my-project.iam.gserviceaccount.com

Enable the Claude models in Vertex AI's Model Garden first. Then, keyless:

GKE: turn on workload identity, give the Google service account roles/aiplatform.user, and let the Kubernetes ServiceAccount act as it (roles/iam.workloadIdentityUser for serviceAccount:my-project.svc.id.goog[tiphys/tiphys]). The chart annotates the ServiceAccount with vertex.serviceAccount. Or grant roles/aiplatform.user to the Kubernetes ServiceAccount's principal directly and leave vertex.serviceAccount blank.
Any other cluster: workload identity federation. Create a pool and an OIDC provider that trusts your cluster's service-account issuer, then the credential configuration with gcloud iam workload-identity-pools create-cred-config ... --credential-source-file=/var/run/secrets/tiphys/google-token/token. Put that file in a Secret (vertex.credentials.existingSecret, key credentials.json) and set vertex.tokenAudience to the provider's audience; the chart projects the pod's token to that path.

A service-account key file in that Secret works too, as a last resort.

Azure

llm:
  provider: azure
  azure:
    endpoint: https://my-resource.services.ai.azure.com   # or https://my-resource.openai.azure.com
    api: foundry                       # foundry (Claude) | openai (Azure OpenAI)
    apiVersion: "2024-10-21"           # Azure OpenAI only
    models:
      fast: ""                         # deployment names; Foundry's default to
      smart: ""                        # claude-haiku-4-5 / claude-sonnet-4-6
    workloadIdentity:
      clientId: 00000000-0000-0000-0000-000000000000
      tenantId: ""                     # blank: the cluster's default tenant
    existingSecret: ""                 # or the resource's key, from a Secret
    secretKey: api_key

Keyless on AKS: turn on the OIDC issuer and workload identity, create a user-assigned managed identity with the Cognitive Services User role on the resource, and add a federated credential for system:serviceaccount:tiphys:tiphys with your cluster's issuer. Set azure.workloadIdentity.clientId to the identity's client ID; the chart labels the pod and annotates the ServiceAccount for the webhook. Without workload identity, set azure.existingSecret to a Secret holding the resource's key. With api: openai, name your deployments in models (Tiphys doesn't guess); a blank tier uses the other tier's deployment.

OpenAI-compatible endpoint

llm:
  provider: openai-compatible
  openaiCompatible:
    endpoint: https://gateway.example.com/v1
    existingSecret: tiphys-llm         # a Secret with `api_key`; blank for none
    models:
      fast: my-fast-model
      smart: my-smart-model

For a gateway, vLLM, Ollama, or another provider's chat-completions API. Tiphys is tuned for Claude; with other models, results may differ.

Integrations (optional, auto-detected)

integrations:
  prometheus:
    enabled: "auto"            # auto | true | false
    url: ""                    # Override auto-discovery; e.g.
                               # http://prometheus-kube-prometheus-prometheus.monitoring.svc:9090
  metricsServer:
    enabled: "auto"
  externalSecrets:
    enabled: "auto"
  argocd:
    enabled: "auto"

auto defers to detection: the scanner walks Services / CRDs / APIServices and flips the integration on when it sees the expected shape.

Reports + approvals

reports:
  target: configmap            # configmap | s3
  s3Bucket: ""
  retention: 30d
  recommenderMode: true        # true: findings carry recommendations, the
                               #   operator stages them manually in the UI.
                               # false: the Reporter auto-creates
                               #   ApprovalRequests at cron time so the
                               #   Approvals view populates overnight.
  maxAutoStagedPerTick: 10     # Only applies when recommenderMode=false.

approvals:
  ttlSeconds: 86400            # 24h. Bump to 172800 (48h) for weekend
                               # coverage. Was 5 min pre-v0.0.1 — the old
                               # value only worked for actively-watched
                               # chat approvals.
  configmapName: tiphys-approvals

Persistence

Four operator-visible stores are backed by dedicated ConfigMaps in the pod's namespace so state survives pod restarts:

persistence:
  snoozesConfigmapName: tiphys-snoozes
  auditConfigmapName: tiphys-audit
  auditMaxRetained: 500        # Cap at this many entries. Stays well
                               # under the 1 MiB ConfigMap size limit.

The reports ConfigMap is named reports.configmapName (defaults to tiphys-reports); the scan cache uses tiphys-scan (not currently parameterized).

Notifications

Outbound webhooks only — Tiphys never receives inbound traffic from these:

notifications:
  slack:
    enabled: false
    webhookUrl: ""
  teams:
    enabled: false
    webhookUrl: ""

Notifications fire on new critical findings since the previous report tick; a steady-state crashloop produces one notification, not one per scan interval.

Control plane (opt-in)

Off by default. With controlPlane.enabled: false, Tiphys never contacts Intelligant AI: no client is built, no poll is scheduled, and nothing leaves the cluster. Turn it on if you want Intelligant AI to be able to pause writes or announce maintenance on your install.

controlPlane:
  enabled: false                         # opt in with true
  endpoint: "https://api.intelligant.ai"
  pollSeconds: 300                       # minimum 30

What it sends. One unauthenticated GET {endpoint}/public/products/tiphys/status every pollSeconds, plus one at startup. No cluster name, no install id, no query string, no body, no credentials; the only identifying header is User-Agent: tiphys/<version>. The answer is Intelligant AI's public status for Tiphys, the same for every install.

What it does.

While the answer says writes are off (always the case during maintenance), the write-safety gate blocks every write tool before it stages anything, and POST /api/approve refuses to approve a change (the approval stays pending, so you can approve it once writes resume). Reads, chat, and reports keep working.
The UI shows a banner: "Tiphys is under maintenance" or "Changes are paused by Intelligant AI", with Intelligant's message and the expected end time.
The startup helm-release-record migration (Tiphys's own bookkeeping Secrets) is skipped while writes are paused. It is idempotent and runs on every start, so it catches up on the next restart.

Fail open. If the endpoint is unreachable, times out (5 s), returns a non-2xx, or returns something unexpected, Tiphys keeps the last answer it got. If it has never had an answer, writes are allowed and there is no maintenance. Errors are logged, never raised.

Resources

resources:
  backend:
    requests:
      cpu: 200m
      memory: 512Mi
    limits:
      cpu: 1000m
      memory: 1Gi
  frontend:
    requests:
      cpu: 50m
      memory: 64Mi
    limits:
      cpu: 200m
      memory: 128Mi

The backend's memory floor is driven by the LLM client buffering streams in flight. The frontend is a static nginx — the defaults are generous.

ServiceAccount + RBAC

serviceAccount:
  create: true
  name: ""                     # Defaults to the chart's fullname
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123:role/tiphys-irsa

RBAC roles the chart installs:

tiphys-reader — ClusterRole with get/list/watch on standard resources (Pods, Deployments, Services, ConfigMaps, Secrets, Events, etc.). Always installed.
tiphys-writer — ClusterRole with create/update/patch on workload resources. No delete, no cluster-admin, no secret-content reads. Installed only when modules.corePlus.writeOperations.enabled=true.
tiphys-state — namespaced Role for the agent's own state ConfigMaps (reports, approvals, snoozes, audit, scan). Narrow scope by resource name. Always installed.

License

license:
  key: ""                      # License file contents; empty = free (default)
  existingSecret: ""           # Or reference an existing Secret holding
                               # the license under data.license (preferred)

Tiphys is free: leave both empty and every module is available.

Licenses come from Intelligant. Your company's admin issues one for each install in Intelligant Accounts (Company → Licenses), named for where it runs (for example prod-east), and can download it again later. Treat the file like a credential: install it as a Secret rather than in your values file, and don't paste it into tickets or logs.

kubectl -n tiphys create secret generic tiphys-license --from-file=license=<your-file>
helm upgrade tiphys oci://ghcr.io/intelligant-ai/charts/tiphys -n tiphys \
  --reuse-values --set license.existingSecret=tiphys-license

The license is checked offline against keys built into the image, so air-gapped installs work and nothing is sent to Intelligant. It is re-checked with each cluster rescan (hourly by default). What it covers comes from your plan's limits, and only from the license: Helm values can turn a module off but never on. A license only ever adds to what a free install gets, and today the free install already has everything.

When it expires, Tiphys keeps running as licensed through the license's grace period (usually 14 days). A banner in the UI and warnings in the log name the date it stops. After that, anything only the license covered stops and Tiphys runs on the free tier. Your data (reports, audit log, conversations) stays readable, and the banner says why. Install a renewed license to restore it.

A license that has been altered, wasn't issued for Tiphys, or was signed with a key this version doesn't carry is refused: the reason is in the backend log and Tiphys runs read-only (Core) until a valid license is installed. If a newly issued license is refused for an unknown key, upgrade Tiphys. Licenses Tiphys issued itself before it joined Intelligant keep working until they expire.

For local development, license.key: dev marks the install as dev in the UI and audit trail.

Settings-to-env mapping

The chart's ConfigMap template flattens the Helm values into env vars the backend's Pydantic Settings class reads. The naming rule:

modules.cloud.enabled → MODULE_CLOUD_ENABLED
llm.tiers.scheduled → AGENT_MODEL_SCHEDULED
llm.anthropic.models.smart → LLM_ANTHROPIC_MODEL_SMART; likewise LLM_VERTEX_* and LLM_AZURE_* (each renders only for its provider). Keys come from Secrets as LLM_ANTHROPIC_API_KEY, LLM_AZURE_API_KEY and LLM_OPENAI_API_KEY, never through the ConfigMap.
integrations.prometheus.url → INTEGRATION_PROMETHEUS_URL
reports.recommenderMode → REPORTS_RECOMMENDER_MODE
approvals.ttlSeconds → APPROVAL_TTL_SECONDS
controlPlane.enabled → CONTROL_PLANE_ENABLED (CONTROL_PLANE_ENDPOINT and CONTROL_PLANE_POLL_SECONDS render only when enabled)

To see the full mapping for an installed release, render the chart and inspect the rendered ConfigMap:

helm get manifest <release-name> -n tiphys \
  | yq 'select(.kind == "ConfigMap" and (.metadata.name | contains("tiphys")))'

To override just one value without rendering the full chart, set the env var directly on the Deployment via your own overlay.