Build on BTP/BAIP

How to build reusable work for BTP

On BTP the reusable unit is a deployment, a service or a piece of configuration someone else can apply: an MTA, a service broker, a Terraform module, a Kyma module. What follows is how SAP documents each.

Guidance, not rules. Each project's own contributing guide wins. Links read 2026-09-29

01Work with an agent

The skills written for BTP/BAIP teach an agent how to build with it, and the atlas is not part of what they read. The atlas's MCP server and its skill answer a different question, what exists, whether it is alive and where it stops, and carry no procedure for code, so the two sit side by side. It reads; it never opens an issue or a pull request. How the atlas serves agents

Skills indexed in BTP/BAIP

READMEs on record for 20 of 20. None of them names the atlas.

Any MCP client: the endpoint

The atlas over streamable HTTP, stateless, answered from the bundled graph.

claude mcp add --transport http onedevatlas https://onedevatlas.dev/mcp

02How BTP/BAIP is extended

On BTP the reusable unit is a deployment, a service or a piece of configuration: an MTA, a service broker, a Terraform module, a Kyma module. Each has a descriptor the platform reads, and work written against it can be deployed by someone else.

Multitarget application (mta.yaml modules, resources, requires)

Cloud Foundry
mta.yaml

SAP's Cloud Foundry documentation describes an MTA as one application of several parts sharing one lifecycle, modelled as modules, resources (services a module needs at runtime) and dependencies declared with provides and requires. mta.yaml is the development descriptor that says what to build and how; the generated mtad.yaml is the deployment descriptor.

yamlAdapted from github.com ↗
resources:
- name: my-cf-service-instance-resource
  type: org.cloudfoundry.managed-service
  parameters:
    service-plan: "lite"
    service: application-logs

modules:
- name: my-mta-managed-app-module
  type: application
  path: "appBits.zip"
  requires:
    - name: my-cf-service-instance-resource

MTA extension descriptors (.mtaext)

Cloud Foundry
.mtaext

An extension descriptor supplies environment- or deployment-specific data such as scaling and credentials, so one MTA archive deploys with different configurations without being modified. It names the descriptor it extends and is passed at deploy time with cf deploy -e; several can be chained, each taking priority over the one it extends.

yamlAdapted from github.com ↗
_schema-version: '3.1'
ID: sample.app.prod
extends: sample.app

modules:
  - name: my-app
    parameter:
      memory: 4GB
      instances: 2

# cf deploy <mtar> -e prod.mtaext

Service broker declared in an MTA module

Cloud Foundry
create-service-broker

The deploy service can create and update a service broker as part of an MTA deployment when a module sets create-service-broker and the broker parameters; the application must implement the service broker API. SAP's page notes that global registration needs Cloud Foundry admin access, and that space-scoped brokers (service-broker-space-scoped: true) can be registered for test purposes.

yamlAdapted from github.com ↗
- name: jobscheduler-broker
  properties:
    user: ${generated-user}
    password: ${generated-password}
  parameters:
    create-service-broker: true
    service-broker-space-scoped: true
    service-broker-name: jobscheduler
    service-broker-user: ${generated-user}
    service-broker-password: ${generated-password}
    service-broker-url: ${default-url}

Open Service Broker API and SAP Service Manager

Any environment
OSB API /v2/catalog

SAP Service Manager is described as the central registry for service brokers and environments in SAP BTP; it speaks the Open Service Broker API to brokers, which advertise catalogs of offerings and plans and process provision, bind, unbind and deprovision requests. A broker is registered in a subaccount with btp register services/broker or smctl register-broker, and the platform first calls the broker's /v2/catalog endpoint.

jsonAdapted from github.com ↗
{
  "services": [{
    "name": "fake-service",
    "id": "acb56d7c-XXXX-XXXX-XXXX-feb140a59a66",
    "description": "A fake service.",
    "bindable": true,
    "plans": [{
      "name": "fake-plan-1",
      "id": "d3031751-XXXX-XXXX-XXXX-a42377d3320e",
      "free": false
    }]
  }]
}

