The Chart Templates Behind Your CAP Kyma Deployment

When you run cds add kyma on a CAP project, cds-dk generates a Helm umbrella chart whose Chart.yaml declares a list of dependencies. If you've opened that file, you've seen something like this:

apiVersion: v2
name: bookshop
description: A simple CAP project.
type: application
version: 1.0.0
appVersion: 1.0.0
annotations:
  app.kubernetes.io/managed-by: cds-dk/helm
dependencies:
  - name: web-application
    alias: srv
    version: ">0.0.0"
  - name: service-instance
    alias: hana
    version: ">0.0.0"
  - name: content-deployment
    alias: hana-deployer
    version: ">0.0.0"
  - name: service-instance
    alias: xsuaa
    version: ">0.0.0"

A natural question follows: how many of these chart templates exist, and what can I configure in each? This post answers exactly that, based on inspecting the @sap/cds-dk module itself (v10.x), and gives you the full list of knobs with practical examples (as of July 2026).

Series — SAP BTP Kyma Runtime:

1. Preparing Your Environment For SAP BTP Development on Kyma Runtime
2. Deploying Your First CAP Application on SAP BTP Kyma Runtime
3. Creating BTP Service Instances on SAP BTP Kyma Runtime with the Service Operator
4. Binding BTP Service Instances to your CAP Application with Kyma Runtime
5. The Chart Templates Behind Your CAP Kyma Deployment (this post)
6. Creating roles for your CAP Application on SAP BTP Kyma Runtime
7. Using Istio Gateway as Entry Point in SAP BTP Kyma Runtime

Three Chart Templates

Here's the key insight that trips up most developers: no matter how long your dependencies: list is, it is built from only three reusable subcharts (as of July 2026). They ship inside the cds-dk Helm plugin:

@sap/cds-dk/lib/build/plugins/helm/files/subcharts/
├── web-application/       # chart version 2.x
├── service-instance/      # chart version 1.x
└── content-deployment/    # chart version 1.x

Here a description of each, and the typical alias you might see in your umbrella chart's Chart.yaml:

The name field selects the template; the alias field names the instance. That's why the example at the top has four dependencies but only three distinct names — service-instance appears twice, once aliased as hana and once as xsuaa. You can add as many service-instance entries as you have BTP services to provision.

Not subcharts, but worth knowing: the plugin also carries helpers for approuter, connectivity and html5-repo. These inject a ConfigMap into the umbrella chart's own templates/ folder — they are not standalone subcharts. The approuter and html5-apps-deployer workloads themselves still run through the web-application chart.

You configure each subchart from the umbrella chart's values.yaml, keyed by the alias. If you're new to how parent charts pass values down to their children, see Helm for Kubernetes — Managing Dependencies.

# values.yaml (umbrella chart)
srv:            # -> configures the web-application subchart aliased as "srv"
  replicaCount: 2
hana:           # -> configures the service-instance subchart aliased as "hana"
  serviceOfferingName: hana
  servicePlanName: hdi-shared

Now let's break down the knobs for each template.

The "web-application" — Your Runnable Workload

This is the workhorse. It renders a Deployment and a Service, and depending on your values, an APIRule to expose it, an HPA to scale it, RBAC, a NetworkPolicy, and service bindings that mount BTP credentials into the pod.

The Knobs

Example — a scalable, bound CAP service

