## 4.1.8.1.8.1  Applications
If you want to create an application in Cloud Foundry and use the SAP Cloud Deployment service, you must create an MTA module first.
In most of cases, an MTA module represents a Cloud Foundry application, but there are cases where they represent an entirely different type of entity, for example content. Modules can have different types and parameters that modify their behavior. For more information, see Modules [page 625].
<!-- image -->
##  Note
We strongly recommend that you specify the appropriate buildpack for your application. This ensures that the application is handled by the buildpack for which it is intended and tested. It also speeds up application deployment, because only the specified buildpack is downloaded for use during the staging process.
You have to use the buildpack module parameter, if you are using any of the following MTA module types:
- application
- custom
- javascript.nodejs
## MTA Deployment Optimizations
The MTA deployment is an incremental process. This means that the state of the artifacts in the Cloud Foundry environment is compared to the desired state described in the mtad.yaml . If there's a difference, a set of operations are computed in order to make the MTA reach the desired state. The following optimizations are possible during the MTA redeployment:
- The application bits are uploaded again if the following is true:
- The application content is changed and there is no cache of the same content for a different application, even in a different space. The Cloud Foundry environment has global caching of application bits without organizational and space isolation.
- The application is restaged and restarted if the following is true:
- The application attributes, such as commands, buildpacks, memory, health-check-url , and so on, are changed.
- The application environment is changed.
- There are new services to which the application is bound.
- There are services the application is bound to, which are discontinued (not available) in the new version of the MTA.
##  Note
Currently, Cloud Foundry environment applications are restaged if they are bound to any service with parameters. This is necessary, because it's not possible to get the current Cloud Foundry service parameters and compare them with the desired ones.
- The application is bound to service whose configuration parameters have been changed. This requires an update of the service instance and rebind, restage, and restart of the application.
- The service binding parameters are changed. This requires an update of the service binding and restage of the application.
- The MTA version is changed, which requires a change of special application environment variables, managed by the deploy service.
## Application-Specific Timeouts
When creating Cloud Foundry applications as part of the MTA deployment, you have the option to set specific timeouts for different phases of the application's creation or execution. When any of these timeouts occur, the MTA operation fails with a relevant error message to prevent the MTA deployment from running indefinitely.
Currently the following timeouts are supported:
- Upload timeout - the time it takes to upload the application binary to the Cloud Controller. Once the upload is complete, the application is ready to use.
- Stage timeout - the time it takes to stage the application.
- Start timeout - the time it takes to start all application instances.
- Task execution timeout - the time between the initiation of a Cloud Foundry task and its final state. This timeout also applies to module hooks, as they use Cloud Foundry tasks. For more information, see Module Hooks [page 649].
## Priority of Timeout Parameters
You can configure application timeouts at different levels according to your needs. When the same timeout (for example, start timeout) is configured in several places for one MTA deployment, a certain order of priority is applied.
The order provides flexibility when you want to define common timeouts for all applications which are part of an MTA but at the same time, you need to define application-specific timeouts.
The timeout parameters follow the following descending order of priority: