Contact Free trial Login

Deploying to CloudHub

logo cloud active logo hybrid disabled logo server disabled logo rtf disabled

You can deploy Mule applications to CloudHub using:

  • Runtime Manager

  • Anypoint Studio

  • CloudHub API

  • CloudHub CLI

  • Mule-Maven Plugin

Naming an Application

Applications are always deployed with public application names in the domain. Application names must be globally unique across CloudHub to avoid domain conflicts.

For this reason, create a naming convention for your applications. For example, you can always prefix your applications with mycompany and optionally a department name: mycompany-mydept-myapplication. You can then add your own DNS records to hide this complex application name. For example, you can route requests to to

The application domain identifies your application in Runtime Manager and also provides you with a public URL for accessing the application if it exposes any inbound endpoints. The format of the URL is For example, an application named abcde is accessible at

With the CloudHub dedicated load balancer, you can then optionally implement mapping rules to set your application’s public URL to any other path you choose, as long as you own the domain.

Deployment Target

If you already have servers registered to the Anypoint Platform, you see a Deployment Target field in the Deploy Application page. Use it to specify where you want to deploy your application, in this case, CloudHub.

For more information about deploying to on-premises servers, server groups, and clusters, see Deploying to Your Own Servers.

Deploy an Application to CloudHub from Studio

You can deploy your applications to CloudHub from Studio. This is helpful if you’re still developing the application and want to deploy it often to an online test environment.

  1. In Studio, open your application as a Mule Project.

  2. In Package Explorer, right-click the project node, then select Anypoint Platform, then Deploy to CloudHub.

  3. If this is your first time deploying from Studio, a popup dialog box asks you to provide your login credentials for Anypoint Platform. Studio stores your credentials and uses them automatically the next time you deploy to CloudHub.

    You can manage these credentials through the Studio Preferences menu, in Anypoint Studio > Authentication.
  4. After you sign in, the Deploy Application dialog opens.


    You cannot deploy an application from Studio to the CloudHub Design environment. The Design environment is specific to applications created in Anypoint Platform Design Center.

Deploy an Application to CloudHub from Runtime Manager

  1. In Anypoint Platform, go to Management Center > Runtime Manager.

  2. In the Applications tab, click Deploy application.

  3. In the Deploy Application page:

    • Enter an Application Name

      An application with the same name cannot be deployed in two environments at the same time. Valid names have a minimum of 3 and a maximum of 42 characters and can contain alphanumeric characters and dashes. Runtime Manager alerts you if the name is available or already reserved by another user.
    • In the Deployment Target drop-down list, select CloudHub.

    • Click Choose File, then select either:

      • Import file from Exchange

      • Upload file

        The application file size limit is 200 MB.
  4. (Optional) To deploy an the application that is in the sandbox environment, you must first move the application from the sandbox environment to the production environment. To do this, click Get from sandbox.
    If the Get from sandbox button does not appear, you first need to create a non-production environment.

  5. In the Runtime tab, select the values from the drop-down lists for:

    • Runtime version

    • Worker size

    • Workers

    • Region

      Select from the following options:

    • Automatically restart application when not respondingRestart the application automatically when it is unresponsive.

    • Persistent queues – Store data in an input queue to disk. See Persistent Queues for more information.

    • Encrypt Persistent queues – Encrypt the data stored in the input queue on disk.

    • Enable Monitoring and Visualizer – Use Anypoint Monitoring and Visualizer for Mule applications running on supported versions of Mule.

      This option appears only if it is enabled for your organization and you have a Titanium subscription to Anypoint Monitoring.
  6. Click Deploy Application.

Set Up a Deployment Failed Alert

To be notified by email when there is an error during deployment, set up a deployment failed alert:


Complete the form and choose Deployment failed as the alert condition.

Deployment Execution

CloudHub uploads your application and automatically begins the deployment process. During this process, your view is switched to the log view, allowing you to monitor the process of your application deployment. This process might take several minutes.

During the deployment, the application status indicator changes to yellow to indicate the deployment is in progress.

When deployment is complete, the application status indicator changes to green, and you are notified in the status area that the application has deployed successfully. Here’s what is in the logs:

Successfully deployed [mule application name]
While you deploy an application on Mule runtime engine version 4.1.x and later, the Gatekeeper mechanism works with API Autodiscovery to help determine the readiness of a deployment. If Gatekeeper considers the application not ready in five minutes, then the deployment status is failed.

Deploy from CloudHub CLI

To deploy a Mule app from the CloudHub Command Line Utility (CLI):

  1. Verify that CloudHub access is enabled on Anypoint Platform.

  2. If you do not already have access to the Anypoint-CLI command line tool, install it using Anypoint Platform CLI installation instructions.

  3. Log into your Anypoint Platform account from the command line:

    1. Enter your username: anypoint-cli --username="user".

    2. Enter your password.

  4. Use the runtime-mgr application deploy command providing the name of the app and the location of the deployable archive (.zip) file on your file system, for example:

    runtime-mgr cloudhub-application deploy myMuleApp /Users/exported-app-folder/
  5. If there are no issues with the name, location or any optional parameters provided, you see a table listing deployment information:

    Deploying myMuleApp ...
    │ Domain                       │                  │
    │ Status                       │ UNDEPLOYED                             │
    │ Updated                      │ a few seconds ago                      │
    │ Runtime                      │ 4.1.0                                  │
    │ File name                    │                        │
    │ Persistent queues            │ false                                  │
    │ Persistent queues encrypted  │ false                                  │
    │ Static IPs enabled           │ false                                  │
    │ Monitoring                   │ Enabled. Auto-restart if not responding│
    │ Workers                      │ 1 vCore * 1                            │
  6. Congratulations, your app is now deployed on CloudHub!

  7. Applications that are deployed via the CLI can be viewed and managed on Runtime Manager like any other application.

    1. If you want to stop the app, on the command line type runtime-mgr cloudhub-application stop <app-name>.

    2. To exit the command line tool, press ctrl + c twice.

  8. Anypoint Platform CLI contains a full list of commands.

Move an Application from Sandbox to Production

If you created and tested an application in a sandbox environment, when you are ready to deploy the application, you must first move the application from the sandbox environment to the production environment.

  1. Sign into your Anypoint Platform account, and go to your production environment.

  2. In the Applications tab, click the Deploy Application button.

  3. Click Get from sandbox to select the application to move to production.

    deploying to cloudhub d6f7a
  4. In the Get from sandbox dialog, select your sandbox environment, select an application to deploy to production, then click Apply.

    Optionally, select the Merge environment variables and mule version checkbox to copy the environment variables and Mule version from the source application you selected.

  5. Continue setting up your deployment as you would with any other deployment.


  • Only a CloudHub Administrator can move applications between environments.

  • To avoid domain name conflict, an application with the same name cannot be deployed in two environments at the same time. Modify the application’s name slightly to deploy it to another environment.

  • Runtime Manager prevents you from duplicating applications in a single environment, so you cannot move an application into the environment it’s already in. To have the same, or similar, applications in a single environment, modify one application’s file to distinguish it from the original.

Runtime Tab

Runtime Version

Using the drop-down menu, select the Runtime version where you want to deploy:

  • Ensure that the runtime version is the same Mule version used to develop your application. For example, if you use the value 3.9.1 and your application uses the new HTTP connector introduced in Mule 4.1.1 and later, your application won’t deploy and the log will contain errors.

  • To see what runtime version you set when you deployed your application:

    1. Click the Applications tab and click your application.

    2. In the expansion view on the right, click Manage Application.

    3. Click Settings to see the deployment values.

Once the application is deployed and running, if any security patches, OS updates, or critical bug fixes are released for the selected runtime version, then you are prompted about this change. If you take no action, updates are applied automatically after 30 days to ensure your applications run with the latest security patches.

deploying to cloudhub update

Worker Sizing

After deploying your application, you can allocate the number and size of the worker associated with your application. On each application, workers are responsible for executing the application logic.

Only running applications count toward workers usage.
Stopped applications do not consume vCore availability.

Worker sizes have different compute and memory capacities, including:

Worker Size Heap Memory

0.1 vCores

500 MB

0.2 vCores

1 GB

1 vCore

1.5 GB

2 vCores

3.5 GB

4 vCores

7.5 GB

