MuleSoft Deployment Options
MuleSoft applications run on the Mule Runtime Engine and can be deployed in several ways depending on your infrastructure preferences, security requirements, and budget. Choosing the right deployment option is one of the most important architectural decisions for your integration platform.
Overview of Deployment Options
Deployment Options Comparison
┌─────────────────┬──────────────┬──────────────┬──────────────┐ │ Option │ Who Manages │ Mule Runtime │ Best For │ │ │ Servers │ Location │ │ ├─────────────────┼──────────────┼──────────────┼──────────────┤ │ CloudHub │ MuleSoft │ MuleSoft │ Fast start, │ │ │ │ AWS Cloud │ no Ops team │ ├─────────────────┼──────────────┼──────────────┼──────────────┤ │ CloudHub 2.0 │ MuleSoft │ MuleSoft │ Container- │ │ │ │ Containers │ based, modern│ ├─────────────────┼──────────────┼──────────────┼──────────────┤ │ Runtime Fabric │ You │ Your K8s │ Full control,│ │ │ │ Cluster │ any cloud │ ├─────────────────┼──────────────┼──────────────┼──────────────┤ │ On-Premises │ You │ Your servers │ Max control, │ │ │ │ │ air-gapped │ └─────────────────┴──────────────┴──────────────┴──────────────┘
CloudHub (Original)
CloudHub is MuleSoft's fully managed iPaaS (Integration Platform as a Service). MuleSoft provisions servers, manages the Mule Runtime, handles backups, and applies security patches. You deploy your application JAR file and CloudHub does the rest.
CloudHub Key Concepts
- Workers: The virtual machines running your application. You choose the size (0.1 vCore to 8 vCores) and the number (1 to 8 workers).
- vCore: A measure of computing capacity. 0.1 vCore suits very light workloads. 1 vCore handles most production APIs. 2+ vCores serve heavy batch jobs.
- Region: The geographic location of the servers. Choose a region close to your users or your backend systems to reduce latency.
- Persistent Queues: Durable message queues built into CloudHub for reliable async messaging between workers.
CloudHub Architecture
Anypoint Platform (MuleSoft-managed)
┌─────────────────────────────────┐
Your Laptop │ CloudHub Region: US-East-1 │
[Studio] ────deploy──►│ │
│ Worker 1: orders-api │
Client Requests ─────►│ Worker 2: orders-api (HA) │
│ │
│ [Load Balancer] │
│ [Object Store] │
│ [Anypoint Monitoring] │
└─────────────────────────────────┘
CloudHub 2.0
CloudHub 2.0 is the next-generation managed runtime built on Kubernetes containers. Unlike the original CloudHub (which used dedicated VMs per app), CloudHub 2.0 runs multiple applications on shared container infrastructure, making it more efficient and faster to scale.
Key differences from original CloudHub:
- Container-based instead of VM-based
- Faster deployment (seconds instead of minutes)
- More granular resource allocation (millicores and MB of memory)
- Supports private spaces with VPN integration
Runtime Fabric
Runtime Fabric (RTF) lets you run the Mule Runtime on your own Kubernetes cluster — on AWS EKS, Azure AKS, Google GKE, or on-premises Kubernetes. You manage the cluster. MuleSoft provides the Mule Runtime containers and the Anypoint control plane.
When to Use Runtime Fabric
- Data sovereignty requirements — data must not leave your country or cloud account
- Existing Kubernetes expertise and infrastructure you want to leverage
- Need to run MuleSoft alongside other workloads on the same cluster
- Cost optimization — use existing cloud compute instead of paying CloudHub per-vCore
Runtime Fabric Architecture
Anypoint Platform (MuleSoft-managed, cloud control plane)
│ deploy, monitor, manage
▼
Your Kubernetes Cluster (you manage this)
├── Node 1 (e.g., AWS EC2 m5.2xlarge)
│ [RTF Controller Pod]
│ [orders-api Pod]
│ [customer-sync Pod]
│
├── Node 2
│ [orders-api Pod] ← replica for HA
│ [inventory-api Pod]
│
└── Node 3
[orders-api Pod] ← another replica
On-Premises Deployment
On-premises deployment runs the Mule Runtime on your own physical servers or VMs in your own data center. You download the Mule Runtime, install it, and deploy application JAR files manually or via the Anypoint Runtime Manager agent.
On-Premises Use Cases
- Air-gapped environments with no internet access
- Government or financial regulations requiring on-premises processing
- Integration with legacy systems that can only communicate on a private network
- Very high security environments where cloud is not permitted
Hybrid Deployment
Many enterprises use a hybrid model: APIs facing the internet run on CloudHub for easy management. Integrations with sensitive internal systems run on-premises to keep data within the corporate network. Both are managed from the same Anypoint Platform control plane.
Hybrid Architecture Diagram
Internet
│
▼
[Experience APIs on CloudHub] ← MuleSoft managed, public-facing
│
│ (calls internal APIs via VPN or Anypoint VPN)
▼
[Process APIs on On-Premises Mule] ← runs in corporate data center
│
├── [SAP system — direct network access]
├── [Oracle database — direct JDBC]
└── [Mainframe — direct MQ connection]
Choosing the Right Option
Decision Guide
Question Recommendation ----------------------------------------------|------------------ No dedicated Ops team, need fast start? → CloudHub Need containers and modern K8s approach? → CloudHub 2.0 Own Kubernetes infrastructure already? → Runtime Fabric Data must stay in your cloud account? → RTF on your cloud Fully air-gapped, no internet? → On-Premises Mix of internet-facing and internal APIs? → Hybrid