Last modified October 14, 2026

Customizing default apps

Every workload cluster has a set of apps installed automatically at creation time, called default apps. Default apps are defined in the cluster chart and provider-specific charts (like cluster-aws). These include essential applications like CoreDNS, Cilium, and cloud provider integrations.

While the default configuration works for most cases, sometimes customization is needed. This guide explains how to customize default apps using the cluster chart values.

App deployment mechanism

Since cluster chart v8.0.0, all default apps are deployed as HelmRelease resources, handled by Flux CD’s Helm controller. Older cluster chart versions deploy some default apps as Giant Swarm App resources. For those, use the App CR notes in the extraConfigs section below.

Understanding app keys

Each default app has a configKey that identifies it in the values structure. You customize apps under global.apps.<configKey>.

List of default apps

These apps are deployed on all clusters regardless of the infrastructure provider:

AWS provider apps

These apps are specific to clusters running on AWS:

Azure provider apps

These apps are specific to clusters running on Azure:

vSphere provider apps

These apps are specific to clusters running on vSphere:

VMware Cloud Director provider apps

These apps are specific to clusters running on VMware Cloud Director:

For a complete and up-to-date list, check the values.schema.json in your provider’s cluster chart.

Find out what configuration can be changed

To find available configuration options for each app, refer to the app’s default values file in its GitHub repository.

For example, for CoreDNS, check helm/coredns-app/values.yaml.

If you can’t find the values file for an app, reach out to your account engineer.

Method 1: Inline values

Pass Helm values directly in your cluster values file under global.apps.<configKey>.values:

global:
  apps:
    coreDns:
      values:
        coredns:
          public:
            cache:
              success:
                ttl: 15

This example reduces the CoreDNS cache lifetime for external answers from the default 30 seconds to 15 seconds. CoreDNS configures cache per zone, so see advanced CoreDNS configuration for the full interface.

The zone-aware coredns.* keys need coredns-app 1.31.0 or newer. Older versions accept them and then ignore them, so check the app version on your cluster first.

Method 2: External ConfigMaps or Secrets

For larger configurations or when sharing settings across clusters, reference external ConfigMaps or Secrets using global.apps.<configKey>.extraConfigs:

global:
  apps:
    awsEbsCsiDriver:
      extraConfigs:
        - kind: ConfigMap
          name: my-ebs-custom-values
          optional: false

The referenced resource must:

• Exist in the same namespace as the cluster
• Have values under a key named values

For HelmRelease-based Apps

The extraConfigs field uses:

• kind: ConfigMap or Secret (PascalCase)
• optional: boolean - if true, missing resources are ignored
• priority: integer (1-150, default 25) - higher priority values override lower ones

The cluster chart turns extraConfigs into the HelmRelease’s valuesFrom list, sorted by priority. Entries sort lowest priority first, so the later entry wins, and ConfigMaps always come before Secrets, so a Secret overrides a ConfigMap whatever the priority.

For App CR-based Apps

On older cluster chart versions that still render App CRs, the extraConfigs field uses:

• kind: configMap or secret (camelCase)
• priority: integer (1-150, default 25) - higher priority values override lower ones

Creating the ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-ebs-custom-values
  namespace: org-myorg
data:
  values: |
    controller:
      resources:
        limits:
          memory: 512Mi
    node:
      tolerateAllTaints: true

Create it with kubectl:

kubectl apply -f my-ebs-custom-values.yaml

Using Secrets for sensitive data

For confidential configuration, use a Secret instead:

global:
  apps:
    certManager:
      extraConfigs:
        - kind: Secret
          name: cert-manager-credentials
          optional: false

Combining both methods

You can use both methods together. Values are merged in this order (later values override earlier):

1. Default provider-independent values (from the chart)
2. Default provider-specific values (from the provider chart)
3. ConfigMaps from extraConfigs with priority of 100 or lower, ordered by priority
4. Inline values
5. ConfigMaps from extraConfigs with priority above 100 (rare, use it to override inline values)
6. Secrets from extraConfigs, ordered by priority (always last, so they override inline values whatever their priority)

global:
  apps:
    awsEbsCsiDriver:
      extraConfigs:
        - kind: ConfigMap
          name: org-wide-ebs-settings
          optional: true
        - kind: Secret
          name: ebs-sensitive-config
          optional: false
      values:
        # These values override the extraConfigs above (default priority 25)
        controller:
          logLevel: debug

Complete example

Here’s a complete cluster values example customizing multiple default apps:

global:
  metadata:
    name: my-cluster
    organization: myorg

  apps:
    # Customize CoreDNS
    coreDns:
      values:
        coredns:
          public:
            cache:
              success:
                ttl: 15

    # Customize Cilium
    cilium:
      values:
        hubble:
          relay:
            enabled: true
          ui:
            enabled: true

    # Customize cert-manager with external config
    certManager:
      extraConfigs:
        - kind: ConfigMap
          name: cert-manager-org-config
          optional: true
      values:
        dns01RecursiveNameserversOnly: true

Troubleshooting

Values not applied: Ensure your config key matches exactly (case-sensitive). For example, use coreDns not coredns.

ConfigMap not found: Verify the ConfigMap or Secret exists in the cluster’s namespace before creating the cluster.

Merge conflicts: Inline values override extraConfigs entries with priority of 100 or lower (default 25), but an extraConfigs entry with a higher priority overrides them. A Secret also overrides any ConfigMap, including the inline values.

Further reading

• cluster chart repository - Provider-independent base chart
• cluster-aws chart repository - AWS provider chart
• cluster-azure chart repository - Azure provider chart
• cluster-vsphere chart repository - vSphere provider chart
• cluster-cloud-director chart repository - VMware Cloud Director provider chart
• App configuration - General app configuration practices