8 vCores

15 GB

16 vCores

32 GB

Workers that have less than 1 vCore capacity (0.1 vCores and 0.2 vCores) offer limited CPU and IO for smaller work loads. Each worker has 8 GB of storage, which is used for both system and application storage.

Workers running on fractional vCores (0.1 vCores and 0.2 vCores) have the ability to burst to higher CPU speeds for a short duration of time. This is useful for improving application start-up times and with processing infrequently large workloads. Allocating workers with 1 vCore or greater is recommended if consistency of performance is needed.

Applications with greater storage needs (for example, verbose logging) should use one of the larger worker sizes—​2 vCores or 4 vCores, which have additional storage as follows:

  • 1 vCore workers have an additional 4 GB of storage

  • 2 vCores workers have an additional 32 GB of storage

  • 4 vCores workers have an additional 80 GB of storage

  • 8 vCores workers have an additional 160 GB of storage

  • 16 vCores workers have an additional 320 GB of storage

The workers with additional storage listed above are available only for Mule version 3.6.2 or later, or API gateway version 2.0.2 or later.

+ It is recommended to access the additional storage at /tmp.

Select the options from the drop-down menu to configure the computing power you need:


Depending on how many vCores are allocated to your account, some of these options may not be applicable, as you may not have enough available capacity.

If you select more vCores than are available in your account, CloudHub allows you to create the application using the console, but you cannot start your application until the vCores are available.

When deploying an application with more than one worker, CloudHub automatically balances any incoming traffic load across your allocated workers. For more information, see Clustering.


If you have global deployment enabled on your account, you can change the Region to which your application deploys using the drop-down menu. Administrators can set the default region on the Organization tab in Account Settings, but that region can be adjusted here when the application is deployed, if necessary.

  • Applications deployed to Europe automatically have their domain updated to

  • Applications deployed to Asia / Pacific automatically have their domain updated to

Automatic Restart

If you are deploying to a runtime that supports worker monitoring (3.4.0 runtime or later), you have the option to select Automatically restart application when not responding. When you select this option, CloudHub automatically restarts your application when the monitoring system discovers a problem with your application.

If this option is not selected, CloudHub produces all the log messages, notifications, and any configured alerts, but takes no action to restart the application.

Read more about Worker Monitoring.

Persistent Queues

Select this box to enable persistent queues on your application. Persistent queues protect against message loss and enable you to distribute workloads across a set of workers. Before you can take advantage of persistent queueing, your application must be set up to use queues. See Clustering for more information.

If your Mule application is using batch component and persistent queues, then you might see batch records being processed multiple times. All batch records are stored in Amazon SQS and by default the visibility of the message is set to 70 seconds. If your batch process takes longer than 70 seconds, then batch processes might see the same message again and process it multiple times.

To avoid this issue, set the 'persistent.queue.min.timeout' system parameter to a reasonable value. For example, if your batch process takes 30 minutes to complete, then set the value to 'persistent.queue.min.timeout=2700000' milliseconds (45 Minutes). The maximum value is 43000000 milliseconds (12 hours). See the below screen shot for setting the value in CloudHub.


Properties Tab

You can optionally specify properties that your application requires. This allows you to externalize important pieces of the configuration that may switch depending on the environment into which you’re deploying. For example, if you’re using a Mule application locally, you might configure your database host to be localhost. But if you’re using CloudHub, you might configure it to be an Amazon RDS server.

To create an application property, click the Properties tab and set the variable by using either a text key=value format or by using the list format with two text boxes. After you have made the change, click Apply Changes.

deploying to cloudhub cff02

These application properties can be used inside your Mule configuration. For example:

<spring:bean id="jdbcDataSource" class="org.enhydra.jdbc.standard.StandardDataSource" destroy-method="shutdown">
   <spring:property name="driverName" value="com.mysql.jdbc.Driver"/>
   <spring:property name="url"value="${database.url}"/>
In text format, the backslash (\) character is used as an escape character. For example, to use : in key or value, you can put \: in the text. To use \, \\ is needed. No escape character is required in list format.

Overriding Properties in CloudHub vs. On-Premises Mule

