Configuring Properties

This page describes configuring properties, such as property placeholders and system properties.

Property Placeholders

You can use Ant-style property placeholders in your Mule configuration. For example:

<email:smtp-config name="config">
    <email:smtp-connection host="${}" port="${smtp.port}"/>

The values for these placeholders can be made available in a variety of ways, as described in the sections that follow.

Global Properties

You can use the <global-property> element to set a placeholder value from within your Mule configuration, such as from within another Mule configuration file. You can use the global property syntax to reference the values from a .yaml or .properties file, and create new (global) properties that depends on configuration properties, or secure configuration properties. To reference configuration properties, read the section on properties files.

<global-property name="" value=""/>
<global-property name="smtp.subject" value="Subject of Email"/>

Properties Files

To load properties from a custom file, you can place your custom properties file at src/main/resources and use the tag <configuration-properties>:

<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns=""
<configuration-properties file="smtp.yaml"/>

<flow name="myProject_flow1">
    <logger message="${propertyFromFile}" doc:name="System Property Set in Property File"/>

To load multiple properties files simply define a <configuration-properties/> tag for each file you want to load.

  • If a property is defined in more than one file referenced in <configuration-properties/> tags, the first definition will be preserved.

These files must be located at src/main/resources, inside your Mule project, or you can also use absolute paths.

Supported Files

The Configuration Properties supports both YAML configuration files and Properties files, as shown in the examples above. The recommended approach is to use a YAML configuration files, because it allows the addition of type validations and autocompletion.

We are not currently supporting any other type than Strings.

File Properties

The placeholder value can also be the entire content of the file. The placeholder value becomes the string value, for example:

Some content

<mule:set-payload value="${file::properties-file.txt}"/>

The payload’s value becomes "Some content". Just like other properties files, these files must be located in src/main/resources, inside your Mule project. Absolute paths can also be used.

This practice is useful for modularizing the configuration file: You can extract large contents from the config file, SQL queries, or transformations to make the config file clearer, and you can reuse the contents.

System Properties

The placeholder value can come from a JDK system property. If you start Mule from the command line, you would specify the properties as follows:

mule -M-Dsmtp.username=JSmith -M-Dsmtp.password=ChangeMe

You can also edit the system properties in conf/wrapper.conf if you are deploying Mule as a webapp. When running Mule in a container.

If you start Mule programmatically, you would specify the properties as follows before creating and starting the Mule context:

System.getProperties().put("smtp.username", "JSmith");
System.getProperties().put("smtp.password", "ChangeMe");

Setting System Properties in Anypoint Studio

You can also add properties when you launch your project on Anypoint Studio, through the Run Configurations menu:

  1. Right-click your project in Package Explorer.

  2. Click Run As > Run Configurations.

  3. Pick the Arguments tab.

  4. Add your arguments to the VM arguments field, preceding property names with -D


    Your properties are now available each time you deploy your app through Studio. You can then reference them with the following syntax:

    <logger message="${propertyFromJVMArg}" doc:name="System Property Set in Studio through JVM args"/>

Environment Variables

Environment variables can be defined in various different ways, there are also several ways to access these from your apps. Regardless of how an environment variable is defined, the recommended way to reference it is through the following syntax:


Environment Variables From the OS

To reference a variable that is defined in the OS, you can simply use the following syntax:

<logger message="${USER}" doc:name="Environment Property Set in OS" />

Setting Environment Variables in Anypoint Studio

You can set variables in Studio through the Run Configuration menu:

  1. Right-click your project in Package Explorer.

  2. Select Run As > Run Configurations.

  3. Pick the Environment tab.

  4. Click the New button and assign your variable a name and value.


Your variable is now available each time you deploy through Studio. You can reference it with the following syntax:

<logger message="${TEST_ENV_VAR}" doc:name="Environment Property Set in Studio"/>
The syntax makes no distinction between when you’re referencing a variable in the OS and a variable defined here. In case names overlap, there’s a radio button you can select when creating these variables that lets you define whether these variables overrides the original OS ones or not.


Setting Properties Values in Runtime Manager

If you deploy your application to Runtime Manager, you can also set properties through the Runtime Manager console. These can be defined when Deploying to CloudHub, or on an already running application.

To create an environment variable or application property:

  1. Log in to your Anypoint Platform account.

  2. Click Runtime Manager.

  3. Either click Deploy Application to deploy a new application, or select a running application and click Manage Application.

  4. Select the Properties tab in the Settings section.

Properties Hierarchy

Configuration properties can be overwritten. The Hierarchy in which these are treated is:

  1. Environment Properties

  2. System Properties

  3. Deployment Properties

  4. Application Properties

So, for example, if a configuration property is defined in a System Property, and there is also an application configuration property, the value for that application will be the last one.

Also, an application property could depend on Environment, System and/or Deployment properties. Deployment Properties could depend on System Properties, and so on.

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.