Destination service

Cloud FoundryKyma
destination (service offering), plan lite

The Destination service holds the information an application needs to reach a remote service or system, manages routing and authentication details and performs the configured authentication flows; for on-premise targets it is used together with the Connectivity service, and on Kubernetes with the Connectivity Proxy and Transparent Proxy. An application consumes it through a service instance and binding, and the documented flow uses a JWT from an xsuaa instance bound with plan application.

Terraform provider for SAP BTP

Any environment
SAP/btp (Terraform registry)

The provider manages SAP BTP resources through Terraform: subaccounts, entitlements, service instances and more. It authenticates with username and password, X.509, a JWT bearer assertion or an existing btp CLI session (USE_BTPCLI_SESSION).

hclAdapted from github.com ↗
# create a subaccount in eu30 region (GCP)
resource "btp_subaccount" "my_project" {
  name      = "My Project"
  subdomain = "my-project"
  region    = "eu30"
}

SAP BTP command line interface (btp CLI)

Any environment
btp

SAP documents the btp CLI as the terminal alternative to the cockpit for account administration: subaccounts, entitlements, environment instances, authorizations, and service brokers and platforms. All commands accept parameters and --format json for scripting.

CLI tools in BTP/BAIP 21
shellAdapted from github.com ↗
btp login
btp create accounts/subaccount --display-name <my-subaccount> --region <my-region> --subdomain <my-subaccount-subdomain>
btp assign accounts/entitlement --to-subaccount <my-subaccount-id> --for-service <my-service> --plan <my-service-plan> --amount <number>
btp create accounts/environment-instance --subaccount <my-subaccount-id> --display-name <my-environment> --environment <cloudfoundry> --plan standard --parameters "{\"instance_name\":\"myOrg\"}"

SAP BTP Operator module (ServiceInstance and ServiceBinding custom resources)

Kyma
services.cloud.sap.com/v1

In Kyma, the SAP BTP Operator module installs the open-source SAP BTP service operator, which provisions SAP BTP service instances and bindings through SAP Service Manager using Kubernetes-native tools. A ServiceBinding produces a Secret in the cluster that carries the credentials.

yamlAdapted from github.com ↗
apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
    name: {SERVICE_INSTANCE_NAME}
    namespace: {NAMESPACE}
spec:
    serviceOfferingName: {SERVICE_OFFERING_NAME}
    servicePlanName: {SERVICE_PLAN_NAME}
    externalName: {SERVICE_INSTANCE_NAME}

Kyma modules and community modules

Kyma
ModuleTemplate (operator.kyma-project.io, v1beta2)

Kyma runtime installs only the modules chosen for a cluster, such as Istio, API Gateway, SAP BTP Operator, Eventing, Serverless or Telemetry, and they can be added or deleted on demand. The kyma-project/community-modules repository holds ModuleTemplate custom resources for modules contributed by the community; its README states these are not subject to the SLA.

Scopes shared between applications (xs-security.json granted-apps)

Cloud Foundry
xs-security.json granted-apps / scope-references

For a business application calling a service in the same subaccount with principal propagation, the service lists the applications that may use a scope under granted-apps, and the calling application references that scope in its role templates. One role then grants access to both applications.

jsonAdapted from github.com ↗
"scopes": [
  {
    "name"         : "$XSAPPNAME.Viewer",
    "description"  : "View log",
    "granted-apps" : ["$XSAPPNAME(application,appa)"]
  }
]

03Tests, checks, types and releases

Each as BTP/BAIP's own documentation describes it, with the pages to read. Where a source recommends something, the recommendation is its own.

Security descriptor and XSUAA

xs-security.jsonSAP Authorization and Trust Management service (xsuaa)

SAP's page explains that an application declares its security in xs-security.json: an xsappname, scopes prefixed with $XSAPPNAME, attributes for instance-based checks, and role templates that administrators turn into roles. For instance-based authorizations the same page recommends SAP Cloud Identity Services Authorization Management.

