Skip to main content
This page lists every setting in the Genesis Helm chart’s values file, values.yaml. Use it alongside the install guide for your platform: AWS, GCP, Azure or local Kubernetes. Put your settings in your own values file and pass it with -f, or set one value at a time with --set. Anything you leave out keeps the default shown here.
Pass the same values file on every upgrade. helm upgrade with -f starts again from the chart’s defaults plus that file, so a setting missing from it goes back to its default.
Settings for the Genesis application itself, such as LLM providers, connections and feature limits, are not Helm values. Put them in a Genesis config file passed with genesisConfig.content, or set them in Config > Advanced Settings. The Configuration Reference lists all of them.

What a new install must set

A first helm install fails unless these are set:
  • identity.clientName and identity.instanceName: the name of this install. See Install identity.
  • A master encryption key: secrets.genesisMasterKey, secrets.existingSecretGenesisMasterKey, or config.extraEnv.GENESIS_MASTER_KEY_REF. See Secrets.
On helm upgrade neither is checked. An install that predates the names gets a reminder in the upgrade notes instead of an error.
The chart does not keep the master key for you. Give the same master key setting on every upgrade. If secrets.genesisMasterKey is left out of an upgrade, the chart drops the key from the Secret it manages, and Helm deletes that Secret outright when no other credential set directly under secrets.* keeps it. Either way Genesis starts without your key, so the secrets it stored cannot be read. To avoid this, keep the key in a Secret you manage and point secrets.existingSecretGenesisMasterKey at it, or use config.extraEnv.GENESIS_MASTER_KEY_REF.
A minimal values file for a new install:

Install identity

These name the install on everything it reports to Genesis Computing: metrics uploads, support and enhancement requests, and logs. Genesis shows the install as <clientName>.<instanceName>, for example acme.prod2.
  • Names are lowercased, any run of characters other than a–z, 0–9 and - becomes -, leading and trailing - are dropped, and each name is cut to 63 characters.
  • They render as GENESIS__SERVER__CLIENT_NAME, GENESIS__SERVER__INSTANCE_NAME and GENESIS__SERVER__BILLING_ENVIRONMENT. Setting one of those keys in config.extraEnv instead also works, and an explicit config.extraEnv entry wins over identity.*, even an empty one.
  • They can also be set in Config > Advanced Settings > Server, but a value set through the chart wins over one set there. If your licence carries a client name, the licence’s name wins.

Chart naming and namespace

Container image

Private Amazon ECR registry

Secrets

Each credential can be given directly, in which case the chart stores it in a Kubernetes Secret it creates, or by naming a Secret you already manage. Use one or the other for each credential. To fetch the master key from AWS Secrets Manager or Google Secret Manager at startup instead, leave both master key settings empty and set config.extraEnv.GENESIS_MASTER_KEY_REF to a reference such as aws_prod/genesis-keys#master_key. The pod needs cloud credentials (IRSA or Workload Identity) for this. See External Secrets.

Server settings

These render into the Genesis ConfigMap as environment variables.

Starting LLM provider and models

The chart chooses a starting LLM provider from the credentials you give it: Databricks when a Databricks token or config.databricksBaseUrl is set, otherwise OpenAI (or Azure OpenAI when config.azureOpenaiEndpoint is set) when an OpenAI key is set. These settings only seed the provider: a provider chosen later in Config > AI Providers or in the Genesis config file wins. For Anthropic, Bedrock, Vertex AI or a LiteLLM proxy, configure the provider in the Genesis config file instead.

Databricks SQL warehouse connection

Creates a Databricks database connection when Genesis starts. Its token comes from secrets.databricksDbPat or secrets.existingSecretDatabricksDbPat.

Genesis config file, RBAC and role mapping

Precedence for a configuration setting, highest first: a GENESIS__* environment variable (for example from config.extraEnv), then a value stored in Genesis (from the config file, the UI or Advanced Settings), then a legacy environment variable the setting reads by default, then the built-in default.

Agent sandboxes

Lets agents run long-running jobs, shell commands and scripts in their own Kubernetes pods. When enabled, the chart creates a sandbox namespace, the RBAC that lets Genesis manage pods in it, and per-install bindings for the service account the Genesis pod runs as (default unless you set one; on EKS, create one so it can carry an IRSA role).

In-pod coding agent workspaces

One workspace pod per user, running Claude Code, that the user attaches a terminal to. cliTerminal.enabled is the single switch: it creates the cluster objects and turns the feature on in Genesis.
Each active user’s workspace reserves 500m CPU and 4Gi of memory (bursting to 8Gi), and every user who has ever attached keeps two 10Gi volumes that are never reclaimed automatically. At the default caps that is up to 12.5 CPU and 100Gi of memory reserved, and up to 1000Gi of disk, on top of Genesis’s own request. Lower cliTerminal.maxWorkspaces to what your cluster can hold: if it cannot schedule a workspace, attaching fails.
cliTerminal.quota was replaced by cliTerminal.maxWorkspaces and cliTerminal.maxLifetimeUsers. With cliTerminal.enabled true, a values file that still sets it fails to render.

Software Factory coding sandbox

Optional development tooling for Genesis Software Factory. Not needed for a standard install; leave it off unless you are configuring Software Factory. One release owns one coding namespace.

Service account and scheduling

Resources and storage

Vertical Pod Autoscaler

Genesis runs as a single pod, so it cannot scale horizontally. A Vertical Pod Autoscaler can right-size its requests instead. It needs the VPA controller installed in the cluster.

Service and ingress

Health probes and shutdown

Each probe takes the standard Kubernetes probe fields, so you can replace any of them.

Restoring a state snapshot

Restores a state snapshot into the data volume before Genesis first starts: the way to move an install from Snowflake, another cluster or a backup. See State Snapshots and Migration.

Corporate CA certificates

Fetches CA certificates from AWS Secrets Manager or Google Secret Manager when the pod starts and adds them to the container’s trust store, so Python, curl, Git and Node.js all trust them. The pod needs IRSA or Workload Identity credentials.

Extending the pod and the release