Just like with on-premises Mule deployments, applications that you deploy to CloudHub can still bundle their own property placeholder or secure property placeholder files inside the deployable archive file. CloudHub substitutes these properties into the application when the application starts.

With an on-premises Mule, there are a couple of ways you can override property values bundled inside the application:

  1. You can configure an external location to add property or secure property placeholder files to override properties.

  2. You can set Java system environment variables at deployment time to override properties.

For example, to use the second option, with an on-premises server you could deploy your application with the following command:

mule -M-Dsecret.key=toSecretPassword -M-Denv=prod -M-Ddb.password=secretPassword -app

In this case, all the values typed into the command are stored only in memory; they are never stored in any file.

With CloudHub, techniques to override properties work differently.

The first approach is more difficult for CloudHub to translate because when an application is deployed into CloudHub it is harder to write override properties files into the file system.

The second approach is easier for CloudHub to handle because the Properties tab allows you to specify Java system environment variables that will function in the same way as adding environment variables when you deploy to an on-premises server. Read more about how to set these variables in Managing Applications on CloudHub.

If you also have property names set in a file inside your application, or in bundled property placeholder files, then when your application is deployed, any entries in the CloudHub Properties tab with the same name will override the matching value bundled with the application.

It is possible to change the behavior of the application to not allow CloudHub properties to override properties bundled with the deployable archive. You do this by changing the options in the Property Placeholder element in the Mule application to prefer property placeholder files over JVM system environment variables. See Spring documentation on Property Placeholder options for more information on non-default property placeholder options.

Overriding Secure Properties

You can flag application properties as secure so that their values are not visible to users at runtime or passed between the server and the console. You can also include an file in your application bundle, which can include properties that are marked as secure, so they are automatically treated as such.

Secure properties can also be overridden by new values you set at runtime in the Runtime Manager console. See Secure Application Properties for more information.

Insight Tab

The Insight tab lets you specify metadata options for the Insight analytics feature. For more information, see Insight.


Logging Tab

CloudHub stores activity logs, which can be viewed or downloaded from the platform. The Logging tab of the deploy menu lets you configure how these logs are structured. Specifically, it lets you set how the different logging levels are applied (INFO, DEBUG, WARN, or ERROR), so that they don’t follow the default usage. For more information, see Viewing Log Data.

The bell icon in the upper right corner lets you manage notifications. For more information, see Alerts

Static IPs Tab

To enable a static IP address for your application, go to the Static IPs tab, then select the Use Static IP checkbox.

Static IP tab

To pre-allocate static IP addresses for your application, select a region from the Region dropdown menu, then click Allocate Static IP to allocate a static IP for the chosen region. The static IP address is allocated when the application is deployed to that region. If the application is already running, applying the static IP address change triggers a restart of the application with the newly-applied static IP address.

Static IPs by region

By default, the number of static IP addresses allocated to your organization is equal to twice the number of production vCores in your subscription. This number is displayed under the Use Static IP checkbox.

If you need to increase this quota, please contact MuleSoft Support.

If an application has static IP addresses reserved in multiple regions, it picks up the IP address from whichever region it is deployed to. This allows you to pre-configure IP address rules for multiple regions for disaster recovery (DR) scenarios.

If you need to free up some of your overall static IP allocation, you can release a static IP that is currently allocated to an application.

Configuring a Deployed Application

Most of the settings you specified when deploying the application can be edited after the application is deployed to CloudHub.

To edit an application’s settings:

  1. In the Applications tab, select an application entry and click Manage Application.

  2. Click the Settings tab.


Auto-Deploy a Proxy from API Manager

If you have registered an API in the Anypoint Platform, you can easily run it through an auto generated proxy to track its usage and implement policies. You can deploy this proxy to CloudHub without ever needing to go into the Runtime Manager section of Anypoint Platform.

From a menu in the API version page, you can trigger the deployment of your proxy and set up the CloudHub application name, environment, and gateway version to use. Then you can optionally access the Runtime Manager deployment menu for this proxy and configure advanced settings.

Deployment Errors

If an error occurs and the application cannot be deployed, the application status indicator changes to Failed. You are alerted in the status area that an error occurred. Check the log details for any application deployment errors. You need to correct the error, upload the application, and deploy again.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub