CF Runtime
CAP Recommended
MTA
PaaS

Cloud Foundry Runtime

SAP BTP's managed PaaS environment — the recommended runtime for CAP applications, SAPUI5 apps, and microservices with automatic buildpack detection, autoscaling, and SAP HANA integration.

Cloud Foundry Runtime Architecture
Rendering diagram…

Executive Summary

Cloud Foundry (CF) Runtime is SAP's managed PaaS offering on BTP. It uses Diego architecture to schedule and run application containers based on buildpacks (Node.js, Java, Python, etc.). CF is the primary runtime for CAP (Cloud Application Programming Model) applications and remains the most mature runtime on BTP.

Key concepts: Org → Space → Application → Service Binding. Each BTP subaccount maps to one CF organisation. Spaces provide environment isolation (DEV/TEST/PROD). Applications are containers managed by buildpacks. Service Bindings inject credentials via VCAP_SERVICES.

CF Architecture Concepts

CF OrganisationOne per BTP subaccount. Contains all CF spaces and shared quotas. The top-level namespace for CF resources.
CF SpacesIsolated environments within an org. Recommended: DEV, TEST, PROD spaces. Each space has independent service instances and apps.
BuildpacksAuto-detected from package.json / pom.xml. SAP provides custom buildpacks for CAP Node.js and CAP Java. Buildpacks compile source into runnable containers.
CF App AutoscalerScale based on CPU/memory/throughput rules. Define min/max instances and triggers in the Autoscaler service configuration.
MTA (MultiTarget Application)SAP's deployment descriptor format. A single mta.yaml orchestrates multi-module apps: frontend, backend, and all service resources.
Service MarketplaceAccess BTP services as CF services: Connectivity, HANA Cloud, XSUAA, Destination, SAP AI Core, etc. All services injected via VCAP_SERVICES.
CF CLIcf push, cf scale, cf env, cf logs --recent. The primary operator tool for CF management. Use cf deploy (MTA plugin) for MTA deployments.
Memory QuotasConfigurable per space. CAP Node.js typically 256MB–512MB per instance. CAP Java typically 512MB–1024MB. Always profile before setting limits.

MTA Deployment Descriptor

Always use MTA for production
MTA descriptors are the only supported mechanism for reproducible, CI/CD-friendly deployments on CF. The mbt build command produces a versioned .mtar archive that can be promoted across environments.
mta.yaml
1# mta.yaml — MultiTarget Application descriptor for CAP app on CF
2ID: dewa-s4-extension
3version: 1.0.0
4_schema-version: 3.3.0
5
6modules:
7  - name: dewa-s4-ext-srv
8    type: nodejs
9    path: gen/srv
10    requires:
11      - name: dewa-hana
12      - name: dewa-xsuaa
13      - name: dewa-destination
14    parameters:
15      memory: 512M
16      disk-quota: 512M
17    build-parameters:
18      builder: npm
19      build-result: .
20
21  - name: dewa-s4-ext-app
22    type: approuter.nodejs
23    path: app/router
24    requires:
25      - name: dewa-xsuaa
26      - name: dewa-s4-ext-srv
27        group: destinations
28        properties:
29          name: srv-api
30          url: ~{srv-url}
31          forwardAuthToken: true
32    parameters:
33      memory: 128M
34
35resources:
36  - name: dewa-hana
37    type: org.cloudfoundry.managed-service
38    parameters:
39      service: hana
40      service-plan: hana-cloud
41
42  - name: dewa-xsuaa
43    type: org.cloudfoundry.managed-service
44    parameters:
45      service: xsuaa
46      service-plan: application
47      path: ./xs-security.json
48
49  - name: dewa-destination
50    type: org.cloudfoundry.managed-service
51    parameters:
52      service: destination
53      service-plan: lite

CF Deploy Commands

deploy.sh
1# Build MTA archive
2mbt build -p cf
3
4# Deploy to BTP Cloud Foundry
5cf login -a https://api.cf.ae1.hana.ondemand.com  # ae1 = UAE region
6cf deploy mta_archives/dewa-s4-extension_1.0.0.mtar
7
8# Scale app instances
9cf scale dewa-s4-ext-srv -i 3
10
11# Check app status
12cf apps
13cf logs dewa-s4-ext-srv --recent

Enterprise Example: DEWA S/4HANA Extension Platform

DEWA Production Configuration
DEWA uses CF Runtime for their SAP S/4HANA extension platform. 3 CF Spaces (DEV/TEST/PROD) within one org in the ae1 (UAE) region. CAP Node.js backend + SAPUI5 Fiori frontend, connected to on-premise S/4HANA 2023 via Cloud Connector. HANA Cloud HDI container for extension data. 2 app instances in PROD with CF Autoscaler configured to scale to 5 instances under peak load.

Best Practices

Use MTA descriptors for all CF deployments

Never use manual cf push in production — MTA ensures reproducible, versioned deployments with proper dependency ordering.

Separate CF spaces per environment

Maintain DEV/TEST/PROD spaces within the same org to isolate workloads and prevent accidental cross-environment access.

Configure CF App Autoscaler

Set up autoscaling rules based on CPU/memory/throughput for production apps to handle variable load without manual intervention.

Use HTTP health-check-type

Set health-check-type to http with a specific endpoint (not process) for accurate liveness detection by the Diego scheduler.

CF App Manifest for local dev, MTA for CI/CD

Use manifest.yml for local cf push during development; reserve MTA deployments for automated pipelines.

Integrate Cloud Logging service

Bind the SAP Cloud Logging service to all CF apps to centralise log aggregation for observability and compliance.

Common Pitfalls

Deploying without MTA
Manual cf push produces un-reproducible deployments — service bindings and configurations drift over time.
Using default memory limits
256MB is often too low for CAP Java apps; baseline at 512MB and profile before reducing.
No zero-downtime deployment
Production deployments without blue-green strategy cause brief downtime and user-facing errors.
Missing XSUAA scope checks in CF spaces
CF Space Developer access allows deploy but should not imply app-level admin — separate CF roles from app scopes.
Using cf push with --no-start then manual config
Post-start manual configuration breaks Infrastructure-as-Code — all config must live in MTA or manifest.

Security Considerations

Apply CF space-level roles carefully: Space Developer (deploy apps), Space Manager (configure space quotas), and Space Auditor (read-only access). Never grant Org Manager to individual developers. Use XSUAA as the authentication layer for all CF apps — CF does not provide application-level auth. Enable audit logging via the Audit Log service and integrate with your SIEM.