CloudHub Networking Guide

logo cloud active logo hybrid disabled logo server disabled logo pcf disabled

The topics in this document deal only with cloud deployments via the cloud-based version of the Runtime Manager. See Deployment Strategies for a better understanding of the different possible deployment scenarios.


CloudHub provides a variety of tools to architect your integrations and APIs so that they are maintainable, secure, and scalable. This guide covers the basic network architecture, DNS, and firewall rules.


Load Balancing

CloudHub provides a load balancing service for all integrations, you can use the default one or obtain the dedicated load balancer.

This service does round robin load distribution across workers, allowing workers to scale linearly as they receive more requests as well as providing transparent switchover when an application is upgraded (see zero downtime upgrades for more information).

Each application deployed on CloudHub has a CNAME record that refers to the load balancer - example: Mule applications deployed on CloudHub must listen on and ports assigned by CloudHub for HTTP and HTTPS. The load balancer then forwards requests from port 80 and 443 (SSL) to these ports on the Mule worker. Forwarded traffic is still HTTP & HTTPS, this means that you can’t listen for HTTPS on ${http.port} nor for plain HTTP on ${https.port}.
These ports must be referenced using the reserved properties ${http.port} and ${https.port} respectively, so CloudHub services can then dynamically allocate a port at deployment time.

Here is an example of a Mule configuration that utilizes this to expose an HTTPS endpoint:

<http:listener-config name="HTTP_Listener_Configuration" protocol="HTTPS" host="" port="${https.port}" doc:name="HTTP Listener Configuration" >
                <tls:context name="TLS_Context_Custom_Keystore" doc:name="TLS Context">
                        <tls:key-store type="jks" path="server.jks" keyPassword="keypassword" password="storepassword" alias="cloudhubworker" />

You may also refer to this knowledge-base article: Sample App: Configuring HTTPS endpoint for deployment in CloudHub

Important: On the Mule worker, the CloudHub load balancer proxies port :80 to :8081 for HTTP and proxies port :443 to :8082 for HTTPS.
The http.port property is automatically set to port 8081 for HTTP, and https.port is set to port 8082 for HTTPS. If other values for http.port and https.port are specified in the file, these are overwritten at deployment time.