jsonAdapted from github.com ↗
{
  "xsappname" : "hello-world",
  "scopes"    : [
    { "name" : "$XSAPPNAME.Display", "description" : "display" },
    { "name" : "$XSAPPNAME.Edit",    "description" : "edit" }
  ]
}

Principal propagation versus technical communication

Destination servicexsuaaCloud Connector

SAP's guidance: propagate the user's identity when the called service's action must be auditable or needs to know the user, and use technical (machine-to-machine) communication when it does not, for example a clean-up task. For destinations to the ABAP environment, the page compares communication-user methods (basic, client certificate) with business-user methods (SAML assertion, OAuth 2.0 SAML bearer), and states it prefers certificate-based authentication over passwords.

CI/CD

SAP Continuous Integration and DeliveryProject Piper (SAP/jenkins-library)

The BTP Developer's Guide presents SAP Continuous Integration and Delivery as a service with predefined pipelines for Cloud Foundry (SAP Fiori and CAP), SAP Fiori for the ABAP platform and SAP Integration Suite artifacts, set up without hosting a Jenkins instance. Project "Piper" is SAP's open-source continuous delivery framework: a shared Jenkins library of reusable steps, Docker images and a CLI, configured in .pipeline/config.yml.

yamlAdapted from project-piper.io ↗
general:
  gitSshKeyCredentialsId: GitHub_Test_SSH
steps:
  cloudFoundryDeploy:
    deployTool: 'cf_native'
    cloudFoundry:
      org: 'testOrg'
      space: 'testSpace'
      credentialsId: 'MY_CF_CREDENTIALSID_IN_JENKINS'

Infrastructure as code

Terraform provider for SAP BTPkyma-project/terraform-btp-kyma-environmentTerraform Exporter for SAP BTP

The Developer's Guide lists the Terraform provider for SAP BTP among the platform's tools and, for Kyma, recommends the kyma-project Terraform module inside CI/CD pipelines to create the resources for a Kyma cluster and tear them down when no longer needed. It recommends a technical user, known as a platform user through a custom SAP Cloud Identity Services tenant, for the pipeline.

hclAdapted from github.com ↗
resource "btp_subaccount_entitlement" "alert_notification_service" {
  subaccount_id = "6aa64c2f-38c1-49a9-b2e8-cf9fea769b7f"
  service_name  = "alert-notification"
  plan_name     = "free"
}

Observability

SAP Cloud ALMSAP Cloud LoggingSAP Alert Notification serviceOpenTelemetryKyma Telemetry module

The Developer's Guide splits observability into central observability in SAP Cloud ALM and local observability in tools such as SAP Cloud Logging, with telemetry flowing through OpenTelemetry-based instrumentation. SAP Cloud Logging is described as an OpenSearch-based service for logs, metrics and traces from Cloud Foundry and Kyma, and the SAP Alert Notification service routes alerts to channels.

Security in delivery

SAP Credential StoreSAP Continuous Integration and DeliverySAP Audit Log service

The Developer's Guide lists secure environment configuration, security tests before go-live, CI/CD pipelines with code scanning and dependency validation, and SAP Credential Store for secrets. It recommends that developers deploy application-based security artifacts and administrators assign the authorizations in the cockpit.

Extending SAP solutions

SAP BTP Cloud FoundrySAP BTP Kyma runtime

The Developer's Guide distinguishes in-app extensions, made inside the SAP solution where it allows them, from side-by-side extensions deployed on SAP BTP. It advises starting simple, keeping the digital core focused, and checking that suitable APIs and events exist; automated configuration covers SAP S/4HANA Cloud and SAP SuccessFactors on Cloud Foundry and Kyma, plus further solutions on Kyma.

Reference architectures

SAP Architecture Center

The SAP Architecture Center publishes reference architectures across five domains. Two apply to platform work: DevOps with SAP BTP (SAP Continuous Integration and Delivery, SAP Cloud Transport Management, SAP Cloud ALM, SAP Cloud Logging, SAP Automation Pilot, Terraform) and Multitenant SaaS Application using CAP (tenant model, lifecycle management, authentication strategies).

04Using open source

Taking open source into a project, and publishing your own under an open licence, as BTP/BAIP's projects and documentation describe it. Every artifact in the atlas carries the same readings, maintenance and licence among them, before it goes into a project.

Pinning the Terraform provider for SAP BTP

TerraformTerraform provider for SAP BTP

The provider's own documentation declares it in `required_providers` with the source `SAP/btp` and an exact version. HashiCorp's version-constraint guidance says reusable modules constrain only the minimum versions of Terraform and providers, root modules use `~>` to set a lower and an upper bound per provider, and configurations that depend on third-party modules require specific module versions so updates happen only when convenient.

hclAdapted from github.com ↗
terraform {
  required_providers {
    btp = {
      source  = "SAP/btp"
      version = "1.26.0"
    }
  }
}

provider "btp" {
  globalaccount = "my-global-account-subdomain"
}

The dependency lock file

Terraform

`terraform init` creates or updates `.terraform.lock.hcl` in the root module's directory, and HashiCorp says to include it in version control so changes to external dependencies go through code review. The lock file tracks only provider dependencies: Terraform does not remember version selections for remote modules and picks the newest version that meets the constraints, so an exact module constraint is how to keep the same module version. `terraform init -upgrade` moves providers to newer versions within the constraints.

Community buildpacks on Cloud Foundry

Cloud Foundry buildpacksMultitarget applications

The Cloud Foundry environment ships one recent version of the community `java_buildpack` as a system buildpack, beside the SAP-managed SAP Java Buildpack, and SAP points to the community repository's releases for changes. For Node.js, SAP documents pinning a release of the community `nodejs-buildpack` by its Git URL and tag in `manifest.yml` or in an MTA module's `buildpack` parameter; SAP describes this as a temporary measure and does not recommend deprecated Node.js versions, since they no longer receive security fixes.

yamlAdapted from github.com ↗
modules:
- name: myapp
  type: javascript.nodejs
  parameters:
    buildpack: https://github.com/cloudfoundry/nodejs-buildpack.git#v1.8.34

Kyma runtime and its open-source modules

Kyma

SAP BTP, Kyma runtime is a managed Kubernetes runtime based on the open-source project Kyma, and its capabilities come as modules a user adds or deletes, released first in a fast channel and about two weeks later in the regular channel. The module code is developed in the kyma-project organisation on GitHub, for example the API Gateway module under Apache-2.0. As a managed service, Kyma reverts unexpected modifications to Kyma-managed resources.

Reading a project's licence and maintenance signals

REUSETerraform provider for SAP BTP

The READMEs of terraform-provider-btp and btp-terraform-samples show a REUSE status badge that links to the REUSE API's compliance report for the repository. The provider's README also carries a CodeQL workflow badge and an OpenSSF Best Practices badge, and its `REUSE.toml` states that API calls to SAP or third-party products included in the code are not licensed under the project's open-source licence.

Declaring the licence with REUSE

REUSE

REUSE, started by the Free Software Foundation Europe, asks a project to provide its licences, add copyright and licensing information to each file, and confirm compliance; specification 3.3 lets a `REUSE.toml` file carry that information instead of DEP5, never both. The SAP-owned Terraform repositories do it with a `REUSE.toml` that annotates every path with an SPDX copyright text and the `Apache-2.0` identifier, a `LICENSES` directory, and a REUSE check in the provider's CI workflows.

tomlAdapted from github.com ↗
version = 1
SPDX-PackageName = "terraform-provider-btp"
SPDX-PackageDownloadLocation = "https://github.com/sap/terraform-provider-btp"

[[annotations]]
path = "**"
precedence = "aggregate"
SPDX-FileCopyrightText = "2026 SAP SE or an SAP affiliate company and terraform-provider-btp contributors"
SPDX-License-Identifier = "Apache-2.0"

Contribution terms in SAP repositories

