Cloud Foundry or Kyma: choosing your SAP BTP runtime

Cloud Foundry is the managed-simplicity choice: push buildpacks, let the platform handle provisioning, scaling and most of the operational surface. It is the right default when a team wants to ship extensions without taking on Kubernetes operations, and it covers the large majority of side-by-side extension scenarios we build.

Kyma is SAP's managed Kubernetes offering — the right choice when a team needs container-level control: custom runtimes, sidecars, specific networking or scaling behavior that a buildpack-based model does not expose. It costs more operational attention and buys more control in return.

We rarely treat this as a one-time, landscape-wide decision. Most enterprises run both — Cloud Foundry for the majority of CAP-based extensions and integration flows, Kyma for the handful of workloads that genuinely need Kubernetes-native control, like custom MCP servers with specific runtime dependencies.

The question we ask first is not 'which platform' but 'what does this specific extension actually need operationally' — and we size the runtime decision to that, workload by workload, rather than standardizing on one for reasons of internal simplicity that the workloads themselves don't share.