Contact Free trial Login

Shared Resources

Mule can define selected connectors as common resources and expose them to all apps deployed under a same domain. These resources are known as shared resources. To host them, you must create a Mule Domain Project and then reference it from each of the projects that use the elements in it. Once defined, any Mule app associated with a particular domain can access resources in this file. Note that Mule apps can be associated with only one domain at a time.

Shared resources allow multiple development teams to work in parallel using the same set of reusable connectors. Defining these connectors as shared resources at the domain level allows the team to:

  • Expose multiple services within the domain through the same port.

  • Share the connection to persistent storage.

  • Share services between apps through a well-defined interface.

  • Ensure consistency between apps upon any changes because the configuration is only set in one place.

To share the metadata, keep the Mule domain project open in Anypoint Studio. Otherwise, you must enter the metadata manually on the linked Mule projects.


This document assumes that you are using Anypoint Studio 7 with Mule runtime 4, or that you are building your apps using Studio 7 and deploying them to Mule 4 Standalone runtime.


Defining flows, subflows, or any message processors as shared resources is not supported. Domains are not meant to share behavior. They are meant to share resources only.

Basic Anatomy

Studio Project

The following files are key within the Mule Domain Project:


This is the shared resources configuration file. This file must have the mule-domain-config.xml file name.


This is the dependencies file descriptor. It is a Maven POM file with required plugins for domains projects.


This file is a descriptor for the domain artifact.

Domain Artifact

You can find the following files when you package a domain into a JAR file:


This is the shared resources configuration file. This file must have the mule-domain-config.xml file name.


A Maven-like repository with all the dependencies of the domain.


Artifact Maven descriptor file.


Internal Mule file used for dependency management.


This file is a descriptor for the domain artifact.


To use shared resources in your apps, you must complete the following tasks:

Creating a New Domain

To create a new domain in Anypoint Studio:

  1. In the top menu bar select, File > New > Mule Domain Project.

  2. Fill in the same fields as you would with a regular Mule Project:

    • Provide a name for the project, and select a Mule version.

Defining Shared Resources

You can configure the domain project by defining shared resources in your mule-domain-config.xml file. You can define multiple resources in this configuration file. In Anypoint Studio, you can edit this file in a couple of ways:

  • Configuration file: Through the XML similar to the XML configuration file for a Mule app, for example:

    <?xml version="1.0" encoding="UTF-8"?>
        <!-- configure here resource to be shared within the domain -->
  • Global Elements: This view provides a graphical interface for defining shared resources.

You can add module or connector dependencies to you domain project so you can use them as shared resources.

Associating Applications with a Domain

Apps can be associated with only one domain at a time. You can associate an existing app with a domain either by using Studio or by editing your project’s pom.xml file directly. If you don’t set a domain dependency, applications use the default domain.

Consider the following when working with Mule 4.2.2 and later versions:

  • The version honors semantic versioning.
    For example, if you set the version to 1.0.1, a domain with version 1.0.2 and later works, but a domain with version 1.0.0 does not.

  • If different domains are deployed with the same group ID, artifact ID, and version, the reference in the pom.xml file might be ambiguous.
    To avoid this issue, add the name of the domain folder in the application’s mule-artifact.json file:

  "domain": "mymuledomain-1.0.1-mule-domain"

Associate an App with a Domain Using Studio

To associate an application with a domain from Studio, follow these steps:

  1. In the Project Explorer or Package Explorer view, right-click the Mule application.

  2. In the menu that opens, click Properties.

  3. From Properties, click Mule Project.

  4. In the Domain field, select a domain for your project.


    Note that when you select a domain, the Mule runtime engine for your project matches the domain’s Mule runtime engine automatically.

After completing these steps, Studio includes the domain in the pom.xml for your project, for example:


Associate an App with a Domain Outside Studio

To associate an app with a domain outside Studio, add the domain dependency to the pom.xml file as shown in the previous example.

Referencing Shared Resources

The following mule-domain-config.xml example defines HTTP listener and HTTP request configurations as shared resources.

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

    <http:listener-config name="listenerConfig">
        <http:listener-connection host="" port="8080"/>

    <http:request-config name="domainLevel">
        <http:request-connection host="localhost" port="9090"/>


Any Mule application associated with the domain can make use of the shared resource by referencing it within the configuration, just as you would reference a resource within the project itself. In the example below, the HTTP listener connector references the shared resource named listenerConfig.

   <flow name="httpService">
      <http:listener config-ref="listenerConfig" path="/" doc:name="HTTP"/>
      <set-payload value="success" />

In Studio’s visual editor, you can simply pick the shared resource out of the dropdown list in the Connector Configuration field of the connector’s properties editor:


Deploying with Shared Resources

By default, when you deploy either an application associated with a domain or a domain associated with any application, Anypoint Studio deploys both. You can change this default behavior by changing the run configuration for the domain. You can also deploy a set of applications in your workspace together, even if they don’t share the same domain.

Mule domain projects cannot be installed using Runtime Manager.

To set this in Studio, open the drop-down menu next to the play button and select Run Configurations.


Then pick the General tab, and tick or untick the boxes next to the projects that you want to always deploy together with the application that is currently selected on the navigation menu to the right.


The steps below describe how to deploy your domain project and the applications outside Studio, to Standalone Mule.

  1. In Studio, select File > Export. Then in the folder named Mule, pick Anypoint Studio Project to Mule Deployable Archive (includes Studio metadata). This creates a .zip file that you can deploy to Standalone Mule.


    If you’ve created your Domain outside Studio, Zip the components of your domain project by selecting the mule-domain-config.xml file and, if you have one, the lib folder with its contents, and compressing them into a single zip file. Name this zip file with the name of the domain. Copy the zip file to MULE_HOME/domains.

    Note that right clicking the a folder and selecting Compress results in additional folders being added to your folder structure when Mule unzips your file, which causes deployment problems. Use the command line to zip your files recursively, or package your app as a zip file from Studio.

  2. Save, zip, and copy the zip file for each application that references this domain into the MULE_HOME/apps folder.

  3. Start Mule via the command console.

    When Mule starts, it first deploys any domains found in the MULE_HOME/domains folder, then it deploys the applications in the MULE_HOME/apps folder, so that all domains are fully started before the applications start.

Deploying Domain Bundles

You also have the option of bundling the applications associated with a domain in your domain folder, then deploying the entire folder as a bundled unit. To do this, include an apps folder in your domain folder structure and place the zip files of your applications there.


The deployment behavior is the same as deploying a domain and apps separately: Mule first deploys the domain itself, then the applications. Deploying domain bundles simplifies the deployment mechanism for teams by removing the manual step of deploying applications separately.

Deploying Domains using Mule Maven Plugin

You can deploy domains to your local Mule instances using the Mule Maven plugin. See Deploy a Domain for instructions.

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.