Deploy to CloudHub 2.0 using Maven and Connected Apps

Photo of Guilherme Pereira, Senior Integration Consultant Written by Guilherme Pereira, Senior Integration Consultant,   Nov 9, 2022

CloudHub V2 arrived with a new architecture and a lot of new features. Let's explore in this tutorial some new features available while deploying to CloudHub V2 using maven.


Deployment Life Cycle

There is a change in how you need to deploy Apps to CloudHub 2.0. As part of the life cycle, you need to deploy your App to Exchange before deploying it to your CloudHub Shared or Private Space.

If you don't deploy your App in the Exchange first, you will face an error message like this one while deploying:

Error "No application with the provided GAV could be retrieved from Exchange" while deploying the CloudHub 2.0 applications


As you know, CloudHub V2 uses a kubernets-based architecture under the hood, and the deployment lifecycle is the same used by Runtime Fabric. As required by this architecture, the application must be pulled from a repository. Anypoint Platform uses Exchange for this purpose.

application must be pulled from a repository

You must ensure your project is configured and using the correct versions of Exchange Maven Facade and Mule Maven Plugin.

The Exchange Maven Facade is an API developed by MuleSoft and emulates a set of features of a Maven repository. The new Exchange V3 contains some new features, like support for SNAPSHOT assets and it's the default version defined for all new Mule 4 projects.

The Mule Maven Plugin also has some updates and a new version. To deploy Apps in CloudHub V2, you need at least version 3.7.0, but keep your eyes on the Mule Docs because, by the time I'm writing this article, the latest version is 3.8.1 containing a lot of bug fixes, new features and improvements.


Snapshot Versions

As mentioned, Exchange Maven Facade now supports SNAPSHOT versions. All SNAPSHOT versions will be configured with the development state in Exchange.

From Mule Docs: "A SNAPSHOT asset is permanently in the development state and cannot be promoted to any other state."

So, while you are developing your App or another asset like a connector or plugin, you can leverage the SNAPSHOT versions to publish it to Exchange.

Stable Versions

Publishing a non-SNAPSHOT asset will create a new asset with a stable state in Exchange and all assets must have a unique GAV (GroupId, ArtifactId, Version). An asset with the same GAV will cause a conflict, make sure you have a unique GAV before deploying it to Exchange as a stable asset.

In some situations, your REST Specification asset might have the same name as your Mule App. In this case, you need to modify your App ArtifactId to avoid conflicts.


Deploying to CloudHub V2

Let's deploy a simple App to CloudHub V2 and see how the new deployment life cycle works. 

First, let's create a Connected App that will allow us to deploy Mule Applications into CloudHub V2:

Go to Anypoint Platform, in the Access Management navigation menu, click Connected Apps:

  1. Click Create App.
  2. Give a name to your App and in the Type field, select App acts on its own behalf (client credentials).
  3. Add the following Scopes to your App: Create Applications, Delete Applications, Manage Application Data, Read Applications, View Environments, View Organization and Exchange Contributor.
  4. Review the configurations and save your App.

create app-1

Open your settings.xml and add a new server entry containing the Client ID and Secret of your Connected App:

        <password>{Client ID}~?~{Secret}</password>


Create a simple Mule App in your Anypoint Studio, and let's modify the following in the pom.xml:

  • Change the groupId to your Anypoint Platform Organization ID / Business Group ID:
    <groupId>Organization ID</groupId>


  • Update the Mule Maven Plugin in the properties section:
    <properties>    ...


  • Add a distribution management pointing to Exchange V3:
            <name>Exchange Private Repository</name>


    repository→id: This is the same value configured in the settings.xml→server→id and references Connected App Client ID & Secret.


  • Make sure you have Exchange V3 in the repositories section:
            <name>Anypoint Exchange</name>


  • Configure the Maven Mule Plugin with the CloudHub V2 deployment option:
        <uri> </uri>


    1. environment: his is the CloudHub V2 environment name. Make sure the name matches equal your environment name.
    2. target: This is the CloudHub V2 Shared Space Region Name or the Private Space name where you want to deploy the App.

      List of the 12 regions available for the Share Space:

      • Cloudhub-US-East-1
      • Cloudhub-US-East-2
      • Cloudhub-US-West-1
      • Cloudhub-US-West-2
      • Cloudhub-EU-West-1
      • Cloudhub-EU-West-2
      • Cloudhub-AP-Southeast-1
      • Cloudhub-AP-Southeast-2
      • Cloudhub-AP-Northeast-1
      • Cloudhub-SA-East-1
      • Cloudhub-EU-Central-1
      • Cloudhub-CA-Central-1
    3. server: This is the same value configured in the settings.xml→server→id and references Connected App Client ID & Secret.
    4. generateDefaultPublicUrl: Use it as true to generate a Public endpoint within * domains.

Check out the resources section for a full example of the pom.xml file and more examples like deploying using a custom domain.

Run the following commands: 

  1. mvn clean deploy: This command will deploy your App to the Exchange:
    deploy app to exchange
  2. mvn clean deploy -DmuleDeploy: This command will deploy the App to CloudHub V2:

deploy the App to CloudHub V2


Final thoughts

Under the hood, CloudHub V2 uses the same architecture as Runtime Fabric, so those familiar with Runtime Fabric will notice the process to deploy an application is the same.

New features like the ability to deploy Assets to Exchange using SNAPSHOT versions can be combined with Mule Maven Plugin and help you to configure better CI/CD pipelines in your organizations. 

Finally, check out the resources section for other examples of usage of the Mule Maven Plugin to deploy Apps to CloudHub V2 using different options.



  1. Project pom.xml - full example:
  2. Deploying to shared space:
  3. Deploying to private space and using * as a public endpoint:
  4. Deploying to private space without a public endpoint:
  5. Deploying to private space using a custom domain as a public endpoint:



We’d love to hear your opinion on this post