Contact Free trial Login

About Cloudhub Dedicated Load Balancer

CloudHub features a backend load-balancing service designed to automate the provisioning of infrastructure components. You can use this service to deploy one or more dedicated load-balancers within an Anypoint Virtual Private Cloud (VPC).

You must have at least one Anypoint VPC defined in your organization before you can configure a dedicated load balancer.

Each dedicated load balancers allows you to:

  1. Handle Load balancing amongst the different CloudHub workers that run a Mule application.

  2. Define SSL configurations to provide custom certificates and optionally enforce two-way SSL client authentication.

  3. Easily configure proxy rules that map your applications to custom domains, enabling you to for example host everything under a single vanity domain.

This is an optional addition to your Anypoint infrastructure that is not included by default in all Anypoint Platform plans. Prior to a Dedicated Load Balancer’s creation, you must first have an Anypoint VPC created for your organization. You can associate multiple environments to the same Anypoint VPC, meaning that you can use the same dedicated load balancer for your different environments.

Check the Creating and Configuring a Dedicated Load Balancer section for more information.

Load Balancer Architecture

A CloudHub dedicated load balancer can be used to route both internal and external traffic, and can route requests for multiple deployed Mule applications.

A CloudHub dedicated load balancer is assigned to a particular Anypoint VPC. The dedicated load balancer then routes traffic to that particular Anypoint VPC within the particular service region of the Anypoint VPC.

For a Mule application to be managed by the dedicated load balancer, the Mule application must be deployed into the Anypoint VPC for the dedicated load balancer.

Your CloudHub dedicated load balancer has an internal domain name to be used by applications and clients within the Anypoint VPC. The structure is internal-<lb-name> where <lb-name> is the name you give the load balancer when you created it. Additionally, your Dedicated Load Balancer exposes an external domain name resolving to 2 public IP addresses which can be reached from outside of your CloudHub Anypoint VPC network: <lb-name> where <lb-name> is the name you gave the load balancer when you created it.

Each Dedicated Load Balancer has a DNS A Record <lb-name> resolving to 2 Public IP addresses of its two instances.
Through your DNS provider, you can add a CNAME record pointing to this A record and use your own domain names to access.

If you want your load balancer to handle all connections to your application and you don’t want your default domain name for your application publicly exposed, then each application needs to be listening over HTTP on port 8091 or 8092, or you can create a custom mapping policy to redirect outside requests from your load balancer to your specific application.

Your load balancer listens for outside requests over HTTPS and, by default, communicates internally with your worker over HTTP. If you configured your Mule application within the Anypoint VPC to listen on HTTPS, make sure you set upstreamProtocol to HTTPS when creating the mapping list using the load-balancer mappings add command.

SSL Endpoints

By providing a certificate and private key pair, you configure an SSL endpoint for your load balancer to serve to clients.
Each load balancer can have multiple and independent SSL endpoints. Each one of them identified by their server certificate common name.

A dedicated load balancer needs to have at least one certificate associated to it, meaning that at least one SSL endpoint needs to be configured when creating the load balancer.


To associate an SSL endpoint you need to provide:

  1. One file containing a PEM encoded and not encrypted certificate file.

  2. A second file containing the private key of your PEM certificate.

    The private key file needs to be passphraseless.

For example, you can create both a PEM encoded and not encrypted certificate file and a private key using openssl. Here is an example of creating a self-signed certificate and corresponding private key:

openssl req -newkey rsa:2048 -nodes -keyout example-com-private.pem -x509 -days 3000 -out example-com-crt.pem

This command prompts you for the certificate information.

You can also store the certificate information in a configuration file and pass that configuration file in to the openssl command.

For example, this certificate configuration file named example-com.cfg defines the DNS domain that includes some SAN (Subject Alternate Names) for two Mule applications: and

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt = no
[ req_distinguished_name ]
countryName                 = US
stateOrProvinceName         = California
localityName               = San Francisco
organizationName           = MuleSoft
commonName                 =

[ req_ext ]
subjectAltName = @alt_names
DNS.1   =
DNS.2   =

Alternatively, this example of a wildcard certificate maps any subdomain name to

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
prompt = no
[ req_distinguished_name ]
countryName                 = US
stateOrProvinceName         = California
localityName               = San Francisco
organizationName           = MuleSoft
commonName                 = *

The example wildcard ceritifcate is configured to support any subdomain request to, so this would include and, as well as any future subdomain names.

You can then pass the certificate configuration file in an openssl command:

openssl req -newkey rsa:2048 -nodes -keyout example-com-private.pem -x509 -days 3000 -out example-com-crt.pem -config example-com.cfg

Then you can decrypt the private key using openssl:

openssl rsa -in example-com-private.pem -out example-com-private-decrypted.pem

Configuring Certificates for Production

In a production environment you would normally have your certificate signed by a valid Certificate Authority (CA). Each SSL Endpoint can have multiple CA certificates and CRLs (Certificate Revocation Lists). You need to provide each of these certificates in a single unencrypted, PEM encoded file. Ordering is not important for independent CA certificates, but certificates in a chain of trust must be concatenated together.

Uploading Certificates

The certificate that you upload to your Load Balancer must be contained in one PEM encoded and unencrypted file.
This file could contain the entire certificate chain ordered one after the other, similar to the example section below:

Certificate Example

The Primary Certificate

(Your Primary SSL certificate: your_domain_name.crt)

The Intermediate Certificate

(Your Intermediate certificate: DigiCertCA.crt)

It is not necessary to include the root certificate in the certificate chain. However, make sure to include the ASCII armor in each certificate.

You can upload an SSL endpoint to your load balancer when creating it, using the cloudhub load-balancer create or upload a new SSL endpoint to an existing load balancer using the cloudhub load-balancer ssl-endpoint add command.

Certificate Validation

If at least one CA certificate is provided for the SSL endpoint, the load balancer passes the client certificate data to the API using the HTTP headers below:


This header returns either SUCCESS, FAILED, or NONE Only after SUCCESS, the client is verified.
It returns NONE when the certificate is not present and FAILED when other validation problems occur.


Contains the full distinguished name of the client certificate.


Contains the full distinguished name of the issuing certificate.


Contains the serial number used by the CA to identify the client.

Adding Revocation Lists

The CloudHub load balancer can optionally verify client requests against certificate revocation lists (CRL). All CRL files need to be concatenated into a single PEM encoded file for upload. Ordering is not important.

You can add a revocation list when creating the load balancer using the ´--crl´ option in your load-balancer create command.

Additionally, if your load balancer is already created, you can use the REST API to update it.
You can send a PATCH request to the /organizations/{orgid}/vpcs/{vpcId}/loadbalancers/{lbId} endpoint adding a revocationList element:

    "op": "replace",
    "path": "/sslEndpoints/0/revocationList",

Certificate Ciphers

A list of recommended ciphers suites with a good balance between compatibility and security for your SSL endpoint are below:
They all offer forward secrecy, except RC4-SHA which is there to support Internet Explorer 8.


CloudHub’s dedicated load balancer supports TLSv1.1 and TLSv1.2. Additionally, you can configure TLS v1.0, but bear in mind that such protocol is no longer accepted by PCi compliance due to its significant vulnerabilities.

Mapping Rules

The load balancer configuration is defined by a list of mapping rules which describe how input URL should be translated into calls to different CloudHub apps.
Mapping rules are attributes of the load balancer’s SSL endpoint.
When you create a mapping rule, you need to specify a certificate CN. Omitting the [certificateName] parameter adds the mappings to the default endpoint.

When creating a simple matching rule, one input address is literally matched to the defined output: the endpoint of one of your applications.
Instead of using literal matchings you can also use a pattern to match a variable-like input text to an endpoint.

By using proxy rules, you can map a domain or subdomain to one of your Mule applications that run in CloudHub

Using Patterns in Mapping Rules

A pattern is a string that defines a template for matching an input text. Whatever is placed into curly brackets { } is treated like a variable. These variables can contain only letters (a-z) and cannot contain any other characters, such as digits or slashes. The variable values can contain the following characters a-z0-1.&_-?_ but no slashes.

Suppose you have set up a DNS CNAME records from to <lb-name> Then you can map to a different deployed CloudHub Mule application name.

For example, you can literally bind two hostnames for redirect:

‘’ ->  application: `app` URI: `/example’

In this case, external requests to would be directed to

Or you can define a pattern to hold the input value:

‘{mypattern}’ -> application: `app-{mypattern}` URI: /data

The example above ensures both is directed to and is directed to, as the variable mypattern holds these values.

For input=””, the pattern can be resolved by assigning mypattern=”bookings” and for input="", the pattern is resolved to assign mypattern=”sales”.

Depending on your design, you can choose to leverage your internal redirects to your endpoints using patterns or simply literal mappings.

Currently patterns in the application URI are not supported.

Creating Mapping Rules

A mapping rule is a set of fields that define an input URL, and a set of fields that describe the output URL.

  • The input URL is described using a URI parameter which can be specified by the user:

    1. URI - a String or Pattern that describes the input URI.

      The input URL follows the main load balancer’s domain (This value should remain constant for the same load balancer)

  • The output URL is specified by two fields.

    1. appName - Output the application name where the request will be forwarded to.

    2. appURI - the URI string that is passed to the resolved application.

Both input and output URLs can be defined using patterns or literal strings.

Mapping rules are attributes of the load balancer’s SSL endpoint, which is identified by the certificate name.
When you create a mapping rule, you need to specify a certificate CN. Omitting the [certificateName] parameter adds the mappings to the default endpoint.

In the list of mapping rules, the rule which is defined first has high priority against other ones defined after it. This means that the first matched rule will be applied.
You can create, view, and delete existing rules using the mappings add, mappings describe and mappings remove commands respectively.

Mapping Rule Examples

The table below contains some mapping rule examples. Assume that the load balancer in these examples is lb-demo.

By default, your load balancer listens to external requests on HTTPS and communicates internally with your worker over HTTP. If you configured your Mule application within the Anypoint VPC to listen on HTTPS, make sure you set upstreamProtocol to HTTPS when creating the mapping list using the load-balancer mappings add command.

URL Mapping

You can pass the app name as an input URI and map it directly to the app name in CloudHub:

Rule # Input URL Output URL








This rule maps{app} to {app}
{app} is a pattern for any application name you choose to pass in the inbound request.

This example assumes that you configured a DNS CNAME record to route to, and that you configured the SSL endpoint with a certificate for the common name

Host Mapping

If you have a wildcard certificate such as *, you can use the subdomain variable to map any subdomain:

Rule # Input URL Output URL








This rule automatically maps any request passed to a subdomain of to the corresponding appName. For example:

  • Passing redirects to

  • Passing maps to

The same applies for the Subject Alternative Names (SANs) of your SSL Endpoints.

Instead of using a wildcard certificate, which permits any subdomain application name to be passed through the dedicated load balancer, you can restrict the allowed subdomain names. To do this, you must have different SANs configured for a certificate’s common name, you can use the ´subdomain´ variable to map the subdomain portion of your domain name to your application.

For example, having:

  • Two deployed applications:

    • dev-app

    • qa-app

  • And an SSL endpoint with the Subject Alternative Names:



  • The mapping rule:

    Rule # Input URL Output URL








This rule maps the subdomain part of your domain name to the application name:

  • Passing redirects to

  • Passing redirects to

1:1 Mapping

If you have only one application, you can map the literal app name.

Rule # Input URL Output URL








This maps your default load balancer directly to your app in CloudHub

Indexing the Priority of Rules

When creating a mapping rule, assign an index to it to define the rule’s priority order.
A rule defined first, at index 0 has higher priority against other rules defined after it. The higher the index assigned, the less priority the mapping rule has.

Every rule must have a priority defined. It is highly recommended to pay attention to each rules’ order when creating them, and multiple rules might override each other.

Ordering and Prioritizing Rules

You can set the order of your mapping rules when creating them using the cloudhub load-balancer mappings add command in the Anypoint Platform CLI by specifying an index value.

When using the API to create a rule, you can not specify a priority order, but you can send a PATCH request later to the load balancer endpoint{orgid}/loadbalancers/{loadbalancerId} and update your rules expressions with an order index, to match your needs based on the order logic explained above.

The load balancer ID is provided to you when you create it. You can also perform a GET request to your endpoint /organizations/{orgid}}/loadbalancers to get the ID.


To whitelist IP addresses to your load balancers, you need to pass those IP addresses in CIDR notation using the load-balancer whitelist add command.

The whitelist works for inbound connections at the load balancer level, not at the CN certificate level. Make sure you only pass IP addresses.

Creating and Configuring a Dedicated Load Balancer

In order to be able to create and configure a load balancer, your profile needs to be an administrator of the organization to which the load balancer is associated.

There are three ways of creating and configuring a dedicated load balancer for your Anypoint VPC:

  1. Using the cloudhub load-balancer create command from the Anypoint Platform CLI.

  2. Using the Cloudhub API through the endpoints{orgid}/loadbalancers and{orgid}/vpcs.

  3. Using Runtime Manager from the Anypoint Platform UI.

A full description of loadbalancers and vpcs endpoints is available in your API Portal. In the API Portal, search among other Mule APIs for the CloudHub API and enter its latest version.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub