--- schema_version: "1" id: 4eee2f7919706787499e405aea4a6c519ac4f01f0fabf007cfead9279524440e title: On-Premises Mule Runtime Deployment Model collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/on-premises/4.4/mule-deployment-model.md canonical_url: https://docs.mulesoft.com/on-premises/4.4/mule-deployment-model source_site: docs.mulesoft.com content_type: documentation content_hash: ec4726ab2bec18c639c1768a1f130ca13258e301396ba082490136dde6dc6122 description: MuleSoft Documentation Site release: "4.4" latest: false --- --- product: On-premises Runtimes version: 4.4 keywords: on-premises, on-prem, standalone, apps folder, anchor file, mule-maven-plugin, standaloneDeployment, domain, hot deployment, mule-domain-config.xml, domains folder --- # On-Premises Mule Runtime Deployment Model > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After on-premises runtime is licensed and started, deploy Mule application JAR files to `$MULE_HOME/apps`. This is the Start and deploy stage in [On-Premises Runtimes Overview](https://docs.mulesoft.com/on-premises/4.4/). You own the Mule runtime engine (Mule) instance on that host. [CloudHub](https://docs.mulesoft.com/cloudhub/), [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/), and [Anypoint Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/) manage the runtime instance for you. Start and stop commands are in [Start and Stop On-Premises Mule Runtime Engine](https://docs.mulesoft.com/on-premises/4.4/starting-and-stopping-mule-esb). ## Run Multiple Applications in One On-Premises 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. - You can share configurations across multiple applications by using domains. - Applications can depend on different library versions. - Multiple versions of an application can run within the same Mule instance. ## Package and Deploy Applications On-Premises 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`. The canonical name is `-anchor.txt` in `$MULE_HOME/apps`. Mule runtime engine deletes the original `.jar` from `/apps` after it unpacks a successful deploy. 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`. ## Share Resources with Domains A Mule domain shares connector configurations, such as an HTTP Listener, among applications on the same on-premises Mule runtime instance. Domains are not supported on CloudHub. Two applications cannot bind the same HTTP host and port in one runtime unless they share that listener through a domain. Copying a Studio project to on-premises runtime without a domain is the usual cause of `address already in use`. Create and package the domain project in Anypoint Studio. That authoring procedure is in [Shared Resources (Mule Domains)](https://docs.mulesoft.com/mule-runtime/latest/shared-resources). Deploy the domain JAR to `$MULE_HOME/domains` on the on-premises host. 1. Export the domain as a deployable JAR and copy it to `$MULE_HOME/domains`. 2. Export each application that references the domain and copy those JARs to `$MULE_HOME/apps`. 3. Start on-premises Mule runtime engine. The runtime deploys everything in `$MULE_HOME/domains` before anything in `$MULE_HOME/apps`. Applications that reference a domain fail to start if the domain JAR is missing or still deploying. By default an application uses the `default` domain. To share a port, point the application at your domain and keep the HTTP Listener configuration only in `mule-domain-config.xml`, not in each app. ## Hot-Deploy an Application 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. ## Continue Running After a Control Plane Disconnect Mule instances run independently from the control plane 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 control plane, 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. ## Troubleshoot Common Error Messages ### `address already in use` Two applications in the same on-premises Mule runtime instance are binding the same HTTP host and port. Put the shared listener in a domain, or change one application’s port. This error is expected when you copy a Studio project to on-premises runtime without a domain. ### `Unauthorized Access. Please verify that authToken is valid` A Maven or pipeline deploy to Runtime Manager (`standaloneDeployment` / ARM) used credentials the control plane rejected. User credentials with MFA do not work for this deploy path. Use a connected app. ## See Also - [On-Premises Runtimes Overview](https://docs.mulesoft.com/on-premises/4.4/) - [Start and Stop On-Premises Mule Runtime Engine](https://docs.mulesoft.com/on-premises/4.4/starting-and-stopping-mule-esb) - [Harden Your On-Premises Mule Runtime Engine Installation](https://docs.mulesoft.com/on-premises/4.4/hardening-your-mule-installation) - [Shared Resources](https://docs.mulesoft.com/mule-runtime/latest/shared-resources) - [Hybrid Standalone Runtimes](https://docs.mulesoft.com/hybrid-standalone/)