Skip to main content

Integration & IT Modernization

Deploying Mule Project to Multiple Environments

This is a quick note. There are plenty of other online resources discussing the same topic. I want to list the steps in one place, so it’s easier for anyone who wants to follow this practice.

In a typical software development life cycle, a project needs to be deployed to multiple environments. Mule project is no exception.

Mule project uses java property files and JVM environment variables to manage project deployment to multiple environments. This solution has several parts.

  1. Property files are created for each environment to store target specific parameters, typical file names are like,

The property names are common in these files. The property values vary depends on the environment. For example, we may have two properties “” and “db.port” define as something like:

  1. In the source code the property will simply be referenced like:

<set-variable variableName=“host” value=“${}” doc:name=“var”/>
<logger message=“port=${db.port}” level=“INFO” doc:name=“logger”/>
An environment variable is defined, for example, “env=dev” that allows the server to determine which environment the application is being deployed to, and therefore pick up the proper property files at runtime for the target platform.

  1. With Anypoint Studio, this is often defined inside
  2. With on-prem server, it can be defined on the server start up command line like

This “-M-D” is a special way for Mule to pass properties to the JVM that runs Mule engine.
If your Mule ESB is configured as service, you can locate the startup script and add “-M-Denv=xxx” for each environment.

3. With Cloudhub, when you deploy the application, you choose which environment to deploy to, then on the deployment page, there is a “properties” tab next to “runtime”. From there, you can simply set the “env” property, for example, to “env=prod”.

  1. In a Mule/Flow configuration file (normally it’s in a common global config file), the property files are referenced as

<context:property-placeholder location=“my-project-${env}.properties “ />

This line will automatically become one of the following files depends on the ${env} setting:
<context:property-placeholder location=“ “ />
<context:property-placeholder location=“ “ />
<context:property-placeholder location=“ “ />

With this setup, the developer doesn’t have to worry about which environment the application will be deployed to. The source code stays exactly the same for all environment. The admin who deploys the application decides which target environment to deploy the application to.

Thoughts on “Deploying Mule Project to Multiple Environments”

  1. If your Mule ESB is configured as service, you can locate the startup script and add “-M-Denv=xxx” for each environment.

    I did not understand this part. Can you please explain more?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Follow Us