The SAP organisation's contributing guide, repeated in terraform-provider-btp and btp-terraform-samples, asks contributors to comply with the project licence and accept the Developer Certificate of Origin, which is requested automatically on the first pull request and uses the Linux Foundation's standard DCO text. It asks that a major feature be discussed with a maintainer in an issue first, and a separate guideline sets four conditions for AI-generated contributions, among them that the AI tool's terms do not conflict with the project licence and that third-party material in its output is licensed and attributed.

05Security

What BTP/BAIP's documentation and its projects state about security, with the pages to read. A project's SECURITY.md, where it has one, says how to report a vulnerability.

SAP's security guidance for BTP applications

SAP Credential Store

The SAP BTP Developer's Guide recommends that developers configure and deploy application-based security artifacts containing authorizations, and that administrators assign them in the cockpit, with platform roles separating development from administration. Its guidelines for delivery name secure runtime configuration, security testing such as penetration tests before go-live, CI/CD pipelines with code scanning and dependency validation, and SAP Credential Store for secrets like API keys or database credentials. SAP Credential Store keeps passwords, keys and keyrings in namespaces, one per customer, tenant or whatever the application chooses, behind a REST API.

xs-security.json and the XSUAA recommendations

SAP Authorization and Trust Management service (XSUAA)

In `xs-security.json`, `scopes` are the permissions an application checks, `role-templates` group scopes and attributes, and `oauth2-configuration` sets token validity, `redirect-uris` and `credential-types`, whose default is `binding-secret`. SAP recommends `binding-secret` or `x509` so the secret of a single binding can be rotated without affecting the other bindings of the instance. The service's security recommendations for developers add individual secrets per binding (BTP-UAA-0003), `redirect-uris` restricted as much as possible (BTP-UAA-0002) and keeping SAP client libraries updated (BTP-UAA-0021), and for operators, automated deployment to cope with X.509 certificate lifetimes (BTP-UAA-0014).

jsonAdapted from github.com ↗
"role-templates": [ {
    "name": "Viewer",
    "description": "View all books",
    "scope-references": [ "$XSAPPNAME.Display" ]
} ],
"oauth2-configuration": {
    "token-validity": 900,
    "redirect-uris": ["https://myapp.cfapps.eu10.hana.ondemand.com"],
    "credential-types": ["binding-secret","x509"]
}

Principal propagation, technical users and destinations

SAP Destination serviceSAP Connectivity service

SAP's documentation says to use principal propagation when the called service's action must be auditable or needs the user's identity, and technical communication when the user's identity does not matter, such as a clean-up task or checking a queue. An HTTP destination states its authentication type, from principal propagation SSO and OAuth user token exchange to OAuth client credentials, OAuth technical user propagation and client certificates, and its proxy type, Internet, OnPremise through the Cloud Connector, or PrivateLink.

Rotating service keys and bindings

Multitarget applicationsSAP BTP Service Operator

On Cloud Foundry, an MTA can create service keys through the `service-keys` parameter; naming a key with `${timestamp}` makes each deployment create a new key and delete the old one, and `env-var-name` keeps the credentials under a stable environment variable. On Kyma, a `ServiceBinding` of the SAP BTP Service Operator takes a `credentialsRotationPolicy` that rotates on a set frequency and keeps the old credentials in a Secret labelled stale until its TTL ends; the policy does not govern how long the credentials themselves are valid, which the service decides.

yamlAdapted from github.com ↗
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
  name: {BINDING_NAME}
spec:
  serviceInstanceName: {SERVICE_INSTANCE_NAME}
  credentialsRotationPolicy:
    enabled: true
    rotatedBindingTTL: 48h
    rotationFrequency: 600h

Secrets in Terraform state

TerraformTerraform provider for SAP BTP

HashiCorp documents that local Terraform state is a plaintext file that includes any secret values in the configuration, to be kept out of Git; remote backends hold state in memory only while in use, and encryption at rest depends on the backend. Ephemeral values are omitted from state and plan files, and write-only arguments on managed resources need Terraform 1.11 or later. The Terraform provider for SAP BTP marks fields such as a service instance's `parameters` as sensitive, which hides them in CLI output while they are still stored in state in plain text, and its guide says plan files exported to JSON must not be committed.

Securing workloads in Kyma

KymaIstioAPI Gateway module

SAP's secure-development page for Kyma covers Pod security, Kubernetes network policies between Pods, Istio sidecar injection, and exposing workloads through the Istio and API Gateway modules with a custom domain and a TLS or mTLS gateway. An APIRule v2 rule has exactly one access strategy, `jwt`, `extAuth` or `noAuth`. Network policy support in the API Gateway and Istio modules is disabled by default, and SAP's Pod recommendations for workloads without special requirements are a non-root user, no privilege escalation, all capabilities dropped, seccomp and a read-only root file system.

yamlAdapted from github.com ↗
# Container spec
      securityContext:
        privileged: false
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        capabilities:
          drop:
            - ALL
        readOnlyRootFilesystem: true

Audit logging

SAP Audit Log service

SAP Audit Log stores audit data written by SAP BTP services for a default 90 days; writing audit events from your own applications and configuring retention need the premium plan. The Audit Log Write API authenticates with mTLS through X.509 certificates, and the predefined categories are `audit.data-access`, `audit.data-modification`, `audit.security-events` and `audit.configuration`.

Reporting a vulnerability

The SAP organisation's security policy covers every SAP-owned repository and asks that vulnerabilities not be reported through public GitHub issues but through the SAP Trust Center or by email to secure@sap.com, with the repository, the affected code location and steps to reproduce. The file lives in the organisation's `.github` repository, and GitHub uses such default community health files for any repository of the account that has none of its own.

06Documentation the atlas can read

The atlas records only what a project's own documentation states, and quotes the sentence it rests on. What it looks for:

The stack it serves
A package is listed as an artifact only when its own documentation names the SAP stack it is built for, such as BTP/BAIP. A generic library is not, however often a project installs it.
Where it runs
Runtimes and flavors are recorded where a sentence states them, and that sentence is shown beside the value. Where the documentation says nothing, the page says it does not say.
What it needs and talks to
Services it requires and systems it connects to, with the protocol, are edges drawn only from what the documentation names.
Its properties
A capability compares its artifacts on a few declared properties. A value counts only with the sentence it comes from; a property the documentation does not mention stays open.
Releases and a licence
Readings are crawled from the repository and the registry, releases and the last push among them. A README is shown whole only under a licence that permits copying; otherwise its opening and a link.

07Tutorials

Step-by-step material from SAP and the ecosystem, linked where it lives.

08Share it

Where finished BTP/BAIP work is published and found, and how it gets into the atlas.

SAP-samples/btp-terraform-samples
Terraform configurations for SAP BTP use cases, including account setups for Discovery Center missions; pull requests under a DCO github.com ↗
Discovery Center mission 4024 setup (Terraform)
Example of a mission's account setup published as Terraform: subaccount, entitlements, subscriptions, role assignments, trust github.com ↗
kyma-project/community-modules
Contribute a Kyma module: fork, add modules/<name>/moduletemplate.yaml (v1beta2), open a pull request github.com ↗
SAP Architecture Center contribution guidelines
Contribute to or propose a reference architecture: discuss in an issue, fork or use the Quick Start, open a pull request, accept the DCO architecture.learning.sap.com ↗
SAP/architecture-center CONTRIBUTING.md
The repository's contribution rules, including the guideline for AI-generated contributions github.com ↗
SAP-samples/cf-mta-examples
40+ MTA examples for Cloud Foundry deployment: managed services, extension descriptors, blue-green, hooks, secrets github.com ↗
SAP-docs/btp-developer-guide
Markdown source of the BTP Developer's Guide; contributions are reviewed for the SAP Help Portal github.com ↗
Add it to the atlas
Use Feedback, Add, or open a pull request against the atlas data. A repository URL is enough to start.
Credit
Maintainers and authors are linked to their work.
Corrections
Anyone can correct an entry, through Feedback or a pull request.