Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
With the latest CAP major release 6 for cds and cds-dk, you can deploy your CAP application on the Kyma Runtime of SAP Business Technology Platform (SAP BTP). The Kyma Runtime is the SAP-managed offering for the Kubernetes based Kyma cloud-native application runtime.


For the first release of CAP on Kyma, our goal was to support “extension” projects:

  • Single-tenant CAP service (Node.js / Java)

  • SAP HANA database

  • SAP Fiori elements or SAPUI5 freestyle UIs

  • Authentication based on XSUAA

  • Connectivity to cloud and on-premise systems

As usual, we went beyond the pure technical enablement: we wanted to make it as easy as possible for you to get your application on the Kyma Runtime.

But let’s start with the technical enablement, the runtime stuff.

Runtime Needs

The runtime support was not a big deal. As CAP applications run on your local machine and on Cloud Foundry, why shouldn’t it be possible to run them in another environment like Kyma? There must be a Node.js or Java execution environment for sure. But this is easy to achieve with containers. Differences are in the interaction between platform and applications.

An important aspect is how applications get access to external services, such as the SAP BTP services.

In the environment variable VCAP_SERVICES, Cloud Foundry provides service bindings as JSON to applications. This mechanism exists neither in Kubernetes nor in Kyma. Service credentials are stored in secrets and can be injected into environment variables or into the file system of an application.

We thought that it would be good to have something that might allow interoperation with non-SAP BTP services as well. Ideally, an open standard. We’ve chosen, which is closest. Read more about it in the blog post The new way to consume Service Bindings on Kyma Runtime.


Once we had ensured that CAP runs and could access SAP BTP services, we started looking for a good deployment experience. Deployment on Kyma - and on Kubernetes in general - includes the following tasks:

  1. Build container images for your application

  2. Push container images to a container registry

  3. Apply Kubernetes resources for your application (using the pushed container images)


(Source: CAP documentation → Deploy to Kyma/K8s)


Containerize Your Application

SAP recommends Cloud Native Buildpacks, such as provided by the Paketo Buildpacks to build container images. You might wonder if this really is the way to do it, everyone seems to use Dockerfiles. That’s true, but buildpacks have some convincing benefits that make your life easier.

As a prerequisite, you need to install the docker (or docker compatible) and the pack tools.

You can create a container image for your service with a pack command like this:

pack build $CONTAINER_REGISTRY/cpapp-srv --path gen/srv \
--buildpack \
--builder paketobuildpacks/builder:base

No Dockerfile needed!

The buildpack approach was already followed by Heroku and Cloud Foundry, but things are done in a different place:

  • Cloud Foundry: cf push uploads your application files to the staging service within the Cloud Foundry cluster. The staging service builds the container image and stores it in Cloud Foundry’s built-in registry.

  • On the Kyma Runtime, this process happens out-of-cluster. First, you build the container image and second, you upload it to some container registry. Unfortunately, SAP has no such offering.

You have the choice between various cloud and self-hosted container registry offerings available. You just need to make sure it is secure and reliably accessible from the Kyma cluster.

Play the Kubernetes API

Everything that runs or happens on Kubernetes is described with resource files. They are formatted as YAML files, but JSON is possible as well.



apiVersion: v1
kind: Pod
name: busybox
- name: busybox
image: busybox
- sleep
- "3600"

Kubernetes kubectl command line lets you bring this resource into your cluster:

kubectl apply -f busybox-pod.yaml

Under the hood, this sends a request to the Kubernetes API that checks the resource and activates it in the cluster. An operator watching for changes picks it up and brings it to live.

With the Pod resource, you run a single container image that executes the waits for an hour and terminates after that.

The image is downloaded from the specified container registry. By default, Docker Hub is used if no registry is specified. In this example, only the image name busybox is provided.

So, once your service’s container image is available in the container registry, you can apply the resource files for your application.

There are different ways to structure and apply resource files. Our choice is Helm.

