Contact Us 1-800-596-4880

Mule Overview

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 runtime engine (Mule) is a lightweight integration engine that runs Mule apps. Users can build Mule apps to connect systems, services, APIs, and devices using MuleSoft’s API-led connectivity instead of point-to-point integrations. Mule apps provide functionality for message routing, data mapping, orchestration, reliability, security, and scalability.

With Mule you can:

  • Connect data to apps in Enterprise Service Bus (ESB) patterns.

  • Build APIs.

  • Access, query, and transform data through the DataWeave language.

  • Configure high-availability, clustering, and performance management at scale.

  • Deploy an integration worker, ESB or API gateway, on-premises or in the cloud.

  • Automatically manage thread pools with the self-tuning, reactive Mule runtime engine.

  • Use error constructs and try scopes for rapid debugging.

  • Isolate the classloader to protect Mule apps from changes to the runtime or connectors.

Installation, Deployment, Management

For a Mule app to run, it must be deployed into an environment where the Mule runtime engine is installed.

Mule is packaged within the Studio IDE and with Design Center on Anypoint Platform so that you can run a Mule app as you design it.

For production and pre-production deployments of Mule apps, you can use Runtime Manager to deploy Mule apps to runtimes within CloudHub and other supported platform as a service (PaaS) solutions.

  • CloudHub is a fully managed, Cloud-based integration platform as a service (iPaaS) for Anypoint Platform that enables you to run your Mule apps without requiring you to provide Mule runtimes or the infrastructure on which your apps run. You use Runtime Manager to deploy Mule apps to CloudHub, select the Mule runtime version, set the number of vCores needed to run the app, and so on.

  • Hybrid deployment models manage Mule apps and runtimes from the Cloud while running them in a datacenter that is managed by your company:

    • For remote Mule runtimes (also called standalone or "naked" Mules), you start Mule runtimes from your datacenter, but you can deploy and manage Mule apps from the Cloud, through Runtime Manager. In this deployment model, you provide the infrastructure and Mule runtime (see Mule Installation).

    • For a hybrid PaaS deployment, you set up and run the PaaS on your company’s datacenter and use Runtime Manager to manage Mule apps within the PaaS. In this case, you provision the infrastructure in which the apps run. To guarantee the high availability of Mule apps, you use Runtime Manager to handle Mule runtimes. MuleSoft also provides the built-in PaaS solution, Runtime Fabric, which runs Mule runtime engines in a "containerized" environment.

In addition to using Runtime Manager, you can perform deployments and manage Mule apps with Anypoint CLI 3.x, which includes commands for deployments and a number of Anypoint Platform use cases.

For more on deployment options, see Deployment Strategies.

Event-Driven Architecture

Mule works by responding to events that are initiated by external or internal resources. Mule works with a variety of sources, including listeners for external events, and schedulers for internally triggered events.

Mule processes events as messages through Event processors. Mule can also handle a high volume of messages in batches through Batch processors.

This behavior reflects Mule’s event-driven architecture (EDA). For more on this topic, see Mule Events.


Within a Mule app, event processing components are arranged into one or more container-like components, called flows.

Understanding basic flow architecture is key to understanding Mule. Essentially, every Mule flow contains a series of components that receive or process messages.

Simple Flow in Design Center
Figure 1. Simple Flow in Design Center

At the simplest level, flows are sequences of Event processors. A message that enters a flow can pass through a variety of processors. In a typical flow, a Mule app receives a message through an Event source (such as an HTTP listener), transforms that message into a new format, and processes any business logic before writing the processed message to an external system in a format that the system can read.

To break up processing into more manageable units, Mule apps often contain multiple, interrelated flows, instead of just a single flow. A flow can call another flow as a direct reference.

For more on this topic, see Flows and Subflows and Mule Applications.

Event Sources

An Event source (or trigger) is the first component in a flow. It receives a triggering event, creates a corresponding Mule event object, and forwards that event on for processing by the next component in the flow.

External clients can trigger processing in a Mule flow through a number of communication protocols and methods, such as JMS, HTTP, FTP, JDBC, or File. Mule translates these communication protocols and methods into a standard message format, which passes through the flow’s Event processors.