For each request that a client makes through CloudHub’s load balancer (, the load balancer maintains two connections. One connection ​from​ the client and one to your Worker. For each connection, the load balancer manages an idle timeout of 300 seconds that is triggered when no data is sent over ​either​ connection. If no data has been sent or received during this time period, the load balancer closes ​both connections.

For connections that take more than 300 seconds to be processed from either side, consider handling the processing asynchronously.

DNS Records

The following DNS records are exposed for your applications when deployed to CloudHub:

Load balancer. Ports 80 and 443 forward to  ${http.port} and ${https.port} respectively.

The external IP address of the Mule workers. HTTP services are exposed on: ${http.port} and ${https.port}

The internal IP address of the Mule workers. The IPs for this DNS record are only accessible within a customer’s private VPC. These IPs are not accessible for workers running in the MuleSoft shared VPC. Public HTTP services are exposed on ${http.port} and ${https.port}. Internal HTTP services are exposed on ports 8091/8092.

In certain situations, you may want to know an application’s internal IPs:

  • When communicating with the worker directly within the customer’s VPC without sending data over the public internet

  • When you wish to setup your own load balancer (see below)

These IP addresses can be accessed through the record, from within the customer’s VPC. If you access the workers directly, any load distribution benefits from the CloudHub load balancing layer are lost.

IP Ranges and Static IPs

As CloudHub deploys on Amazon EC2, IP addresses are chosen from the Amazon EC2 IP pool. For a list of these ranges, please consult Amazon AWS IP Address Ranges API. The download link in that page will retrieve a dynamically generate JSON representation of all ranges that include the region. Note that Amazon may change the ranges without notice so you may want to update this information regularly.

CloudHub supports allocating a static IP for applications so that they can be whitelisted for other services. To enable a static IP for your application, go to the Static IPs tab in the application settings page on the Runtime Manager UI, then enable the Use Static IP checkbox. By default, you are allocated a number of static IPs equal to twice the number of Production vCores in your subscription. To increase this limit, contact MuleSoft Support. After a static IP has been allocated for your application, it is visible in the Static IPs tab in the application settings. For more details, see Deploying to CloudHub.

Static IPs are not supported for private IP addresses inside a CloudHub VPC.

Sometimes firewalls or infrastructure settings don’t let Mule runtimes reach the Runtime Manager’s public services. This might be an issue when registering a Mule runtime or when starting it and registering it to work with Runtime Manager.

If you need to whitelist the IPs for the communication between the Runtime Manager Agent and the Runtime Manager console, see IPs to Whitelist.

You can assign Static IP to applications with multiple workers. However, it is not possible to pre-allocate static IPs for multiple workers. In case of multiple workers, IP addresses are automatically allocated.

Regional Services

Depending on what region you deploy your application in, the DNS record and the load balancer for your integration may change. The following table summarizes what DNS record are available for your application for each region:

DNS Record Regions

US East (N. Virginia)

US East (Ohio)

US West (N. California),

US West (Oregon)

Canada (Central)

South America (Sao Paulo)

Asia Pacific (Singapore)

Asia Pacific (Sydney)

Asia Pacific (Tokyo)

EU (Ireland)

EU (Frankfurt)

EU (London)

Deploying to a region also affects your internal and external worker DNS address. For example, if you deploy in Europe, the DNS records for internal and external IPs are and

Firewall Rules and Port Access

The only two ports exposed externally are ${http.port} and ${https.port} (by default 8081 and 8082 respectively). If you wish to access other ports, you can do so through the Anypoint Virtual Private Cloud (VPC) offering.

If you wish to expose HTTP services only inside a VPC, these services can be exposed on ports ${http.private.port} ${https.private.port} (8091 and 8092 respectively), which are open by default on the internal network. In this case, these services are not accessible on the public IPs or the load-balancer, ensuring that they can be accessed securely.

While the ports in your VPC for 8091 & 8092 are already open, your Mule application needs to be configured so its HTTP(s) Listener configuration uses either port 8091 or 8092.

Additional ports can be opened inside the VPC, for example, for JMX based monitoring. In order to do so, refer to the Firewall rules section in out VPC documentation.

Dedicated Load Balancing Configurations

Under certain circumstances you may want to set up a custom load balancing layer for your Mule workers. For example, if you want to provide a custom domain name or SSL certificates.

Traffic can be routed from your load balancer to CloudHub workers through the internal or external DNS record for your workers. This record contains an IP address for every worker in the application. It is recommended that you set your DNS timeout to between 20-60 seconds so that any DNS changes are propagated quickly and minimize impact.

By configuring your own VPC you can set your own dedicated load balancer through the Anypoint Platform Command Line Interface.

Avoiding Public Discoverability for Applications on CloudHub

If you have a Virtual Private Cloud and a Cloudhub Dedicated Load Balancer, you can prevent your applications hosted in CloudHub from being publicly accessible:

  1. Remove the VPC firewall rule for ports 8081 and 8082 using:

    1. The Firewall Rules tab in your VPC management center:

      1. Remove both rules with source Anywhere ( and ports 8081 and 8082.

    2. The Anypoint CLI

      1. Run the cloudhub vpc firewall-rules remove command with the index 1 and 3

  2. Create a whitelist in your dedicated load balancer with the IPs you want to authorize.

    1. You can only do this using the cloudhub load-balancer whitelist add command from the CLI.

Important: If you don’t have any Cloudhub Dedicated Load Balancer, performing the first step will be sufficient to ensure that applications deployed in your VPCs will not be publicly accessible.

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.