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:
  cluster:
    enabled: true              # Always true — the Core is the baseline
    subFeatures:
      knowledgeGraph: true
  cloud:
    enabled: false             # Set to true once the Cloud Agent entitlement is active
    provider: aws              # aws | azure | gcp
    aws:
      regionOverride: ""       # Optional: pin a different region from the
                               # cluster's ambient one (Bedrock region is
                               # separate — see agent.model.region 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.
  idp:
    enabled: false
    writeOperations:
      enabled: false           # Separate toggle — the Core Plus entitled
                               # but write-ops disabled is a valid
                               # "scaffolding only" mode.
    auditLog: true

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

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

Agent runtime

agent:
  model:
    scheduled: fast            # Haiku — background scans, low-stakes calls
    interactive: smart         # Sonnet — chat, complex reasoning
    region: us-east-1          # Bedrock region. Different from cluster
                               # region — Bedrock isn't in every region.
  schedule:
    healthCheckInterval: 30m   # Reporter cadence
    knowledgeGraphRefresh: 1h  # Scanner re-run
    entitlementCheck: 1h       # License re-verification
  namespaces:
    include: []                # Scope the scan. Empty = all namespaces
                               # minus the excluded list.
    exclude:
      - kube-system
      - kube-public
      - kube-node-lease

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
• agent.model.scheduled → AGENT_MODEL_SCHEDULED
• 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.