Contact Free trial Login

Application Deployment

Learn how to deploy, undeploy and update Mule applications.

Starting Mule

Start Mule from a command line tool by running $MULE_HOME/bin/mule or start Mule as a service. By default, applications in the $MULE_HOME/apps directory are deployed.

Use the mule.deploy.applications property to specify the apps that are deployed when starting Mule. To specify multiple apps, use a colon (:) to separate them. Mule 4 respects the order when starting the applications. New or updated applications don’t start until Mule restarts.

Start Mule and specify which app to deploy, for example:

mule -M-Dmule.deploy.applications=foo

Where foo is a Mule app at $MULE_HOME/apps/foo.

From this moment, Mule checks every three seconds for the $MULE_HOME/apps/foo/mule-config.xml updates. You can update the application jar contents and modify this file so Mule reloads the config and class modifications.

Start Mule by specifying multiple apps to run, for example:

mule -M-Dmule.deploy.applications=foo:xoo

Where foo is a Mule app at $MULE_HOME/apps/foo and xoo is another Mule app at $MULE_HOME/apps/xoo.

If you start Mule and specify an app using the mule.deploy.applications property, the hot deployment process works only for the specified app.

Deploying Applications

Mule applications, either packaged (for example jar file) or exploded can be dropped into $MULE_HOME/apps. If Mule is already running, the application is deployed dynamically.

All applications in Mule are unpacked at runtime and the original jar is removed. This means, for example, that dropping a jar file into /apps dir creates a new folder with the same name (without the jar extension) and deletes the jar.

Confirm a successful app deployment by:

  • Having an unpacked application folder in the apps dir. For example, for stockTrader.jar- $MULE_HOME/apps/stockTrader.

  • An anchor file created for a running app, for example, $MULE_HOME/apps/stockTrader-anchor.txt

If you want to store your applications in a different location, you can store them on Unix-based systems by creating a symlink to your application directory from $MULE_HOME/apps.

Deploying Applications in Parallel

In Mule 4, you can deploy applications in parallel. Deploying applications in parallel reduces the startup time when you deploy a large number. To prevent deployment failure, ensure that applications are not dependent on each other because a particular start order cannot be guaranteed.

To enable parallel deployment, start Mule using the -M-Dmule.deployment.parallel option. For example:

mule -M-Dmule.deployment.parallel

All applications in the /apps directory start in parallel.

Undeploying Applications

Don’t delete the application folder directly, but rather delete an app’s anchor file only.

Deleting only the app’s anchor file:

  • Prevents any interference from the hot-deployment layer and doesn’t leave room for concurrent conflicting actions.

  • Avoids potential application jar locking issues on some operation systems and allows for clean shutdown and undeployment.

For example, if the stockTrader app is running (app folder is there as well as the $MULE_HOME/apps/stockTrader-anchor.txt file), just delete the anchor file to remove the app from the Mule instance at runtime. Application folder is removed after the app terminates.

After undeploying a Mule Application, there is a timeout of 15 seconds until LoggerContext stops. Log files for an application only release after this timeout expires. This information is important in Windows, where you can’t remove files that are in use by other processes.

Updating Applications at Runtime

Updating a Mule application at runtime can be a complex change involving class modifications, endpoint modifications (for example, changing ports, etc), as well as reconfigured flows. As a result, any application update does a graceful app shutdown under the hood and reconfigures itself. In practice, this is pretty transparent to the user and happens within seconds.

There are several ways you can update an application:

  • By dropping the modifications over an existing exploded app folder and touching the 'master' configuration file (mule-config.xml in app root by default).

  • By dropping a new jar version of the app into $MULE_HOME/apps dir. Mule detects this as an existing app update and ensures a clean redeployment of the app. Note that Mule discards any modifications to the old app folder - the new app folder is a clean exploded application from a jar.

As you see, both integrate pretty well with existing build tools, the preference for one over another really depends on established development practices only.

Sharing Resources

If you’re deploying multiple applications to the same place and those applications could share the same resources, then you can create a common domain where you can define common configurations that can then be referenced by multiple projects. This allows you to, for example, expose different services in different projects through the same HTTP host and port and be able to deploy everything without any conflicts.

What happens if communication between RunTimes and Management pane is disrupted?

Mule runtimes run independently with the Management pane to execute integration logic and serve API requests. This architecture allows for the runtimes to be deployed strategically (on-prem and cloud) and ensures it is not a bottleneck for any communications. When/if an event occurs which causes the runtimes to get disconnected from the Management pane, they continue to run as designed and execute integration and/or serve API without interruption. However, new or updated policies will not be pulled and updated until the connection is re-established.


If the application fails to start (for example, in a broken configuration file), Mule does not monitor the app for changes (as technically there is no application running). To update such an app, simply redeploy the app by dropping an updated archive into the apps folder.

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.