The CAP Helm Chart

Helm allowed us to create a set of reusable and configurable deployment files for CAP applications. See section Customize Helm chart in the CAP documentation for more details. With the CAP tooling installed, you can add the Helm chart to your project by just running cds add helm.

The Helm chart contains all the required Kubernetes resources for deploying your application, SAP HANA database content and HTML5 applications, as well as creating instances of SAP BTP services and consuming them.

You can even update the Helm chart later with another run of cds add helm.

The configuration of the Helm chart is stored in the chart/values.yaml file. cds add helm creates this file with defaults based on your CAP project’s configuration. The content is similarly structured like an mta.yaml file.

Let’s have a brief look at the Kubernetes resources provided by the Helm chart:

Your service gets into action using a Kubernetes Deployment resource. This resource supports having multiple instances of the same service and has zero-downtime upgrade built-in. The SAP HANA and HTML5 deployments are done using Jobs. Don’t search for them after successfully installing the Helm chart. They get cleaned-up if everything worked well.

Using SAP BTP Services

You might wonder how to create SAP BTP service instances from Kyma. Let me take you to a short journey to the past: In former times, the SAP BTP services were registered in the Service Broker of Cloud Foundry landscapes. But SAP has already freed the services from the Cloud Foundry chains. Nowadays, services are registered in the SAP Service Manager that isn’t limited to Cloud Foundry. You can connect a Kyma Runtime - or in general any Kubernetes - cluster with an SAP BTP subaccount. The SAP BTP Service Operator in your Kyma cluster does the connection to the SAP Service Manager. It is automatically installed and configured by enabling the Kyma Runtime.

The SAP BTP Service Operator has custom resource definitions for creating service instances and service bindings. Service bindings create secrets that are injected into the applications’ pods. I’ve already explained that.


kind: ServiceInstance
name: cpapp-xsuaa
serviceOfferingName: xsuaa
servicePlanName: application

kind: ServiceBinding
name: cpapp-srv-auth
serviceInstanceName: cpapp-xsuaa

This creates a secret containing the credentials in the cluster:

kubectl get secrets

NAME            TYPE
cpapp-srv-auth Opaque

The CAP Helm chart lets you configure your required services without the need to write these files.

But even without deploying your application, you can test with those Kubernetes provisioned SAP BTP services. As you can do for Cloud Foundry, you can connect your local application to them using cds bind. Just add the --on k8s option.

For example:

cds bind --to cpapp-srv-auth --on k8s

Now, you can run your application with the real XSUAA instance. For example, with CAP Node.js:

cds watch --profile hybrid

Why Kyma Runtime?

So, that’s all nice and good, but why should I bother about Kyma Runtime?

Kubernetes is a mature cloud platform with convincing concepts and functionality built-in. But even more important, it is the de-facto industry standard for running containerized workloads. It has a huge and vibrant ecosystem.

The Kyma Project adds service mesh, serverless, eventing, and observability functionality on top of it by using established open source technology.

SAP provides you with a managed offering of all of that embedded in the SAP BTP. You just need to click on Enable ;-).

Added Value on Top of Kubernetes: The Service Mesh

Services meshes are good examples how Kubernetes extensions can add value. Istio is a service mesh that builds on Kubernetes and is included in Kyma. It’s a programmable, secure network within your Kubernetes cluster.

For example, you can use it to secure the communication between services. Let’s say you have a shopping application, which consists of a Bookshop and an Order service, and you want to ensure that the Order service can only be called from Bookshop. With Istio that’s possible with some configuration - you guess it: resource YAML files. No programming required!

The Bookshop just calls http://order/.. Istio injects sidecar containers that run side-by-side with your applications’ containers, and take over the external communication for them. By that, the HTTP request from Order is sent through a mTLS tunnel and for the Order service it ensures that it accepts only requests from Bookshop. Istio generates and distributes the required certificates automatically. You don’t need to care for that.

