Mulesoft offers multiple deployment models to cater to varying organizational requirements, including CloudHub, on-premises, and hybrid approaches. Each model affects scalability, maintenance, and governance.
CloudHub is Mulesoft's fully managed integration platform-as-a-service (iPaaS), providing automatic scaling, monitoring, and simplified management without infrastructure overhead. It suits cloud-first organizations seeking rapid deployment.
On-premises deployment allows full control over runtime, security, and network configurations. Organizations with strict compliance or latency requirements often prefer this model, though it requires dedicated infrastructure management.
Hybrid deployment combines CloudHub and on-premises runtimes, enabling organizations to leverage cloud benefits while maintaining control over sensitive workloads locally. It provides flexibility for complex integration landscapes.
Choosing the right deployment model depends on business priorities, technical constraints, and long-term maintainability. Factors like cost, compliance, operational overhead, and integration complexity should guide the decision.
CloudHub is a fully managed cloud-based integration platform where Mulesoft handles infrastructure, scaling, and updates. Users focus on building and deploying APIs without managing servers.
On-premises deployment gives organizations control over runtime environments, security configurations, and network topology. It requires internal teams to manage servers, updates, and scaling manually.
In practice, CloudHub reduces operational overhead and accelerates deployment, while on-premises may be preferred for compliance, latency-sensitive, or legacy system integrations.
Hybrid deployment involves using both CloudHub and on-premises runtimes. The design must address data flow, latency, and network connectivity between cloud and local systems.
Security is critical; sensitive data may need to remain on-premises while less sensitive workloads run in the cloud. Organizations should implement consistent policies across both environments.
Operational monitoring should integrate both runtimes, ensuring visibility and consistent alerting. Deployment pipelines need to accommodate differences in packaging, versioning, and dependency management.
An organization dealing with financial data under strict compliance regulations may be restricted from sending sensitive data to the cloud. CloudHub alone cannot satisfy this requirement.
Latency-sensitive systems like real-time trading platforms may not tolerate cloud-induced delays. Deploying runtimes closer to core systems on-premises mitigates this issue.
A hybrid model allows non-sensitive APIs and integration flows to run in CloudHub for scalability, while sensitive workloads remain on-premises, balancing compliance, performance, and operational efficiency.
CloudHub, On-Premises, and Hybrid are supported Mulesoft deployment models. Serverless Lambda is an AWS compute service, not a Mulesoft deployment option.
On-premises deployment is suitable when compliance or low-latency access to local systems is critical. CloudHub is preferable for automated scaling and reducing IT management overhead.
Deployment decisions should consider operational overhead, complexity of integrations, and regulatory requirements. UI theme or superficial preferences are irrelevant to deployment strategy.
This snippet sets up an HTTP listener on port 8081. On CloudHub, Mulesoft automatically assigns workers and manages network configuration, simplifying deployment.
The logger captures incoming requests for monitoring and debugging purposes.
// XML
<http:listener-config name="HTTP_Listener_config" host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration"/>
<flow name="cloudhubFlow">
<http:listener doc:name="Listener" config-ref="HTTP_Listener_config" path="/api"/>
<logger level="INFO" doc:name="Logger" message="Received request"/>
</flow>This YAML config shows a hybrid setup where an on-premises Mule runtime communicates securely with CloudHub using a VPN.
The configuration specifies VPN credentials and endpoints, ensuring secure and reliable integration between cloud and local systems.
# YAML
mule:
hybrid:
vpn:
name: "onPremVPN"
endpoint: "10.0.0.5"
authentication:
username: "vpnUser"
password: "vpnPassword"
flows:
- name: onPremFlow
source: http:listener
path: /local
logger: "Processing request locally"This flow uses a Choice router to dynamically send sensitive payloads to the on-premises runtime while sending non-sensitive data to CloudHub.
It demonstrates real-world routing decisions based on security and compliance needs.
// XML
<flow name="dynamicRoutingFlow">
<choice doc:name="Route Based on Payload">
<when expression="#[payload.type == 'sensitive']">
<flow-ref name="onPremFlow"/>
</when>
<otherwise>
<flow-ref name="cloudHubFlow"/>
</otherwise>
</choice>
</flow>This DataWeave script conditionally transforms the payload. Sensitive data is processed (here, simply uppercased for demonstration) before routing to on-premises runtime, while other data is passed through.
Such transformations are crucial in hybrid deployments to enforce security and data handling policies dynamically.
// DataWeave
%dw 2.0
output application/json
var input = payload
---
if (input.sensitive) {
{
id: input.id,
encryptedData: upper(input.data)
}
} else {
input
}CloudHub provides a fully managed environment where Mulesoft handles infrastructure, scaling, patching, and monitoring. This reduces operational overhead for organizations.
It allows easy deployment of APIs and integration flows with minimal configuration, enabling faster time-to-market.
CloudHub supports high availability and automatic failover, ensuring that integration services remain resilient without manual intervention.
In a hybrid setup, sensitive workloads may remain on-premises to comply with regulatory or organizational policies. Ensuring proper VPN or private connectivity is critical.
Data in transit between CloudHub and on-premises should be encrypted, and access control policies must be consistent across both environments.
Hybrid deployments require rigorous monitoring to detect anomalies or unauthorized access attempts, ensuring data protection and compliance.
Each CloudHub worker represents a dedicated runtime for API execution. Choosing the correct worker size affects memory allocation, throughput, and response time.
Oversized workers can increase operational costs unnecessarily, while undersized workers may cause slow response times or request queuing.
Proper sizing requires load testing and monitoring, balancing performance with cost efficiency to ensure production SLAs are met without excessive resource usage.
CloudHub provides automatic scaling, managed updates, and built-in monitoring. Full server-level customization is only possible with on-premises deployments.
Hybrid deployments are selected based on latency, compliance, and integration complexity. UI preferences do not affect deployment model decisions.
On-premises deployment is ideal when compliance, latency, and infrastructure control are top priorities. Auto-scaling without infrastructure management is a benefit of CloudHub, not on-premises.
This configuration can be deployed on CloudHub with multiple workers assigned in the deployment settings to ensure high availability and fault tolerance.
Multiple workers allow requests to be processed in parallel, improving performance under load.
// XML
<http:listener-config name="HTTP_Listener_config" host="0.0.0.0" port="8081"/>
<flow name="highAvailabilityFlow">
<http:listener config-ref="HTTP_Listener_config" path="/api"/>
<logger message="Request received" level="INFO"/>
</flow>This configuration defines a VPN for secure communication between CloudHub and on-premises runtimes.
Flows routed over this VPN ensure sensitive data remains protected during transit.
// XML
<mule>
<hybrid:vpn name="OnPremVPN" endpoint="10.0.0.10" username="vpnUser" password="vpnPass"/>
<flow name="secureHybridFlow">
<http:listener path="/secure" config-ref="HTTP_Listener_config"/>
<logger message="Processing secure hybrid request" level="INFO"/>
</flow>
</mule>This script checks the 'region' field in the payload to dynamically route messages to the appropriate runtime.
It supports multi-region hybrid deployment strategies, optimizing performance and compliance.
// DataWeave
%dw 2.0
output application/json
---
if (payload.region == "EMEA") {
{ route: "onPrem", data: payload }
} else {
{ route: "cloudHub", data: payload }
}This Choice router dynamically directs sensitive data to on-premises flows and non-sensitive data to CloudHub.
It demonstrates conditional routing crucial for hybrid deployments with compliance requirements.
// XML
<flow name="sensitivityBasedRouting">
<choice doc:name="Route Based on Sensitivity">
<when expression="#[payload.sensitive == true]">
<flow-ref name="onPremFlow"/>
</when>
<otherwise>
<flow-ref name="cloudHubFlow"/>
</otherwise>
</choice>
</flow>Many enterprises still depend on legacy systems hosted within private networks that cannot be exposed externally due to compliance or technical limitations. Moving those integrations entirely to the cloud may introduce latency, security risks, or operational dependencies that are difficult to justify.
Certain industries such as healthcare, banking, and government operate under strict regulations that require sensitive data processing to remain within internal infrastructure. In such cases, on-premises Mule runtimes provide tighter control over networking, firewall policies, and audit mechanisms.
Another practical reason is operational predictability. Organizations with mature infrastructure teams sometimes prefer managing runtimes internally because they already have monitoring, backup, and disaster recovery standards deeply integrated into their existing systems.
Deployment topology determines how far requests must travel between systems. If a Mule application deployed in CloudHub frequently communicates with an on-premises database through VPN tunnels, network latency can significantly affect response time.
Architects often place latency-sensitive APIs closer to backend systems. For example, APIs handling real-time warehouse scanning or financial transaction validation may run on-premises to minimize network hops and reduce timeout risks.
Topology also affects resilience. Poorly designed hybrid deployments can create bottlenecks where all traffic depends on a single VPN gateway or firewall path. Distributed deployment planning becomes critical for maintaining predictable API performance.
Organizations running CloudHub, Runtime Fabric, and on-premises deployments together often face fragmented monitoring and inconsistent deployment processes. Different environments may require separate scaling strategies, logging approaches, and operational procedures.
Release coordination becomes more difficult because deployment pipelines must support different runtime behaviors. A deployment that works correctly in CloudHub may behave differently on a customer-managed runtime due to infrastructure dependencies or networking differences.
Security governance also becomes harder to standardize. Teams must ensure certificate rotation, firewall rules, secret management, and runtime patching remain consistent across all deployment models. Without centralized governance, operational drift becomes a serious long-term risk.
CloudHub is a managed integration platform where infrastructure responsibilities such as runtime provisioning, patching, and scaling are handled by Mulesoft.
On-premises, standalone runtimes, and bare metal deployments require internal infrastructure ownership and operational management.
Hybrid deployment is commonly chosen when organizations need to modernize incrementally while retaining sensitive systems internally.
Public-facing APIs may benefit from cloud scalability, while regulated or latency-sensitive integrations remain on-premises.
Hybrid deployments can become unstable when traffic depends heavily on a single network path or when runtime maintenance standards differ across environments.
Monitoring fragmentation is also common because cloud and on-premises systems may use separate observability stacks.
This flow exposes a lightweight HTTP endpoint suitable for CloudHub deployment. CloudHub automatically handles worker provisioning and public endpoint exposure.
The logger helps operations teams validate traffic flow and monitor API invocation activity after deployment.
// XML
<http:listener-config name="httpConfig" host="0.0.0.0" port="8081" />
<flow name="cloudhubApiFlow">
<http:listener config-ref="httpConfig" path="/orders" />
<set-payload value='#[{"status": "CloudHub deployment active"}]' />
<logger level="INFO" message="CloudHub API invoked" />
</flow>Externalizing deployment properties simplifies movement between CloudHub, Runtime Fabric, and on-premises environments without modifying application logic.
This approach also improves operational governance because infrastructure-specific values remain separated from implementation code.
# YAML
http:
host: "0.0.0.0"
port: "8081"
database:
host: "db.internal.company"
port: "1521"
username: "muleuser"
runtime:
deploymentModel: "hybrid"This router enables region-aware deployment processing. Requests originating from different regions can be directed to specific runtimes based on compliance or latency requirements.
Regional routing is commonly used in multinational deployments where data residency laws require processing within specific geographic boundaries.
// XML
<flow name="regionalDeploymentRouter">
<choice>
<when expression="#[attributes.headers.region == 'US']">
<flow-ref name="usCloudHubFlow" />
</when>
<when expression="#[attributes.headers.region == 'EU']">
<flow-ref name="euOnPremFlow" />
</when>
<otherwise>
<flow-ref name="defaultProcessingFlow" />
</otherwise>
</choice>
</flow>This script dynamically enriches payloads based on deployment context. Operational metadata can help downstream systems apply different auditing or processing policies.
In enterprise integrations, deployment-aware transformations are often used for observability, compliance tagging, and traffic classification.
// DataWeave
%dw 2.0
output application/json
var deploymentType = vars.runtimeType default "cloud"
---
if (deploymentType == "onprem")
{
environment: "internal-runtime",
auditRequired: true,
payload: payload
}
else
{
environment: "cloudhub-runtime",
auditRequired: false,
payload: payload
}