Skip to Content
Technical Articles
Author's profile photo Balaji Vengatesh Murugesan

MTA deployment, a starter


This blog post is aimed for developers who are very new to SAP BTP which requires a deployment descriptor (MTA or Manifest)  to deploy applications.

It is always challenging to deploy an MTA or manifest based application be it NodeJS, GO or Java. Additionally we face a lot of challenges and jargons which slows our development.

Though creating MTA might feel overwhelming at first, it has a lot of advantages to offer. The deployment is one touch most of the time and creates an ecosystem where different components from a single application can collaborate together. Helps us create more resources without writing manual commands or collective shell scripts for every resource we consume.  So the entire file is reusable



We can install the cloud MTA build tool using any of the methods below in the link

You have to consider the following limits for the MTA artifacts, which can be handled by the Cloud Foundry deploy service:

  • Maximum size of the MTA archive: 4 GB
  • Maximum size of MTA module content: 1 GB
  • Maximum size of MTA resource content: 1 GB
  • Maximum size of MTA descriptors (mtad.yaml and MANIFEST.MF): 1 MB



The different terminologies used in MTA deployments are

Multitarget application (MTA)

An application comprised of multiple software modules, which are created with different technologies and deployed to different runtimes.

Development descriptor

A YAML file named mta.yaml that contains a list of all entities, such as modules, resources, and properties that belong to an application or are used by it at runtime, and the dependencies between them. It is automatically generated when an MTA project is created or modified, or when a module is added or removed. The developer needs to edit the descriptor manually to define resources, properties, and dependencies, as well as fill in missing information.

Deployment descriptor

A YAML file named mtad.yaml that contains a list of all entities which is created from the WEB IDE or from Multitarget Application Archive Builder tool or manually. This file is similar to Development Descriptor but is used from the MTA Deployer.


A self-contained application of a certain type, which is developed, packaged, and deployed.

Module Type

A type that defines the structure and the development technology of a module. You can see a list of the module types at Modules.


Any resource, such as an external service that is required by a module at runtime but not provided by the module itself.


A property (key-value pair) of an application, module, or resource, that is used during deployment or at runtime.


A reserved variable belonging to a module or resource, whose value is used during deployment or at runtime.


A relationship between a module and another module, resource, or property, such as provides and requires.

provides: indicates the properties or parameters that are provided by a module or resource to other modules.

requires: indicates other modules or resources that are required by a module in order to run.

MTA archive (MTAR)

Archive containing a deployment descriptor, the module and resource binaries, and configuration files. The archive follows the JAR file specification.



Consider a nodeJS app having dependency to a hdi-container in a subaccount.  This can be modelled like this


_schema-version: "3.1.0"
ID: simple-mta
version: 1.0.0

- name: anatz
  type: javascript.nodejs
    - name: hdi-service

- name: hdi-service
  type: org.cloudfoundry.managed-service
    service: hana
    service-plan: hdi-shared

The sample file contains a nodejs module named anatz which ready to be deployed. You can also specify the path of the module by specifying the path property. Also few modules such as the launchpad do not contain the path property, as it takes the already created modules and configures them to deploy.

A requires property is specified which allows the module to be deployed only if the required dependencies are satisfied. The required dependencies can come from other modules or from the resources that will be created as services in SAP BTP. like databases or event meshes


Additionally we can also provide parameters such as memory and route to the module. This enables us to control all the modules in one place before deployment


_schema-version: 3.1.0
ID: anatz-keep-existing
version: 4.0.0

- name: anatz
  type: staticfile
    memory: 64M
    route: new-custom-route-${space}
      env: true
      service-bindings: true
      routes: true


Sometime we would like to generate our files before starting the build. This can be done by running a shell script or individual commands like mvn clean install or npm install. All these can be speified under Build parameters.

- builder: custom
- npm install --production
Commands can also be run specific to modules.
Resources can also contain parameters which takes care of special hardcoded values such as url’s or references such to files.
So before we plan an MTA deployment
  • It is advisable to look into the manifest.yaml file (If you have already) make note of modules and dependencies before starting to create one here.
  • Once you have the module files in place start creating the modules, if needed add a provide property to the module if it requires to be addressed by the upcoming modules by that name


Finally do an MTA build using the command mbt build on the module. resolve any errors shown. The final MTAR file will be generated in mta_archive as an .mtar file
You can deploy the mtar file to cloud foundry by  using the command  cf deploy filename.mtar

If deployment is successful you will receive no process failed message at the end of deployment.


For more information on MTA’s checkout the help portal






Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Sudarshan Survepalli
      Sudarshan Survepalli

      Thank you very much for demystifying the terminology which most always is a hindrance in understanding things