Last modified August 20, 2026

Cluster configuration

Cluster configuration is managed through the app platform configuration options.

A cluster has three main configuration sources:

• Default, provider-independent app configuration. This comes from the cluster chart. If an app carries this configuration, you should probably move it directly to the app’s own repository.
• Provider-specific app configuration. This comes from cluster-<provider>.
• Customer-specified app configuration. This comes from the cluster-<provider> Helm values. It’s usually specified in the customer’s GitOps repository.

Where the defaults come from

The interface to define a workload cluster is built on top of Helm and the app platform. Creating a cluster means delivering a configured App resource to the platform API.

Those definitions come from the cluster provider Helm template, cluster-aws for example. That chart carries the provider-specific definition, and depends on two more charts:

• cluster holds the basic provider-agnostic definition.
• cluster-shared holds the common resources that every cluster runs by default.

The chain is therefore cluster-<provider> → cluster → cluster-shared, with each link contributing part of what a cluster ends up being.

How the configuration layers merge

Cluster configuration builds on the app platform configuration levels:

• The cluster template provides a default configuration through the App resource’s config field.
• You add custom configuration through the App resource’s extraConfigs field, which is overlaid on top of the default config. Where values collide, the entry with the higher priority prevails.

Note: The RFC on merging configmaps in GitOps explains why we chose this approach.

To apply this with reusable Kustomize bases, see creating a base template for your workload cluster.