# values.yaml (umbrella chart)
srv:
  replicaCount: 2
  image:
    repository: my-registry/bookshop-srv
    tag: "1.0.0"
  resources:
    requests:
      cpu: 200m
      memory: 256M
    limits:
      cpu: 500m
      memory: 512M
  hpa:
    enabled: true
    minReplicas: 2
    maxReplicas: 5
  expose:
    enabled: true
    rules:
      - path: /*
        methods: [GET, POST, PUT, PATCH, DELETE]
        noAuth: false          # require auth via the mesh
  bindings:
    hana:
      serviceInstanceName: hana
    xsuaa:
      serviceInstanceName: xsuaa
  health:
    liveness:
      path: /health
    readiness:
      path: /health

The bindings block is the bridge between this workload and your service-instance dependencies: each entry references a serviceInstanceName and mounts its credentials Secret into the pod. See Creating BTP Service Instances on SAP BTP Kyma Runtime with the Service Operator for how those instances are created.

The "service-instance" — Provisioning BTP Services

This chart is the declarative counterpart to cf create-service. It renders a ServiceInstance and (optionally) a ServiceBinding custom resource for the SAP BTP Service Operator to reconcile.

The Knobs

Example — an XSUAA instance with parameters

# values.yaml (umbrella chart)
xsuaa:
  serviceOfferingName: xsuaa
  servicePlanName: application
  parameters:
    xsappname: bookshop
    tenant-mode: dedicated
    role-templates:
      - name: Viewer
        description: View books
  bindings:
    xsuaa:
      credentialsRotationPolicy:
        enabled: true
        rotationFrequency: "720h"    # rotate every 30 days
        rotatedBindingTTL: "24h"     # keep the old binding for 24h

And a minimal HANA instance:

hana:
  serviceOfferingName: hana
  servicePlanName: hdi-shared

The "content-deployment" — One-Off Jobs

Some BTP scenarios need a task that runs once to push content — the classic example being the HANA HDI deployer, which creates tables and loads initial data. This chart renders a Kubernetes Job (plus a ServiceAccount and any bindings the job needs).

The Knobs

Example — a HANA deployer job

# values.yaml (umbrella chart)
hana-deployer:
  image:
    repository: my-registry/bookshop-hana-deployer
    tag: "1.0.0"
  bindings:
    hana:
      serviceInstanceName: hana
  ttlDaysAfterFinished: 7

Putting It All Together

A typical bookshop deployment wires all three templates together — the deployer runs once to set up the database, the service instances provision HANA and XSUAA, and the web-application runs your CAP service bound to both:

# Chart.yaml
dependencies:
  - name: web-application
    alias: srv
    version: ">0.0.0"
  - name: service-instance
    alias: hana
    version: ">0.0.0"
  - name: content-deployment
    alias: hana-deployer
    version: ">0.0.0"
  - name: service-instance
    alias: xsuaa
    version: ">0.0.0"

# values.yaml
srv:
  image: { repository: my-registry/bookshop-srv, tag: "1.0.0" }
  bindings:
    hana: { serviceInstanceName: hana }
    xsuaa: { serviceInstanceName: xsuaa }

hana:
  serviceOfferingName: hana
  servicePlanName: hdi-shared

hana-deployer:
  image: { repository: my-registry/bookshop-hana-deployer, tag: "1.0.0" }
  bindings:
    hana: { serviceInstanceName: hana }

xsuaa:
  serviceOfferingName: xsuaa
  servicePlanName: application

Finding This For Yourself

Everything here came straight from the module. To inspect the shipped subcharts and their default values on your own machine:

# Locate your cds-dk install
CDS=$(npm root -g)/@sap/cds-dk

# List the three subchart templates
ls "$CDS/lib/build/plugins/helm/files/subcharts"

# Read the default values for any of them
cat "$CDS/lib/build/plugins/helm/files/subcharts/web-application/values.yaml"

After cds add kyma and after building the project, the same charts also land in your project's gen/chart/charts/ folder, so you can browse them right next to your code.

Related Reading

• Deploying Your First CAP Application on SAP BTP Kyma Runtime — where the umbrella chart is first generated.
• Creating BTP Service Instances on SAP BTP Kyma Runtime with the Service Operator — the CRs behind the service-instance chart.
• Helm for Kubernetes — Managing Dependencies — how umbrella charts pass values down to subcharts.
• Helm for Kubernetes — Templates and Functions — the Go templating that renders these charts.
• SAP CAP — Deploy to Kyma — the official capire guide for cds add helm.