SAP BTP Runtimes — Cloud Foundry, ABAP and Kyma Compared

I’ve sat in scoping calls where a team spent three weeks arguing over which Node.js framework to use on Cloud Foundry — before anyone had confirmed the project needed Cloud Foundry at all. That question gets skipped more often than it should.

SAP BTP gives you three runtimes to build on: Cloud Foundry, the ABAP Environment and Kyma. Pick one and you shape everything that follows — who can build it, how it scales, and how much of what you already own you get to reuse.

This is the comparison I wish someone had handed me the first time I had to make that call. No vendor language, no fence-sitting. What each runtime actually is, where two of them genuinely compete for the same project, and where the decision was never really a decision at all.

🔗 This post builds on SAP BTP — The Platform Explained , which covers what BTP is at a platform level. If you haven’t set up a BTP account yet, Getting Started with SAP BTP — A Hands-On Guide walks through that first.

What “environment” actually means on SAP BTP

An environment in SAP BTP is a runtime plus its tooling, chosen at subaccount level. You are not picking a feature. You are picking the platform your code will live inside — the languages available, how it scales, how it fails, and who on your team can maintain it.

There used to be a fourth option — Neo, SAP’s original proprietary cloud stack, offered since 2012. SAP confirmed Neo will sunset on 31 December 2028, subject to existing contract terms. The multi-cloud foundation — Cloud Foundry, ABAP Environment and Kyma — has been the default for new BTP customers since 2020, and it’s the only sensible starting point for anything new in 2026.

📝 Note

Environments live at subaccount level, not account level. One global account can run Cloud Foundry in one subaccount and ABAP Environment in another. You are never locked into a single choice for the whole landscape.

Cloud Foundry — the default for cloud-native apps

Cloud Foundry is the runtime most people mean when they say ‘we’re building on BTP.’ It’s an open-source platform-as-a-service managed by the Cloud Foundry Foundation, and SAP runs a managed version of it as one of BTP’s three multi-cloud runtimes.

You push code, Cloud Foundry wraps it in a container using a buildpack, and it runs. Official buildpacks cover Java, Node.js, Python, Ruby, Go and PHP, with community and SAP-maintained buildpacks on top. If your team already writes in one of these, there is close to zero ramp-up.

The SAP Cloud Application Programming Model — CAP — is built to run here. It’s the fastest path from zero to a working OData or GraphQL service backed by HANA, and I’ve used it as the default starting point for new BTP projects for years.

💡 Practical Tip

If you’re extending an SAP system but the extension doesn’t need tight coupling to SAP data or transactions, build it in Cloud Foundry with CAP, not in ABAP. You get a bigger hiring pool and faster iteration, and CAP still talks to your SAP backend cleanly through its service layer.

ABAP Environment — extending SAP with ABAP Cloud

SAP BTP’s ABAP Environment launched in 2018. Developers nicknamed it Steampunk — an internal SAP project name that stuck — and you’ll still hear both terms used interchangeably in the wild.

In November 2022, SAP folded it into a broader strategic term: ABAP Cloud. That name now covers both the BTP ABAP Environment and Embedded Steampunk inside S/4HANA itself. The functionality barely changed — the point was giving one name to ‘modern, cloud-ready ABAP development,’ wherever it runs.

This is not the ABAP most consultants grew up with.

ABAP Cloud enforces a restricted language version called ABAP for Cloud Development. No CALL SCREEN, no classic Dynpro, no SAP GUI.

You build with RAP — the ABAP RESTful Application Programming Model — and the only supported UI is Fiori.

⚠️ Warning

Don’t sell ABAP Environment to a client as ‘the same ABAP, just in the cloud.’ It genuinely isn’t. Teams that expect to lift-and-shift old-style reports and screens hit a wall fast, and that expectation gap causes more project friction than the technology itself.

Where it wins: you already have ABAP developers, and the extension needs proximity to SAP data, transactions or apps — the kind of coupling that keeps you inside the Clean Core principle instead of reaching around it. For SAP S/4HANA Cloud Public Edition specifically, ABAP Cloud is the supported way to build extensions that need that level of coupling.

Kyma — Kubernetes for event-driven and containerised work

Kyma is SAP’s fully managed Kubernetes runtime, built on the open-source Kyma project. Where Cloud Foundry hands you a buildpack and hides the infrastructure, Kyma hands you Kubernetes — containers, serverless functions, event triggers, the whole toolkit — and expects you to know what you’re doing with it.

It runs any language you can put in a container, which is broader than Cloud Foundry’s buildpack list. It supports autoscaling and self-healing out of the box, the same as Cloud Foundry, but with more configuration surface underneath.

That power comes with a cost.

Kyma needs a team comfortable with Kubernetes concepts — pods, deployments, ingress, secrets.

