Contact Free trial Login

Using Parameters in Your Configuration Files

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.
If you’re deploying multiple applications through a Shared Resources structure, then you shouldn’t set anything in the properties files, as there might potentially be conflicts between the various apps that share a domain. Instead, you can set environment variables over the scope of the deployed app, its domain and other apps under that domain. In Studio you can create these variables through the Environment tab of the Run Configurations menu, reachable via the dropdown menu next to the Play button.

When an application gets deployed in different environments, like QA, pre-production or production, it usually needs to be configured differently as server names, credentials and other similar parameters will vary.

As a developer facing this kind of variability, your goal is to produce a single Mule application for all your environments and to externalize all the environment-specific configuration parameters. This is the key to reproducible deployments.

Consider externalizing other aspects of your configuration, like time-out values, polling frequencies, etc…​ even if they don’t vary between environments. This will facilitate tuning and experimenting as the whole Mule application would become configurable through a single properties file.

In Mule, you achieve this by using Spring’s property placeholder resolution mechanism. Consider the following Mule configuration fragment that defines an HTTP endpoint pointing to a password protected web resource:

<http:endpoint name="ProtectedWebResource"
               path="path/to/resource" />

The variable bits are clearly visible: the user, password and host can vary for each environment where this endpoint gets deployed in. To provide values for these variables, we use a standard Java properties file:


Use a consistent naming strategy for your properties and make them unique across applications: this will greatly facilitate re-use across teams.

You also need to configure Spring’s property placeholder configurer. Instead of configuring Spring to load a single properties file, follow this approach:

  • Configure Spring to load a default properties file and another file containing overrides.

  • Ship a default properties file with values applicable for developers' workstations inside your Mule application deployable.

  • Create the properties override file only in the environments where it’s needed and with only the properties that actually need to be overridden.

The advantages of this approach are:

  • Developers don’t need to deploy and run the application locally.

  • The ops team only needs to work with the set of properties they have to configure for a particular environment.

Here is a method of accomplishing this:

<mule xmlns=""
             " />

With this in place, add a file in your application directory (src/main/app) and put default and development environment values in it. To override some values, create a file and drop it in $MULE_HOME/conf.


If your ops team can’t drop files in Mule’s directory hierarchy, the alternative is to configure the placeholder configurer to pick up the override file from a well-known location, as shown here:

                   file:///etc/mule/conf/" />

Use unique file names for your properties files to ease the burden on sysadmins. A good strategy is to use the application name or ID in the default and override properties file names.
Should you need to encrypt passwords in your properties file, consider using the Mule Credentials Vault. Refer to the documentation for Anypoint™ Enterprise Security for more information on securing applications in Mule.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub