---
schema_version: "1"
id: 666ef65241af198b6807132e159293f1c4312f30dbd82e3eea523c65a75e7b22
title: Modularize Configuration Files
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-runtime/4.11/modularizing-your-configuration-files-for-team-development.md
canonical_url: https://docs.mulesoft.com/mule-runtime/4.11/modularizing-your-configuration-files-for-team-development
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 684d2215cc5d3d6bf98827a75ece6950911de3dcf30482c5cf7631e2237ff67b
description: MuleSoft Documentation Site
release: "4.11"
latest: false
---
---
product: Mule Runtime
version: 4.11
keywords: anypoint studio, team, shared projects
---

# Modularize Configuration Files

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Though it might seem convenient to keep your Mule configurations in one file, a very large XML file
quickly becomes unmanageable. This is why MuleSoft recommends that you split monolithic
configurations into several files, and leverage Mule’s capacity to load multiple configuration files
at application start-up time. Splitting configurations into multiple files encourages reuse across
teams.

Mule offers two options for loading multiple configuration files:

- Side-by-side: Provide a list of independent configuration files to load.

- Imported: Have one configuration file import several others, which in turn, can import other
  files.

In practice, it’s common to use both approaches simultaneously.

Because configuration files are loaded in the same context, you must use unique names for the
configuration elements. Mule will not load an application if its configuration files have name
conflicts.

Here are some suggested ways to determine where to split configuration elements into separate files
and which elements to keep together:

- Business domains usually form a natural border that you can use to separate configuration
  elements.

- Keep together elements that have been changed for similar reasons. This reduces the risk of
  impacting unrelated aspects of your application.

- Technical elements, such as administrative components, security, and external system
  configurations determine good separation lines.

- Separate a side-by-side connector configuration to facilitate functional testing. (This suggestion
  does not apply to environment-specific connector configurations, which use properties files.)

- Consider reuse across teams and projects when you separate configuration elements.

> [!NOTE] By default, Mule treats all XML configuration files as configurations when an application
> is packaged and loaded in the side-by-side fashion.

## Imported configuration files

Mule has a special `import` configuration component for importing configuration files into each
other. This component takes a `file` parameter, which contains the reference to the desired
configuration file.

The following example shows a main configuration file that imports three other configuration
elements: `global-configurations.xml`, `admin-config.xml`, and `audit-flows.xml`

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://www.mulesoft.org/schema/mule/core"
      xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd">

    <import file="global-configurations.xml"/>
    <import file="admin-config.xml"/>
    <import file="audit-flows.xml"/>

</mule>
```

> [!NOTE] The import mechanism requires that the XML files are in the classpath.

## See also

- [Develop Mule Applications](https://docs.mulesoft.com/mule-runtime/4.11/mule-app-dev)