Last modified January 19, 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

Default applications are deployed using two mechanisms:

• App CR - Giant Swarm’s in-house app management
• HelmRelease CR - Flux CD’s Helm controller

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:
        ConfigMap:
          cache: 15

This example reduces the CoreDNS cache lifetime from the default 30 seconds to 15 seconds.

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

For App CR-based Apps

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. Values from extraConfigs (in the order listed)
4. Inline values (highest 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 everything above
        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:
        ConfigMap:
          cache: 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: Remember that inline values always take highest priority over extraConfigs.

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