Reference configurations

Two named configurations rather than a blank values file. Each ships in the install kit, so you can read it before you use it.

Configuration	For	Redundancy	Storage
Single node	Evaluation, training, upgrade rehearsal	None	Smallest
Production	Anything you depend on	Full	Smallest production grade

Single node

Not for production. Everything at one replica on one node. Losing the node loses the data.

Ships as three overlays in the kit:

$KIT/examples/single-node/infra-values.yaml
$KIT/examples/single-node/data-values.yaml
$KIT/examples/single-node/platform-values.yaml

Layer each one after the production values file, so it wins. Full procedure: Quickstart.

	Production	Single node
Object store	3 replicas, erasure coded, StatefulSet	1 replica, standalone, Deployment
Postgres	3 instances, pooler on	1 instance, pooler off
Kafka	3 brokers, replication factor 3	1 broker, every factor 1
Services	2 or 3 replicas	1 each
StorageClass	Yours	local-path, the k3s default

Production

The default. values-onprem.yaml in the bundle is the production configuration, so there is no overlay to apply: what you install in Install is this.

What you set yourself:

# gen0sec-infra
rustfs:
  storageclass:
    name: your-block-storage-class

# gen0sec-data
postgres:
  volume:
    storageClass: your-block-storage-class
kafka:
  storage:
    class: your-block-storage-class

For requirements see Sizing.

Extending retention

The shipped sizes are deliberately modest, so growing is the normal direction. Which key you grow depends on what you are retaining. See Sizing storage for your retention.

eg.

# gen0sec-data
postgres:
  volume:
    size: 200Gi
    storageClass: your-block-storage-class
kafka:
  storage:
    size: 200Gi
    class: your-block-storage-class

# gen0sec-infra
rustfs:
  storageclass:
    name: your-block-storage-class
    dataStorageSize: 100Gi

You can also grow later

Volume expansion grows a volume if your StorageClass has allowVolumeExpansion: true. Starting at the defaults and expanding when you need to is a reasonable plan, and it is the direction that works: nothing shrinks a volume.

Publishing endpoints

Independent of the three above, and needed by all of them:

$KIT/examples/single-entrypoint/ingress-values.yaml

One address for the dashboard and every agent-facing API, routed by path prefix. See Publish the endpoints.

Keeping your overrides

Put them in a file under version control, not in --set arguments.

helm upgrade g0s $B/charts/gen0sec-platform-*.tgz -n gen0sec \
  -f $B/values/gen0sec-platform-values-onprem.yaml \
  -f my-site/platform.yaml \
  --set global.imageTag=$VERSION \
  --timeout 20m

helm upgrade uses only what you pass it. Anything set with --set on a previous install and omitted now reverts to the chart default, silently. A file makes that impossible to forget.

Two things that are awkward to keep in a file, because they are per-release or per-secret:

Keep as --set	Why
global.imageTag	Changes every release
downloadProxy.apiKeySecret.name	Or put it in your file. Just never omit it. See Data relay

What the kit contains

ls $KIT/examples/*/

Everything under examples/ is a starting point you are meant to read and edit, not a black box. Each file carries comments explaining which values are yours to set.