Contact Us 1-800-596-4880

On-Premises Deployment Model

Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule reached its End of Life on November 2, 2022, when Extended Support ended.

Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted.

MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements.

Mule application deployment consists of two main aspects:

  • The Mule runtime engine instance

  • The Mule applications deployed to that Mule instance

When you deploy applications to CloudHub or to Anypoint Runtime Fabric, these services take care of the Mule runtime engine instances needed to run applications.

When you deploy applications on-premises, you are responsible for the installation and configuration of the Mule runtime engine instances that run your Mule applications. Because you have complete control of the on-premise instance (unlike with CloudHub or Runtime Fabric deployments), you must understand the characteristics specific to on-premises deployments.

Running Multiple Applications in One Mule Instance

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:

  • You can break down a complex application into several Mule apps with their specific logic, and then deploy those several Mule apps in one Mule instance.

  • Clear boundaries for running operations in a Mule application.

  • Mule runtime engine monitors your Mule applications and reloads configuration changes automatically.

  • Applications can depend on different library versions.

  • Multiple versions of an application can run within the same Mule instance.

Application Package and Deployment

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:

  • The status of the application in the console is DEPLOYED.

  • An unpacked application folder exists in the /apps directory of your Mule instance: for example, for stockTrader.jar, $MULE_HOME/apps/stockTrader.

  • An anchor file exists 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.

Application and Domain Deployment

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:

deploy+domain

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.

Application Hot Deployment

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:

  • touch the anchor file of that application.

  • touch or update any of the Mule configuration files declared in the mule-artifact.json file.

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.

Communication Between Mule Instances and the Management Pane

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.