On-Premises Deployment Model

One instance of Mule runtime engine can run multiple applications, enabling you to include the same namespaces within different applications that neither collide nor share information, which provides additional advantages such as:

Mule runtime engine unpacks all applications at runtime, removes the original .jar files inside the /apps directory, creates a new folder for each application, and names each folder with the same name as the application file (minus the .jar extension).

To confirm successful deployment, verify the following:

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.

All applications are deployed together within a domain. By default, your application references the default domain, and no further configuration is required. You can see that the domain is deployed with the Mule app in the console:

If you’re deploying multiple applications to the same Mule instance, and the applications must share the same resources, you can create a common domain to define configurations that can be referenced by multiple projects. This practice enables you to expose different services in different projects through the same HTTP host and port without causing conflicts.

You can modify your Mule application’s configuration files and custom classes and reload the app without having to restart Mule.

Every three seconds, Mule checks for updated configuration files in the $MULE_HOME/apps directory and, when it finds one, Mule reloads the configuration file and the JAR files in that application’s java source directory.

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

To reload an application, you can:

For example, if you want to modify one of your custom classes, make your changes to the custom class, copy the updated class to the java directory, and then touch the anchor file.

Mule instances run independently from the Management pane to execute integration logic and serve API requests. This architecture enables you to deploy Mule runtime engine strategically and ensures that it is not a bottleneck to communications.
When an event occurs that causes the Mule instances to become disconnected from the Management pane, the instances continue to run as designed to execute integration and serve APIs without interruption. However, new or updated policies are not pulled and updated until the connection is reestablished.