Contact Free trial Login

About CloudHub Architecture

CloudHub has been built from the ground up to provide enterprises with a multi-tenant, secure, elastic, and highly available integration platform as a service (iPaaS). This document describes how the underlying mechanisms of the CloudHub platform work to achieve these goals.

Manage CloudHub with the Runtime Manager console in the Anypoint Platform. You can also deploy to it directly from Anypoint Studio, via the CloudHub API or via the Anypoint Platform Command Line Interface (Anypoint CLI).

See Deployment Strategies for a better understanding of the different possible deployment scenarios, including on-premises and Anypoint Platform Private Cloud Edition (Anypoint PCE).

CloudHub Architecture

To understand CloudHub’s approach to security and availability, it’s important to understand the architecture behind CloudHub. It includes two major components—​Anypoint platform services, and the worker cloud. These two components and the Runtime Manager console through which you access them work together to run your integration applications.

architecture diagram

These are applications that you create and deploy to CloudHub to perform integration logic for your business.

blue 1

The Runtime Manager console is the face of CloudHub, allowing you to deploy and monitor integrations, and configure your account, among other things.

blue 2

This set of shared CloudHub platform services and APIs includes CloudHub Insight, alerting, logging, account management, virtual private cloud/secure data gateway, load balancing, and others.

blue 3

This is an elastic cloud of Mule instances that run integration applications.

You can view the live status and detailed service history for the Runtime Manager console, platform services, and the CloudHub worker cloud on for the default (US hosted) Control Plane and for the EU Control Plane.

Integration Applications

An integration application is any integration that you’ve built using Anypoint Studio. These applications can do everything from synchronizing data from Salesforce to a database, to publishing a SOAP or REST API, to creating complex orchestrations of business processes.

For more about creating and deploying integration applications, see CloudHub and Deploying to CloudHub.

Runtime Management Console

The Runtime Manager console is integrated into the Anypoint Platform. Sign in with your Anypoint Platform credentials to upload and manage your integration applications at runtime. The console surfaces useful monitoring information from the platform services and also works as a comprehensive dashboard for both application-level and account-level management.

Through this same console you can deploy to CloudHub as well as to other registered servers. You can also manage deployed applications.

Administrator account holders can use the Anypoint Platform to add and manage other users in the organization, define user roles, and create and manage sandbox environments.

For more general information about CloudHub, see CloudHub.

Platform Services

CloudHub’s platform services are responsible for coordinating all aspects of the platform. They coordinate deployment of applications, monitor integrations, provide analytics data, store application data, run scheduled jobs, and more. Many of these services are also exposed through the CloudHub REST API.

CloudHub Workers

Applications on CloudHub are run by one or more instances of Mule, called workers. These have the following characteristics:

  • Capacity: Each worker has a specific amount of capacity to process data, you can select the size of your workers when configuring an application.

  • Isolation: Each worker runs in a separate container from every other application.

  • Manageability: Each worker is deployed and monitored independently.

  • Locality: Each worker runs in a specific worker cloud, the US, EU, Asia-Pacific, etc.

Each worker is a dedicated instance of Mule that runs your integration application. Workers may have a different memory capacity and processing power depending on how you configure them at application level. Workers can be scaled vertically by selecting one of the available worker sizes:

Worker Sizes:

  • 0.1 vCores + 500 MB Heap Memory

  • 0.2 vCores + 1 GB Heap Memory

  • 1 vCores + 1.5 GB Heap Memory

  • 2 vCores + 3.5 GB Heap Memory

  • 4 vCores + 7.5 GB Heap Memory

  • 8 vCores + 15 GB Heap Memory

  • 16 vCores + 32 GB Heap Memory

Along with less available memory, workers that use a fraction of a vCore have more limited CPU and IO, which are usually only appropriate for smaller workloads.

With CloudHub Fabric, you can also scale your applications horizontally by adding multiple workers and load distribution over queues. For more information about scaling workers, see Worker Scaleout. For more information about using persistent queues on CloudHub, see Persistent Queues.

You can monitor your workers and verify that they are all operating well. You can also enable automatic restarts in case any issue occurs with one.

Global Worker Clouds

CloudHub offers worker clouds in 12 different regions of the world: North America, South America, the European Union, and Asia-Pacific. This global distribution allows you to host your integration in a location that is closest to your services, thus reducing latency. It may also allow you to adhere with local laws, such as the EU Data Protection Directive. The management console and platform services are hosted in the United States.

The complete list of supported regions is:

Region Sub-Domain

US East (North Virginia)

US East (Ohio)

US West (Oregon)

US West (North California)

Canada (Central)

Brazil (Sao Paulo)

Europe (Ireland)

Europe (Frankfurt)

UK (London)

Asia Pacific (Tokyo)

Asia Pacific (Sydney)

Asia Pacific (Singapore)

The domain provided for your application is based on the region your application is deployed to. For example, if you deploy an application named myapp to Canada (Central), the domain used to access the application is The load balancer used to route requests resides in the same region as your application.

For more information about deploying applications to different regions, refer to Deploying to CloudHub. For more information about CloudHub’s security and compliance, download the Anypoint Cloud Security & Compliance whitepaper.

Workers and Multitenancy

Because different levels of security and isolation are needed depending on the service, the platform provides two different levels of multitenancy.

  • First, the worker cloud is a multitenant cloud of virtual machines. These VMs provide the security and isolation needed for your integrations to run custom code without affecting others.

  • Second, the management console and the platform services have a "shared everything" architecture – all tenants share the same web UI, monitoring services, load balancers, etc. These services do not process or transmit your data.

CloudHub Availability and Scalability

CloudHub has been designed to be highly available and scalable through redundancy, intelligent healing, and zero downtime updates. It also provides customers with the ability to scale and have added reliability through CloudHub Fabric.

Redundant Platform

All of CloudHub’s platform services, from load balancing to the API layer, have at least one, built-in layer of redundancy and are available in at least two data centers at all times. All data centers are at least 60 miles apart. This redundancy ensures that even if there is a data center outage, the platform remains available.

Intelligent Healing

CloudHub monitors the worker clouds for any type of problems and provides a self-healing mechanism to recover from problems. If the underlying hardware suffers a failure, the platform migrates your application to a new worker automatically. In the case of an application crash – whether due to a problem with custom code or a bug in the underlying stack – the platform recognizes the crash and can restart the worker automatically.

For more information about application monitoring and automatic restarts, see Worker Monitoring.

Zero Downtime Updates

CloudHub supports updating your applications at runtime so end users of your HTTP APIs experience zero downtime. While your application update is deploying, CloudHub keeps the old version of your application running. Your domain points to the old version of your application until the newly uploaded version is fully started. This allows you to keep servicing requests from your old application while the new version of your application is starting.

CloudHub Fabric

CloudHub Fabric provides scalability, workload distribution, and added reliability to applications on CloudHub. These capabilities are powered by CloudHub’s scalable load-balancing service, CloudHub Fabric worker scaleout, and persistent queueing features.

Worker Scale-Out and Data Center Redundancy

With CloudHub Fabric, you can add multiple workers to your application to make it horizontally scale. This also adds additional reliability. CloudHub automatically distributes multiple workers for the same application across two or more datacenters for maximum reliability.

When deploying your application to two or more workers, the HTTP load balancing service distributes requests across these workers, allowing you to scale your services horizontally. Requests are distributed on a round-robin basis.

Persistent Queues

Persistent queues ensure zero message loss and allow you to distribute non-HTTP workloads across a set of workers. For example, if your application is deployed to more than one worker, persistent queues allow interworker communication and workload distribution. If a large file is placed in the queue, your workers can divide it up and process it in parallel.

Persistent queues also guarantee delivery of your messages; even if one or more workers or datacenters go down, persistent queues facilitate disaster recovery and provide resilience to hardware or application failures.

For more details about worker scale-out and persistent queues, refer to CloudHub Fabric.


CloudHub architecture provides a secure platform for your integrations.

Securing your payload data is critically important. To this end, CloudHub does not inspect, store, or otherwise interact directly with payload data. CloudHub workers provide a secure facility for transmitting and processing data by giving each application its own virtual machine. This ensures complete isolation between tenants for payload security, and isolation from other tenants’ code.

CloudHub collects monitoring, analytics, and log data from CloudHub workers and may perform actions on behalf of the user on CloudHub workers. All communication between CloudHub platform services and the worker cloud is secured using SSL with client certificate authentication. This ensures that unauthorized parties cannot read data and that they cannot initiate unauthorized actions.

Secure properties can also be loaded as part of your application bundle. If a property is flagged as secure, it won’t be viewable even through the Runtime Manager console, in fact, it is never propagated anywhere outside the CloudHub worker running the application.

For more information about MuleSoft’s approach to security, please see the Anypoint Cloud Security & Compliance whitepaper.

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.