Try it Yourself

You can learn how to deploy a CAP application with the Deploy Your CAP Application on SAP BTP Kyma Runtime tutorials, which are part of the SAP BTP end-to-end tutorial series.

If you’re new to CAP, you should create the tutorial application from scratch with the Build an Application End-to-End Using CAP, Node.js and VS Code tutorial mission:

  1. Prepare Your Development Environment for CAP

  2. Create a CAP Application and SAP Fiori UI

Alternatively, you can start with the prepared application from the cap-roles branch of the tutorial’s examples repository.

Learn More

You will find more information in the new Deploy to Kyma/K8s guide as part of the revamped Deployment Cookbook in the official CAP documentation “capire”.


Further, CAP samples have been extended for Kyma deployment:

The End

That’s it. I hope you’ve enjoyed reading this blog. I’m looking forward to hearing from you about your first hands-on experience with CAP on the Kyma Runtime.
Active Contributor
0 Kudos
Hi Uwe,

thank you for this blog post.

You stated that currently only single tenant apps are possible. Will and if yes when will multitenancy be possible? 

Regards Helmut
Hi Helmut,

You can build multi tenancy applications on Kyma Runtime. It works the same way like it works for CF. See the CAP Multi tenancy Cookbook for general CAP multi tenancy documentation.

However, we do not yet have support in our Helm chart. That means you need to add the required Kubernetes resources, such as the SaaS registry and the Service Manager instance, yourself. You can just put them into the chart folder along with the templates provided by "cds add helm". We consider to add it with one of our next relases.

One important remark wrt. Service Manager. You need to create the Service Manager "container" instance in CF. Otherwise you won't be able to create HDI container instances.

There are a few resources on multi tenancy on Kyma available. For example:

I haven't reviewed them, but I would assume that they provide good guidance.

Best regards,

Active Contributor
Hi Uwe,

thanks for the valueable answer. Good to know that there is already a solution and you work on further simplicity.

Best regards
Active Contributor
Hi Uwe,

In the context of this blog post, does it mean SAP is moving away from Cloud Foundry in general and specifically for CAP?  Does SAP intend to stop support for applications deployed to BTP Cloud Foundry in future?



Hello Mustafa,

Thanks for this great question. We are not moving away from Cloud Foundry and do not stop support for applications deployed to SAP BTP, Cloud Foundry runtime.

As we evolve Kyma as a K8s-based runtime along our unified runtime strategy, it is of equal importance to support CAP on Kyma as a first-class citizen in multi-cloud.

The Cloud Foundry runtime and the Cloud Foundry based services will not go away. The Cloud Foundry based services are planned to be made consumable in Kyma as well, so that customers have full flexibility.

Best regards,

0 Kudos
Hi Uwe,


Thanks for your content.

Could you please share the advantages of CAP on Kyma against CAP on CF Runtime ?


Best Regards
0 Kudos
Hi Jungwoo,

The advantage of running CAP on Kyma is that you can make use of all the Kyma und Kubernetes functionalities and its ecosystem. I gave Istio as an example in the article.

A good platform choice depends on the project's needs and also on its scale.

Best regards,
0 Kudos
Very useful blog Uwe! Thanks for sharing this with community.
0 Kudos

Hi Uwe,


How can we access tables and other hana objects which are part of a different HDI container in Kyma? In CF we could just add a connection in the mta.yaml file but how to do the same in Kyma?



0 Kudos

Hi Gaurav,

You can create additional service bindings to your HDI containers.But because HANA Cloud doesn't yet support Kyma and Kubernetes, you need to create a secret with the credentials of the HDI container for each of them.

The secret needs to service binding metadata with which you can access it in your CAP application. See example script to create the secret.

In the Helm chart (values.yaml), just add the additional bindings.

For example:

fromSecret: cpapp-db
fromSecret: cpapp-db-container-2


Best regards,