Contact Us 1-800-596-4880
  1. Homepage

  2. On-premises Runtimes (4.11)

On-Premises Runtimes Overview

On-premises runtime is a Mule runtime engine (Mule) that you install and run on infrastructure you manage: a laptop, a virtual machine, or a data center host. You own the Java Virtual Machine, the file system, the Windows service or Linux daemon, Mule application deployment, licensing, and high availability. CloudHub, CloudHub 2.0, and Anypoint Runtime Fabric are separate runtime planes.

Choose On-Premises Runtime

Choose on-premises runtime when Mule applications must run on a host you manage. You install Mule, size CPU and RAM on that host, and deploy Mule application JAR files to $MULE_HOME/apps. You don’t need Anypoint Runtime Manager to start the runtime or to deploy Mule applications. Production use, clustering, and premium connectors require an Enterprise license.

Anypoint Studio already includes Mule for development and testing. Don’t download or install a separate on-premises runtime only to use Studio.

If the runtime plane is CloudHub, CloudHub 2.0, or Anypoint Runtime Fabric, deploy the Mule application there instead of installing on-premises runtime.

To have Anypoint Runtime Manager manage the instance, register the Runtime Manager agent. That instance is then a Hybrid Standalone Runtime.

To confirm the JDK, operating system, and hardware for this Mule version before you download, see Hardware and Software Requirements for On-Premises Mule Runtime Engine.

Complete the On-Premises Setup Path

Install and operate on-premises runtime in this order. Complete each stage before the next. Skip a stage only when that work already exists in your environment.

Stage Action References

Prerequisites

Confirm the JDK, architecture, RAM, and OS listed for this Mule version. Red Hat Enterprise Linux (RHEL) is tested; RHEL clones such as Rocky Linux are supported.

Hardware and Software Requirements

Download

Unpack the Enterprise zip. Set MULE_HOME. Run $MULE_HOME/bin/mule once in the console to prove the JVM starts.

Download, Install, Configure, and Upgrade

Service

Install as a Windows service or Linux daemon with mule install. That command doesn’t create a systemd unit named mule.service.

Start and Stop On-Premises Mule Runtime Engine

License

Stop the runtime. Install license.lic with mule -installLicense. An expired Enterprise license doesn’t restart. The Java Service Wrapper (Tanuki) license is a different key.

Install an Enterprise License

Wrapper

Point wrapper.java.command at the java executable, not at JAVA_HOME. Set heap, Metaspace, and wrapper.startup.timeout in wrapper.conf.

Configure the Java Service Wrapper

Start and deploy

Start with mule start. Copy Mule application JARs to $MULE_HOME/apps. Read status in $MULE_HOME/logs/mule_ee.log when the runtime runs as a service.

On-Premises Mule Runtime Deployment Model

Harden

Run as a non-root user, restrict file permissions, and configure TLS or FIPS before production.

Harden Your On-Premises Mule Runtime Engine Installation

Register (optional)

Register the Runtime Manager agent only if the control plane must manage this instance.

Hybrid Standalone Runtimes

Cluster (optional)

Cluster Enterprise nodes for failover. Supply your own load balancer.

Cluster On-Premises Mule Runtime Instances

Upgrade

Apply a patch or move to a later 4.x minor using the upgrade documentation.

Update, Upgrade, or Migrate Mule Runtime Engine

Operate Mule Applications on the Runtime

After on-premises runtime is running, you deploy Mule applications as JAR files into $MULE_HOME/apps. The runtime unpacks each JAR, creates a folder with the application name, writes an anchor file named <appName>-anchor.txt, and deletes the original JAR. One runtime instance can host many Mule applications. Mule applications don’t share classloaders, so they can depend on different library versions.

Two Mule applications in the same instance cannot bind the same HTTP host and port unless they share a listener through a domain. Domains aren’t supported on CloudHub. Copying a Studio project to an on-premises runtime without a domain is the usual cause of address already in use.

Hot deployment reloads an application when you update a configuration file declared in mule-artifact.json or touch the anchor file. Set mule.deployment.forceParseConfigXmls=true to pick up XML changes. Packaging validations don’t run on a hot deploy.

The Anypoint Platform control plane isn’t in the request path. Mule applications keep serving API and integration traffic if Runtime Manager is unreachable. New or updated policies aren’t pulled until the connection returns.

To package, hot-deploy, or share ports, see On-Premises Mule Runtime Deployment Model. To start, stop, or install the daemon, see Start and Stop On-Premises Mule Runtime Engine.

Plan Clustering and Disaster Recovery

An on-premises cluster groups two or more Mule nodes so they share memory, VM queues, and object-store data. Clustering is an Enterprise feature. A server group isn’t a cluster: Runtime Manager can deploy to a server group, but those nodes don’t share state. Server groups and Runtime Manager clusters are documented in Hybrid Standalone Runtimes.

An on-premises cluster doesn’t create a virtual IP. It doesn’t include a built-in load balancer. It doesn’t copy application artifacts from node to node. You deploy the same application to each node, or you deploy through Runtime Manager, and you put HTTP and TCP traffic behind a load balancer you supply.

High availability keeps serving traffic when a node fails. Disaster recovery restores infrastructure you back up after a site loss. Recovery time objective (RTO) and recovery point objective (RPO) are yours to set; MuleSoft keeps the control plane available and doesn’t store your business data.

See Also