I wouldn’t hand it to a team whose only cloud experience is deploying a CAP app to Cloud Foundry. Give them time with Kubernetes first, or bring in someone who already has the scars.

📌 Key Takeaway

Kyma is best for event-driven and containerised workloads that genuinely need Kubernetes-level control — not a more powerful version of Cloud Foundry to reach for by default.

The real decision — how these three actually compete

Here’s the part most comparisons get wrong: these three runtimes don’t compete with each other in a three-way fight. Two of them do, and the third mostly doesn’t.

Cloud Foundry and ABAP Environment genuinely compete when you’re extending an SAP system and the extension could reasonably go either way — build it loosely coupled in Cloud Foundry with CAP, or build it tightly coupled in ABAP Cloud with RAP. That’s a real decision with real trade-offs, and it’s the one worth spending a workshop on.

Kyma rarely competes with either. SAP’s own documentation is explicit about this: if you need ABAP, you choose ABAP Environment, full stop — Kyma was never part of that conversation. And Kyma versus Cloud Foundry is less a rivalry than a question of whether your workload genuinely needs Kubernetes-level control, or is happy inside a buildpack.

Factor	Cloud Foundry	ABAP Environment	Kyma
Best for	Polyglot cloud-native apps, CAP services	Extensions needing tight SAP data or transaction coupling	Event-driven, containerised, Kubernetes-native workloads
Skillset needed	Java, Node.js, Python or similar — CAP developers	ABAP Cloud (RAP, CDS) — a restricted language version	Kubernetes, containers, any container-friendly language
Isolation	Per-app container isolation	Shared resources, closer to classic Netweaver behaviour	Per-app container isolation, pod-level control
Scaling	Automatic, horizontal and vertical	Vertical, managed by SAP within the system’s sizing	Automatic, the most granular of the three
Operational complexity	Low — SAP manages the platform	Low — SAP manages the platform	Higher — Kubernetes concepts required

If you take one thing from this table: isolation is the sleeper issue. In ABAP Environment, apps share resources the way they always did on classic ABAP Netweaver — one runaway job can affect others on the same system. Cloud Foundry and Kyma isolate each app in its own container, so one crashing app doesn’t take its neighbours down.

Can you mix runtimes?

Yes, and most real landscapes do. Environments are chosen at subaccount level, not account level, so nothing stops you running Cloud Foundry in one subaccount and ABAP Environment in another under the same global account.

In practice I’ve seen this pattern constantly: ABAP Environment for the extensions that need real proximity to SAP data, Cloud Foundry for everything else, and Kyma brought in later once an event-driven or Kubernetes-shaped requirement actually shows up. Nobody picks one runtime on day one and never touches the others.

At a glance — SAP BTP runtimes

Concept	One-line summary
Environment (SAP BTP)	The runtime plus tooling you choose at subaccount level to build and run applications
Multi-cloud foundation	The default BTP foundation since 2020 — Cloud Foundry, ABAP Environment and Kyma
Neo	SAP’s original proprietary environment — sunsetting 31 December 2028
Cloud Foundry	Open-source, buildpack-based PaaS — the default for polyglot cloud-native apps and CAP
ABAP Cloud	The strategic umbrella term (since November 2022) for modern, restricted ABAP development
ABAP Environment (Steampunk)	BTP’s ABAP runtime — best when you need tight coupling to SAP data and already have ABAP skills
RAP	The ABAP RESTful Application Programming Model — how you build Fiori apps in ABAP Environment
Kyma	Fully managed Kubernetes runtime — best for event-driven, containerised workloads needing real control
Isolation	Cloud Foundry and Kyma isolate apps per container; ABAP Environment shares resources like classic Netweaver
Mixing runtimes	Chosen at subaccount level — most real landscapes run more than one

What to take away

The runtime question isn’t really a technology decision. It’s a people and architecture decision wearing a technology costume. Ask what your team already knows, and ask how tightly the thing you’re building needs to sit next to SAP data — those two answers decide more than any feature comparison table ever will.

Cloud Foundry will keep being the default, because most extensions don’t need ABAP’s proximity or Kyma’s control. ABAP Environment earns its place when the coupling is real. Kyma earns its place when Kubernetes is genuinely the requirement, not just the interesting option in the room.

🔗 Related posts on this site

SAP BTP — The Platform Explained — the foundational post this one builds on.

SAP CAP — The Framework Behind Modern BTP Development — the framework that makes Cloud Foundry the fast path for new SAP extensions.

ABAP RAP — What It Is, What It Replaces, and Why It Matters — the programming model behind everything you build in ABAP Environment.

CDS Views and the VDM in SAP S/4HANA Explained — the data modelling layer both RAP and CAP depend on.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/sap-btp-runtimes-cloud-foundry-abap-and-kyma-compared/