Event sources in Mule can connect to specific external sources, either through a standard protocol or a third-party API. It is also possible to set a Scheduler component. Some schedulers can poll for specific changes to external resources, such as new files or table rows in an external resource. Examples of listeners and connector operations that can trigger a flow include:

  • HTTP, JMS, VM listeners in their associated connectors

  • On Table Row operation in the Database connector

  • On New or Updated File operation in the File and FTP connectors

  • Scheduler

Note that you can also create your own Event source using the Mule SDK.

Event Processors

Once a flow is triggered through an Event source, subsequent components process the Mule event as it travels through the flow. By default, each Event processor that receives a Mule event returns a new Mule message, typically with a set of attributes and the message payload that the processor returns. The processor passes on the new message as output to the next processor in the flow.

Event processors available to Mule apps include:

  • Operations from modules and connectors. Examples include reading from and writing to an external resource and validating data in the Mule app.

    Some operations can make client requests to external resources and services (including external databases and systems, such as Salesforce, Workday, ServiceNow, and many others) and to other Mule apps. Others can run your custom code, support OAuth configurations, and handle communication through asynchronous queues, for example. A variety of other operations are available.

  • Core components can route data, perform data transformations, handle errors that might occur when processing the event, and perform other tasks in a Mule app.

    Transformers (such as the Transform Message, Set Variable, and others) are key to exchanging data between nodes. Transformers enable Mule to convert message data in the Mule event to a format that another app or service can read.

    Mule also enables content enrichment of messages (through Target Parameters) so that you can retrieve additional data and attach it to the message.

Note that you can also create your own Event processors using the Mule SDK.

For more on this topic, see Core Components and Connectors and Modules.

Anypoint Studio and Design Center

You can design Mule apps in Anypoint Studio, in Design Center, or even with handwritten XML. Studio and Design Center UIs represent message processors as icons within flow components. Studio also represents them as XML elements in a Configuration XML.

For more on this topic, see Mule Flow Design (Design Center) and Anypoint Studio.


DataWeave is the primary language used for formulating expressions in Mule. Within fields of many message processing components, in addition to the Transform Message component, you can use DataWeave to access, manipulate, transform, and extract data from the Mule event.

At runtime, Mule evaluates expressions while executing a flow to:

  • Extract data needed to process the current message.

  • Set or manipulate a value in the message.

For more on this topic, see DataWeave Language.

Batch Processing

Mule supports batch jobs, which split messages into individual records, act on each record, then report the results and, if necessary, push the processed output to other systems or queues. This functionality is particularly useful when working with streaming input or when engineering "near real-time" data integration between SaaS applications.

Studio and Design Center provide various batch components that you can use to configure batch processes. For more on this topic, see Batch Processors.

API Gateway

Mule Runtime includes an embedded API Gateway, which enables you to apply security policies to an API, enrich incoming or outgoing messages, and add capabilities to an API without having to write any code. See API Gateway for information on the Mule runtime engine in the API Manager documentation.

Non-blocking Execution Engine

The Mule execution engine is based on a non-blocking runtime. This is a task-oriented execution model that allows you to take advantage of non-blocking IO calls and to make tuning configurations in a simple way.

Flows always function synchronously. If you need to achieve asynchronous patterns, such as Fire-and-Forget, you can use the Async (<async>) component.

Mule Event processors indicate to the runtime whether they are CPU intensive, CPU light, or IO intensive operations. These workload types help the runtime tune for different workloads, removing the need for you to manage thread pools manually to achieve optimum performance. Instead, the runtime introspects the available resources (such as memory and CPU cores) in the system to tune thread pools automatically.

For more detailed documentation on the execution engine, threading model, and tuning options, see Execution Engine.

Mule Versioning

The Mule version you use determines what your Mule app can do and what features and products are compatible with Mule. Core components, which process the Mule event as it travels through flows in a Mule app, are part of a Core module that is bundled with and shares the same version as Mule. Modules, connectors, the DataWeave language, and a number of MuleSoft products have their own versioning system but are compatible with specific versions of Mule. For example, DataWeave 2.0 and Studio 7.x are compatible Mule 4.x runtimes, while DataWeave 1.0 and Studio 6.x are compatible with Mule 3.x runtimes. You need to make sure the connector or module you use in a Mule app is compatible with your Mule version.