Platform values configuration

How the file is shaped

Three parts, in this order. Understanding the split is what keeps the file maintainable.

The pattern looks like this:

x-common:
  routingHost: &routingHost "genesis.<env>.<your-domain>"

global:
  routing:
    mode: gateway-api
    host: *routingHost          # alias — follows the anchor

genesis-idp:
  extraEnv:
    - name: KC_HOSTNAME
      value: *keycloakExternalUrl

Tier 1 — must change for every environment

If you copy a values file and change nothing else, change these. Every one is a fact about your infrastructure, and a stale value here fails the install or silently points the platform at someone else's environment.

Environment identity — 7 values

Routing, ingress and environment — 5 values

These sit in global rather than x-common, and every chart default here is a local-development placeholder.

Container registry — 3 values

PostgreSQL — 8 values

The last two are database names. They only need changing if your naming convention differs — but they must match the databases preflight created.

Redis — 7 values, and the tier decides them

Two are anchors; the rest sit in global.redis. They are all Tier 1 because the Redis tier you provisioned as a prerequisite determines every one of them, and the chart's defaults match only the simplest case.

Values by product, each taken from a working deployment. The endpoint tells you which row you are on — the two Azure Redis products in particular are different services with different ports, and picking the wrong row is the most common Redis misconfiguration.

The reference customer values file starts at port: 6380, tls: true, auth: true — one managed shape, not the only one. Change the port to match your own endpoint. Leave enabled: true: the platform degrades badly without Redis, which handles sessions, rate limiting and SSE streaming.

These chart values take Redis as host plus port. If you are also setting the CLI's own config, that takes a rediss:// URL instead and has its own formatting trap — see the Redis notes in the install guide.

Secrets and workload identity — 4 values

Cloud service endpoints — 5 values

Tier 2 — must be internally consistent

These are not environment identity, so a copied file often "works". But they encode a contract between values, and a mismatch fails at runtime rather than at install.

The Postgres capacity gate

global.capacityGate is the one Tier 2 value that fails the render rather than failing later. It declares how many pods will consume the database, and the chart asserts your declaration against the footprint it actually renders.

The floor it enforces at pod startup:

floor = (expectedApiPods    × api_ceiling)
      + (expectedWorkerPods × worker_ceiling)
      + externalDbConsumers
      + 23 reserved

Tier 3 — leave these alone

Values that look environment-specific but are not. Editing them is how a working file starts drifting.

YAML behaviours that cost real time

Each of these has produced a failure that looked like something else.

x-common:
  devWorkerBase: &devWorkerBase
    enabled: true
    replicaCount: 2
  devWorkerEnv: &devWorkerEnv
    REDIS_ENABLED: "true"
    DEFAULT_PROVIDER: *llmProvider

genesis-dev-worker-io:
  <<: *devWorkerBase          # everything shared
  env:
    <<: *devWorkerEnv         # shared env
    WORKER_PROFILES: "io"     # ...then only what differs

Decisions to record, not copy

Some values are neither environment identity nor a safe default — they are open questions that a copied file carries forward invisibly. Mark them in your own file (a consistent # ACTION: comment works well) so they can be searched for and closed.

Before the first sync

helm template with your values catches schema errors and renders the manifests, but none of the checks above — each one is valid YAML that renders cleanly and fails later.

See also