Deploying Mule Apps to Runtime Fabric

Anypoint Runtime Fabric enables you to deploy Mule applications and API Proxies to a Mule runtime engine that is managed on Runtime Fabric.

Supported Mule Runtime Server Versions

See Anypoint Runtime Fabric Runtimes Release Notes for information on supported versions of Mule runtime server.

Before You Begin Deploying Mule Apps

Before you deploy a Mule app or API proxy to Runtime Fabric:

Install and configure a Runtime Fabric.
Ensure that you understand how resources are allocated as described in Allocating resources for Application Deployment.

Publish your Mule app or API proxy to Exchange.

Before you deploy Mule apps and API proxies to Runtime Fabric, you must first publish them to Exchange. When you deploy Mule apps and API proxies from Runtime Manager, they are published to Exchange automatically.

Deployment Options

Use one of the following options to deploy Mule apps to Runtime Fabric:

Deploying a Mule App Using Runtime Manager
Use Runtime Manager to manually deploy Mule apps and API proxies.
Deploying a Mule App to Runtime Fabric using Maven (Mule 4)
Use Maven for managing and deploying a Mule application or API proxy.
Deploying and Managing Apps in Runtime Fabric Using the CLI
Use the Anypoint Platform CLI to deploy Mule applications

Deployment Considerations

Eventual consistency

Runtime Fabric is a self healing, eventually consistent platform. When building a CI pipeline for Runtime Fabric deployment, you must take eventual consistency into consideration. After triggering a deployment, the application status should become RUNNING. If the application status never indicates RUNNING, the replicas contain a state and reason to indicate why the application is not RUNNING.

Application Deployment

When an application is deployed, the following events occur:

The expected state of your application is stored, including application bundle and number of replicas.
The application replica status shows as PENDING.
When adequate compute and memory resources are available, each replica is attached to a node.
If not already present, a Docker image corresponding to the Mule Runtime version is downloaded.
The replica status shows as STARTING.
The replica finishes loading the application.
The replica status shows as STARTED and is able to perform work.

Exchange Asset Caching

When you deploy a Mule application, the runtime environment caches the application artifact using a key derived from its Maven coordinates: groupId, artifactId, and version. This cache improves deployment performance by avoiding redundant downloads from Exchange.

However, if you delete an Exchange asset and re-publish it under the same version (for example, 1.0.0), the cache has no visibility into whether the underlying artifact content has changed. As a result, deployments continue to use the previously cached artifact until that cache entry is evicted.

Re-publishing an Exchange asset under the same groupId:artifactId:version coordinates doesn’t update cached artifacts on existing deployment targets. Deployments on those targets continue to use the previously cached version.

To ensure that updated application artifacts are deployed correctly, use one of these approaches:

Increment the version number
Even a patch-level version bump (for example, from 1.0.0 to 1.0.1) produces a distinct cache key, ensuring the runtime fetches and caches the new artifact from Exchange.
Use the -SNAPSHOT qualifier
Appending -SNAPSHOT to the version (for example, 1.0.0-SNAPSHOT) signals that the artifact is mutable. The resource cache treats SNAPSHOT versions as non-cacheable and fetches directly from Exchange on every deployment. This approach is recommended during active development iterations.

Application Failure

If an application fails, for example, due to running of out memory, the following events occur:

The replica status shows as TERMINATED.
Runtime Fabric immediately attempts to restart the replica.
The replica status shows as RECOVERING.
If the replica is able to restart:
- The replica finishes loading the application.
- The replica status shows as STARTED and is able to perform work.
If the replica is initially unable to restart, for example, it relies on a network resource which temporarily unavailable, the following events occur:
- The replica status shows as PENDING, with a message indicating "CrashLoopBackoff". Runtime Fabric attempts to restart the replica, using exponential backoff to avoid an excessive number of restart attempts.
- The replica status alternates between RECOVERING and PENDING until the issue preventing a successful restart is resolved.
- The replica loads the application.
- After a successful restart, the replica shows as STARTED and is able to perform work.