# mulesoft CloudHub - Full Documentation

<!-- document id=7b1d3bfb939b41194067ade8450e4192816f1ab466014c192b065cc0e085e3aa url=/mulesoft/current/en-us/cloudhub/lb-cert-upload.md -->

---
product: CloudHub
---

# Add Certificates to a Dedicated Load Balancer

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

When you create a dedicated load balancer (DLB), you must add at least one certificate. You can add
additional certificates to a DLB using Runtime Manager or the command-line interface.

The certificate must be contained in one unencrypted, PEM-encoded file. If you are migrating a
certificate created with Windows tools:

- Remove all "Bag Attributes" and "Key Attributes".

- Convert all end-of-line characters from `\r\n` to `\n`, if necessary.

This file must contain the entire certificate chain ordered sequentially:

<table><colgroup><col> <col></colgroup><thead><tr><th>Certificate</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p>The Primary Certificate</p></div></div></td><td><div><div><p>-----BEGIN CERTIFICATE-----<br>(Your Primary SSL certificate: your_domain_name.crt)<br>-----END CERTIFICATE-----</p></div></div></td></tr><tr><td><div><div><p>The Intermediate Certificate</p></div></div></td><td><div><div><p>-----BEGIN CERTIFICATE-----<br>(Your Intermediate certificate: DigiCertCA.crt)<br>-----END CERTIFICATE-----</p></div></div></td></tr></tbody></table>

You don’t need to include the root certificate in the certificate chain. However, ensure that you
include the ASCII armor in each certificate.

## Add a Certificate to an Existing Load Balancer

You can add a certificate to an existing DLB using Runtime Manager or the command-line interface.

To add a certificate using Runtime Manager:

1.  From Anypoint Platform, click **Runtime Manager**.

2.  Click **Load Balancers**, and then click the load balancer name.

3.  In the **Certificates** tab, click **Add certificate**.

    ![Add certificate option in the load balancer settings page](/mulesoft/current/en-us/cloudhub/_images/lb-cert-upload-update.png)

    Figure 1. The arrow shows the **Add certificate** option in the **Certificates** tab.

4.  Select **Choose File** to upload the public key and private key files, such as:

    - Public key file

      A PEM file that includes both the server certificate and the intermediate CA certificate, for
      example, `example-com-crt.pem`

    - Private key file

      A PEM file that contains a passphrase-less private key, for example,
      `example-com-private-noencrypt.pem`

      To create the passphrase-less file, run a command like the following:

      ```console
      openssl rsa -in example-com-private.pem -out example-com-private_noencrypt.pem
      ```

5.  Click **Save Certificate**.

To add a certificate to an existing DLB using the CLI:

```console
cloudhub load-balancer ssl-endpoint add myLB_name example-com-crt.pem example-com-private.pem
```

## Replace a Certificate on an Existing Load Balancer

You can replace a certificate on an existing DLB when the certificate is expiring or needs to be
updated.

To replace a certificate using Runtime Manager:

1.  From Anypoint Platform, click **Runtime Manager**.

2.  Click **Load Balancers**, and then click the load balancer name.

3.  In the **Certificates** tab, click the certificate name.

4.  Select **Choose File** to upload the public key and private key files, such as:

    - Public key file

      A PEM file that includes both the server certificate and the intermediate CA certificate, for
      example, `new-example-com-crt.pem`

    - Private key file:

      A PEM file that contains a passphrase-less private key, for example,
      `new-example-com-private-noencrypt.pem`

      To create the passphrase-less file, run a command like the following:

      ```console
      openssl rsa -in new-example-com-private.pem -out new-example-com-private_noencrypt.pem
      ```

5.  Click **Done Editing**.

6.  Click **Apply Changes**.

## See Also

- [Configure SSL Endpoints](https://docs.mulesoft.com/cloudhub/lb-ssl-endpoints)

- [Create a Load Balancer with Runtime Manager](https://docs.mulesoft.com/cloudhub/lb-create-arm)

- [Create a Load Balancer with the Anypoint Platform CLI](https://docs.mulesoft.com/cloudhub/lb-create-cli)

- [cloudhub load-balancer ssl-endpoint add](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-ssl-endpoint-add)

<!-- document id=a154e64a37aab8f6e426c6e16f48a67073118d43a63eb4bbef6e4631406f6095 url=/mulesoft/current/en-us/cloudhub/vpc-connectivity-methods-concept.md -->

---
product: CloudHub
---

# Anypoint VPC Connectivity Methods

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can connect an Anypoint Virtual Private Cloud (Anypoint VPC) to your private network using these
methods:

- IPsec tunnel

- Transit gateway attachment

- VPC peering

  To connect your Anypoint VPC using VPC peering, contact your MuleSoft Support representative.

- AWS Direct Connect

  To connect your Anypoint VPC using AWS Direct Connect, contact your MuleSoft Support
  representative.

> [!NOTE] A maximum of 95 route table entries is allowed per VPC, regardless of the number of
> connections. To avoid exceeding the limit, consolidate networks to the fewest number possible.

## IPsec Tunnel

You can use an IPsec tunnel with network-to-network configuration to connect your on-premises data
centers to your Anypoint VPC. An IPsec VPN tunnel is generally the recommended solution for VPC to
on-premises connectivity, as it provides a standardized, secure way to connect. This method also
integrates well with existing IT infrastructure such as routers and appliances.

![IPsec Tunnel Overview](/mulesoft/current/en-us/cloudhub/_images/vpc-overview-ipsec.png)

> [!NOTE] If you are using a legacy VPN, migrate to Anypoint VPN before making changes.

To create an Anypoint VPN connection to your network, see [Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-about).

## Transit Gateway Attachments

AWS Transit Gateway acts as a cloud router in AWS, simplifying network access between VPCs,
on-premises data centers, and third-party software, while providing increased visibility and control
over the network. Transit gateways effectively merge your organization’s cloud resources and
on-premises datacenters into one network topology.

On CloudHub, you can take advantage of this network simplification by securely attaching Anypoint
VPC to an AWS Transit Gateway in your AWS account.

To use transit gateway attachments, your Anypoint VPC and AWS transit gateway must be in the same
region.

![Transit Gateway Overview](/mulesoft/current/en-us/cloudhub/_images/vpc-overview-tgw.png)

To attach your Anypoint VPC to your transit gateway, see [Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub/tgw-about).

## VPC Peering

VPC peering provides a connection between two VPCs. In this case, it pairs your private Amazon VPC
directly to your Anypoint VPC. This enables you to route traffic between the two VPCs so they can
communicate as though they are in the same network.

![VPC Peering Overview](/mulesoft/current/en-us/cloudhub/_images/vpc-overview-peering.png)

> [!NOTE] To use VPC Peering, your AWS and Anypoint VPCs must be located in the same region.

## AWS Direct Connect

To create a Direct Connect connection to Anypoint VPC, create or use an existing AWS Transit Gateway
in your AWS account and set up the Direct Connect connection to the Transit Gateway. Then, attach
Anypoint VPC to the Transit Gateway and configure the required routing to enable Anypoint VPC
on-premises connectivity.

On your AWS account, attach Direct Connect connections to a Direct Connect Gateway and associate
that Direct Connect Gateway with your Transit Gateway. Anypoint VPC attaches to the Transit Gateway.

![AWS Direct Connect Overview](/mulesoft/current/en-us/cloudhub/_images/vpc-overview-dx.png)

> [!NOTE] To use Direct Connect, your AWS Direct Connect Partner and the Anypoint VPCs must be
> located in the same region. Direct Connect requires the Border Gateway Protocol (BGP) for dynamic
> routing. Static routing isn’t supported.

## Direct Connect High Availability

A single Direct Connect connection isn’t sufficient for high availability. A failure at the
facility, hardware, or connection level can cause total connectivity loss.

For workloads that require high availability, use multiple Direct Connect connections that enter the
AWS Global Network at two AWS Direct Connect locations and converge at a Transit Gateway in your AWS
account. Attach Anypoint VPC to that Transit Gateway.

![High Availability Direct Connect for Anypoint VPC](/mulesoft/current/en-us/cloudhub/_images/vpc-overview-dx-ha.png)

This HA topology uses these components:

- **On-premises infrastructure**  
  Network traffic originates from your on-premises environment. Use a single data center with
  redundant edge routers, or distribute traffic across multiple physical data centers.

- **Two AWS Direct Connect locations**  
  To provide path redundancy, Direct Connect connections must enter the AWS Global Network at two
  AWS facilities. See
  [AWS Direct Connect Locations](https://aws.amazon.com/directconnect/locations/).

- **AWS Transit Gateway**  
  The Transit Gateway in your AWS account acts as a centralized cloud router. Attach both Direct
  Connect connections to a Direct Connect Gateway, and associate that Direct Connect Gateway with
  the Transit Gateway.

- **Anypoint VPC**  
  Attach Anypoint VPC to your Transit Gateway to route traffic privately to your on-premises
  resources.

### Prerequisites

Before you configure Direct Connect high availability:

- Provision the Transit Gateway and Anypoint VPC in the same AWS region.

- Use BGP for dynamic routing. Static routing isn’t supported.

- Plan Direct Connect connections at two AWS Direct Connect locations.

- Stay within the 95 route table entries allowed per Anypoint VPC. Consolidate networks with summary
  routes so you don’t exceed the limit.

### Configure Direct Connect High Availability

1.  In your AWS account, create a Transit Gateway in the same region as your Anypoint VPC.

2.  Work with AWS or your AWS Direct Connect Partner to provision dedicated or hosted connections at
    two physical locations:

    1.  Establish connection A between your on-premises network and AWS Direct Connect Location 1.

    2.  Establish connection B between your on-premises network and AWS Direct Connect Location 2.

    3.  Create the virtual interfaces (VIFs) required to attach both Direct Connect connections to
        your Transit Gateway through a Direct Connect Gateway.

3.  Enable BGP over both Direct Connect connections.

    To manage traffic as active/passive or active/active, configure your on-premises edge routers.
    For an active/standby setup, use AS path prepending on the secondary connection so it’s a less
    preferred route during normal operations. See
    [Routing policies for Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/routing-and-bgp.html#private-routing-policies)
    in the AWS documentation.

4.  Verify that routes propagate from the Direct Connect Gateway into the Transit Gateway route
    table associated with Anypoint VPC.

5.  Attach Anypoint VPC to the Transit Gateway. See [Attach to Transit Gateways](https://docs.mulesoft.com/cloudhub/tgw-attach-arm).

6.  In your Transit Gateway route tables, route traffic destined for your on-premises network over
    the Direct Connect links, and route traffic destined for Anypoint VPC to the VPC attachment.

### Failover Behavior

Because this architecture uses BGP for dynamic routing across redundant paths, failover is
automatic:

- If the primary network link, on-premises router, or AWS Direct Connect location fails, BGP
  withdraws the primary routes.

- If the Transit Gateway moves active traffic to the secondary Direct Connect connection.

- When the primary connection is restored, BGP re-advertises the preferred routes and traffic
  returns to its normal path. You don’t need to update routing manually in CloudHub or AWS.

> [!IMPORTANT] Before deleting a VPC that uses Direct Connect, contact MuleSoft Support to remove
> the Direct Connect connection.
>
> MuleSoft Support manually provisions and removes Direct Connect connections. If you delete a VPC
> before removing Direct Connect, the deletion can fail and leave resources (VPCs, virtual gateway
> attachments, and hosted connections) in AWS.

## See Also

- [Request VPC Connectivity to Your Network](https://docs.mulesoft.com/cloudhub/to-request-vpc-connectivity)

- [Attach to Transit Gateways](https://docs.mulesoft.com/cloudhub/tgw-attach-arm)

- [Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-about)

- [Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub/tgw-about)

<!-- document id=f812fcb7910650636fc398af5a778a64fbb57d2ca6d2c739eaacbee01001fd6f url=/mulesoft/current/en-us/cloudhub/vpn-about.md -->

---
product: CloudHub
---

# Anypoint VPN

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Use Anypoint VPN to create a secure connection between your MuleSoft Virtual Private Cloud (VPC) and
your on-premises network. You can create multiple site-to-site VPNs if required.

> [!NOTE] The number of VPNs you can create depends on the VPN entitlements available to your
> account. Contact your MuleSoft account representative if you don’t know how many VPN entitlements
> you have on your account.

Anypoint VPN supports site-to-site Internet Protocol security (IPsec) connections. A physical or
software appliance, called a VPN endpoint, is the terminator on your side of the connection. The
MuleSoft side of the connection is an implementation of a virtual private gateway (VGW). The
MuleSoft VGW is associated with a single MuleSoft VPC but can support up to 10 VPN connections.

> [!NOTE] MuleSoft implementation capabilities may vary from other VGW offerings.

## Anypoint VPN Features

Each Anypoint VPN connection consists of two tunnels that enable you to connect to a single public
IP address at a remote location. To configure connectivity to an additional public IP address at a
remote location, you must create two VPN connections.

A single VPN provides increased availability for your MuleSoft VPC. Routine maintenance can briefly
disable one of the two tunnels of your VPN connection. During this time, your VPN connection
automatically fails over to the second tunnel so access is not interrupted. For this reason, both
tunnels must be configured on your endpoint. Tunnel selection depends on your VPN endpoint
capabilities and the routing type selection.

The MuleSoft VGW implementation supports a maximum throughput of 1.25 Gbps. Multiple VPN connections
to the same VPC share the throughput capabilities of a single VGW. The VPN connection throughput
depends on several factors, such as the capability of your VPN endpoint, the capacity of the
connection, the average packet size, the protocol, and network latency between the gateways.

### IPsec Settings

Anypoint VPN supports any combination of the following IPsec settings:

- IKE version 1

- IKE version 2 for route-based VPNs only

- AES 128 or 256-bit encryption operating in the CBC and GCM

- SHA or SHA-2 (256, 384, 512) hashing

- Diffie-Hellman Phase 1 groups 2, 14-24

- Diffie-Hellman Phase 2 groups 2, 5, 14-24

- Timeouts for IKEv1

  - IKE (Phase 1) Lifetime: 28800 seconds (8 hours)

  - IPsec (Phase 2) Lifetime: 3600 seconds (1 hour)

- Timeouts for IKEv2

  - IKE (Phase 1) Lifetime: 28000 seconds (7 hours and 50 minutes)

  - IPsec (Phase 2) Lifetime: 3000 seconds (50 minutes)

> [!NOTE] Some of these IPsec settings are not supported in Government Cloud. For specific
> Government Cloud VPN settings, see [Anypoint VPN Settings](https://docs.mulesoft.com/gov-cloud/gov-cloud-anypoint-vpn).

### Anypoint VPN Routing

Anypoint VPN supports dynamic or static routing for VPN connections.

- **Dynamic routing** Your device uses Border Gateway Protocol (BGP) to advertise routes to Anypoint
  VPN. Use BGP routing if your device supports this protocol.

- **Static routing** - Requires you to specify the routes (subnets) in your network that are
  accessible through Anypoint VPN.

  > [!NOTE] A maximum of 95 route table entries is permitted per VPC, regardless of the number of
  > VPN connections. Consolidate networks to the fewest number possible to avoid exceeding the
  > limit.

### Limitations

Anypoint VPN does not support these features and configurations:

- Network Address Translation (NAT)

- IPv6

- IKEv2 with policy-based VPNs

- A single VPC with both AWS Direct Connect and Anypoint VPN connections

- Advertising a default route (0.0.0.0/0) over BGP or static routing

## Requirements for Static VPN Connections

To create a static VPN connection, your VPN endpoint must be able to:

- Establish IKE Security Associations using a Pre-Shared Key (PSK)

- Establish IPsec Security Associations in Tunnel mode

- Utilize any combination of IPsec settings that MuleSoft supports

- Fragment IP packets before encryption

  You must fragment packets that are too large to transmit. Your VPN device must be able to fragment
  packets before encapsulation.

- Use one Security Association (SA) pair per tunnel

  Anypoint VPN supports one unique SA pair per tunnel (a pair refers to one inbound and one outbound
  connection). Some policy-based devices create an SA for each ACL (access-control list) entry. In
  this situation, you must consolidate your rules and then filter unwanted traffic.

- Use IPsec Dead Peer Detection (DPD)

  DPD allows devices to rapidly identify when network conditions change. You can enable DPD on the
  MuleSoft endpoint using `DPD Interval: 10` and `DPD Retries: 3`.

- Allow asymmetric routing

  Asymmetric routing occurs when routing policies send traffic from your network to the VPC through
  one tunnel and traffic returns from the VPC through the other tunnel. The MuleSoft VPN endpoint
  selects the tunnel using an internal algorithm, making the return path dynamic. If your device
  uses an active/active tunnel configuration, you must allow asymmetric routing for each Anypoint
  VPN connection.

- For IPsec, enable perfect forward secrecy (PFS) with the above Phase 2 Diffie-Hellman groups

## Requirements for Dynamic VPN Connections

To create a dynamic VPN connection, in addition to the static VPN connection requirements, the VPN
endpoint must be able to:

- Establish BGP peering

- Support route-based VPNs (bind tunnels to logical interfaces)

- For IPsec, enable perfect forward secrecy (PFS) with the above Phase 2 Diffie-Hellman groups

## Recommendations

- Adjust the maximum segment size of TCP packets entering the VPN tunnel.

  VPN headers require additional space, which reduces the amount of space available for data.

  To limit the impact of this behavior, configure your endpoint with TCP MSS Adjustment: 1387 bytes.

- Reset the `DF` flag on packets.

  Packets might carry a Don’t Fragment (`DF`) flag, indicating that the packet must not be
  fragmented. Some VPN devices can override the `DF` flag and fragment packets unconditionally when
  required. If available, enable the setting `Clear Don’t Fragment (DF) Bit`.

## Tested Network Devices

The following network devices are known to work with the Anypoint VPN. If your device does not
appear in the list of tested devices, check the [requirements](#vpn_requirements) to verify that
your device is suitable for use with Anypoint VPN.

<table><colgroup><col> <col></colgroup><thead><tr><th>Hardware</th><th>Software</th></tr></thead><tbody><tr><td><p>Check Point Security Gateway</p></td><td><p>R77.10 or later</p></td></tr><tr><td><p>Cisco ASA</p></td><td><p>ASA 8.2 or later</p></td></tr><tr><td><p>Cisco IOS</p></td><td><p>Cisco IOS 12.4 or later</p></td></tr><tr><td><p>Dell SonicWALL</p></td><td><p>SonicOS 5.9 or later</p></td></tr><tr><td><p>Fortinet Fortigate 40+ Series</p></td><td><p>FortiOS 4.0 or later</p></td></tr><tr><td><p>Juniper J-Series Service Router</p></td><td><p>JunOS 9.5 or later</p></td></tr><tr><td><p>Juniper SRX-Series Services Gateway</p></td><td><p>JunOS 11.0 or later</p></td></tr><tr><td><p>Juniper SSG</p></td><td><p>ScreenOS 6.1 or 6.2 or later</p></td></tr><tr><td><p>Juniper ISG</p></td><td><p>ScreenOS 6.1 or 6.2 or later</p></td></tr><tr><td><p>Netgate pfSense</p></td><td><p>OS 2.2.5 or later</p></td></tr><tr><td><p>Palo Alto Networks</p></td><td><p>PANOS 4.1.2 or later</p></td></tr><tr><td><p>Yamaha</p></td><td><div><div><ul><li><p>RT107e</p></li><li><p>RTX1200</p></li><li><p>RTX1210</p></li><li><p>RTX1500</p></li><li><p>RTX3000</p></li><li><p>SRT100</p></li></ul></div></div></td></tr><tr><td><p>Microsoft Windows Server</p></td><td><div><div><ul><li><p>2008 R2 or later</p></li><li><p>2012 R2 or later</p></li></ul></div></div></td></tr><tr><td><p>Zyxel Zywall Series</p></td><td><div><div><ul><li><p>4.20 or later for statically routed Anypoint VPN connections</p></li><li><p>4.30 or later for dynamically routed Anypoint VPN connections</p></li></ul></div></div></td></tr></tbody></table>

If there is no specific **Device Configuration** file downloadable from the **Get VPN Config** menu
for any of the listed devices, use the **Generic** VPN configuration file.

![Generic VPN configuration file option](/mulesoft/current/en-us/cloudhub/_images/vpn-device-generic-config.png)

## See Also

- [Create an Anypoint VPN Connection](https://docs.mulesoft.com/cloudhub/vpn-create-arm)

- [Anypoint VPN High Availability](https://docs.mulesoft.com/cloudhub/vpn-high-availability)

- [Anypoint VPN Knowledge Articles](https://help.salesforce.com/s/articleView?id=001117281&type=1)

<!-- document id=09726db1fa9b5f2746959758836de5af65cda5990e5a57988698dee142cb1423 url=/mulesoft/current/en-us/cloudhub/vpn-downtime-risk.md -->

---
product: CloudHub
---

# Anypoint VPN downtime risk

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Every VPN provisioned in Mulesoft has an associated risk that depends on the state of the VPN
tunnels.

For high downtime risk VPNs, deploy a [high-availability VPN](https://docs.mulesoft.com/cloudhub/vpn-high-availability) solution to
avoid any downtime associated with AWS-delivered auto-updates. See
[VPN Maintenance](https://docs.mulesoft.com/cloudhub/vpn-maintenance) for more details.

## Downtime Risk types

VPN downtime risk depends on the number of UP tunnels.

There are three types of downtime risks:

- UNAVAILABLE

- LOW

- HIGH

If both tunnels of the VPN are down, the VPN downtime risk is **UNAVAILABLE**, since no data is
going through the VPN.

If the VPN has one tunnel UP and the other one DOWN, then the VPN has **HIGH** downtime risk.

If the VPN has both tunnels UP, then the VPN has **LOW** downtime risk.

## Check the VPN Risk in Anypoint Platform

You can check the downtime risk associated with your VPNs in Anypoint Platform.

To check your VPN downtime risk:

1.  Sign in to Anypoint Platform.

2.  Go to Runtime Manager.

3.  Open the **VPNs** tab.

4.  Check the **Downtime Risk** column for your VPN.

![VPN Downtime Risk UI](/mulesoft/current/en-us/cloudhub/_images/vpn-downtime-risk.png)

## See Also

- [Anypoint VPN High Availability](https://docs.mulesoft.com/cloudhub/vpn-high-availability)

- [VPN Maintenance](https://docs.mulesoft.com/cloudhub/vpn-maintenance)

- [Using Redundant Site-to-Site VPN Connections to Provide Failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html)

<!-- document id=1e46286e21fb241d46eec6937a88b1de3bc26ed6c5270bfbd5fac9cfe16e163d url=/mulesoft/current/en-us/cloudhub/vpn-high-availability.md -->

---
product: CloudHub
---

# Anypoint VPN High Availability

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Your VPN connection consists of two VPN tunnels that terminate in different Availability Zones to
provide increased availability to your VPC. During a mandatory upgrade, AWS might briefly disable
one of the two tunnels of your VPN connection.

When you configure your customer gateway, configure both tunnels for redundancy. When one tunnel
becomes unavailable (for example, it is down for maintenance), AWS automatically routes network
traffic to the other available tunnel for that specific VPN connection. When AWS performs updates on
one VPN tunnel, it sets a lower outbound multi-exit discriminator (MED) value on the other tunnel to
ensure failover.

The AWS Site-to-Site VPN [SLA](https://aws.amazon.com/vpn/site-to-site-vpn-sla/) requires two VPN
endpoints for each connection. Having redundant Anypoint VPN tunnels configured helps to prevent
MuleSoft service downtime during the AWS auto-patching window.

To ensure that your applications and related operations can handle Anypoint VPN updates, issues, and
individual customer gateway failures, implement High Availability with redundant Anypoint VPN
connections. Each Anypoint VPN connection consists of two endpoints, providing High Availability
(HA) on the MuleSoft side by default.

## Prerequisites

- Sufficient entitlement for each VPN connection

- Two VPN endpoints using different public IP addresses

- Two VPN connections in Runtime Manager

## Configure High Availability with Anypoint VPN

The following example shows a High Availability VPN topology that uses a single Anypoint VPC and two
VPN connections.

A MuleSoft Virtual Private Gateway (VGW) supports one Anypoint VPC association and up to 10 VPN
connections. You can locate your VPN Gateways in the same data center or in different physical
locations.

To eliminate all single points of failure, the two customer gateways should be in different data
centers, and preferably in different cities. Ideally, use your Disaster Recovery location for the
second gateway.

![VPN High Availability Topology](/mulesoft/current/en-us/cloudhub/_images/vpn-ha-topology.png)

Use BGP routing to advertise the same routes via VPN-1 and VPN-2. For instructions on how to control
path selection via the routing protocol, see
[Anypoint VPN Path Selection using BGP Routing](https://help.salesforce.com/s/articleView?id=001116889&type=1).

In this scenario, the VPN Gateways are configured to prefer VPN-1 Tunnel-1, then VPN-1 Tunnel-2,
then VPN-2 Tunnel-1, and finally VPN-2 Tunnel-2. This configuration produces an automatic failover
to another tunnel and another VPN in the event of a VPN connectivity issue. This makes the Anypoint
VPN solution more resilient and robust.

High Availability VPN connections also support static routing, in which you establish a VPN-2 to
work as a redundant, standby connection in the event of a failure with VPN-1.

## See Also

- [Create an Anypoint VPN Connection](https://docs.mulesoft.com/cloudhub/vpn-create-arm)

- [Anypoint VPN Downtime Risk](https://docs.mulesoft.com/cloudhub/vpn-downtime-risk)

- [Using Redundant Site-to-Site VPN Connections to Provide Failover](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html)

- [Continue to Have Redundant Pair of VPNs as Well](https://docs.aws.amazon.com/vpn/latest/s2svpn/disaster-recovery-resiliency.html)

- [How to Calculate VPC and VPN License Requirements](https://help.salesforce.com/s/articleView?id=001114580&type=1)

<!-- document id=c5106e4f34aabee9a4ab15c0e913cf2babed33395a4253fbd9e2e7237904f141 url=/mulesoft/current/en-us/cloudhub/vpn-maintenance.md -->

---
product: CloudHub
---

# Anypoint VPN Maintenance

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

## Anypoint VPN Update

MuleSoft Anypoint VPN is a managed service that is underpinned by AWS Site-to-Site VPN connections.
Using a VPN is important for any integrations or flows that require connectivity to your on-premises
or external platforms. Updating an Anypoint VPN that is not set up with at least a pair of tunnels
that use BGP routing will cause downtime. See
[Anypoint VPN High Availability](https://docs.mulesoft.com/cloudhub/vpn-high-availability) for more information.

After the October 2022 quarterly maintenance window, Anypoint VPN will no longer support quarterly
customer self-upgrades. From this point forward, updates made to Anypoint VPN will adhere to AWS’s
standard continuous upgrade process. Upgrades will be applied on-demand, with no published
maintenance window schedule, no customer opt-in self-upgrade capabilities, with **potential
(limited) downtime for customers that do not have a**
[High Availability (HA) VPN implementation](https://docs.mulesoft.com/cloudhub/vpn-high-availability).

Deploy a [high-availability VPN](https://docs.mulesoft.com/cloudhub/vpn-high-availability) solution to avoid any downtime associated
with these AWS-delivered security updates. Review the following sections for recommendations and
troubleshooting information.

## Avoiding or Reducing Downtime During an On-demand Maintenance

Mule applications that use Anypoint VPN connectivity are impacted during an on-demand maintenance.
The impact on the Anypoint VPN varies depending on the VPN configuration:

- An Anypoint VPN with at least one pair of tunnels configured with BGP routing and DPD (Dead Peer
  Detection) to reset the tunnels when triggered incurs minimal downtime. The switchover takes a few
  seconds.

- An Anypoint VPN tunnel pair configured with static routing incurs some downtime before
  reconnection. The reconnection takes longer if you do not have an automated failover mechanism to
  detect failed tunnels.

- For an Anypoint VPN configured without BGP routing or a failover mechanism or with only one tunnel
  configured, the outage is up to 60 minutes long while the update occurs and the original tunnel
  comes back up.

## Troubleshoot Issues During an Anypoint VPN On-demand Maintenance

These are some of the possible issues you may encounter during an on-demand maintenance:

### Tunnels Don’t Come Up

If the tunnels are not back up within 10-15 minutes at any point in time, try restarting your end of
the tunnels to bring them back up.

If your VPN is configured with static routing, try generating "interesting traffic" (traffic that
should be encrypted over the Anypoint VPN connection) towards the Anypoint VPN to bring up the VPN.
See
[How to Generate Interesting Traffic for Anypoint VPN](https://help.salesforce.com/s/articleView?id=001117182&type=1)
for more information.

### Tunnel Goes Down Due to Inactivity

If there is no traffic over the VPN tunnel, the VPN goes down due to inactivity. In this case,
generate interesting traffic. We recommend that you move towards BGP.

### IKE Phase Lifetimes Mismatch

#### If You Use IKEv2:

To maintain a reliable tunnel operation after an on-demand maintenance, ensure that the IKEv2 Phase
1 and Phase 2 lifetimes are set as described in [IPsec Settings](https://docs.mulesoft.com/cloudhub/vpn-about#ipsec-settings):

- IKE Phase 1 lifetime: 28000 seconds

- IKE Phase 2 lifetime: 3000 second

> [!NOTE] AWS documentation states 28800 seconds for the IKE Phase 1 lifetime, and 3600 seconds for
> the IKE Phase 2 lifetime. MuleSoft recommends the 28000/3000 combination for your firewall device
> to timeout first and control the rekey process.

#### If You Use IKEv1:

If you use IKEv1, use the default configuration: 28800 seconds for the Phase 1 lifetime, and 3600
seconds for the Phase 2 lifetime.

### Anypoint VPN Goes Down Periodically Due to PFS not Enabled for IPsec Phase 2

If you use Azure VPN, ensure that PFS is enabled and adjust the lifetimes for Phase 2. For more
information, see
[Anypoint VPN to Azure keeps going down every hour](https://help.salesforce.com/s/articleView?id=001116834&type=1).

### Anypoint VPN with BGP Routing Enters into Asymmetric Mode after an Update

Anypoint VPN enters into asymmetric mode after an on-demand maintenance if the AS paths for the two
tunnels of the same VPN are different.

### Seeing IPsec DPD Failures in VPN Logs

Ensure that your DPD settings are correctly configured.

### Other issues

For other issues with Anypoint VPN, see [Troubleshoot Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-troubleshooting).

<!-- document id=5e1f20c19d1a155c884f34bdbe9f6b8e0cc52fb51c1d06f6328cf3e2e6850372 url=/mulesoft/current/en-us/cloudhub/worker-monitoring.md -->

---
product: CloudHub
---

# Application Monitoring and Automatic Restarts

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

CloudHub monitors all applications and enables you to receive notifications and diagnostic
information if your application becomes unresponsive.

You can enable automatic restarts so that your application can recover automatically without your
intervention.

## How Application Monitoring Works

CloudHub uses the Mule Agent health check endpoint to determine the readiness of a deployment. This
monitoring method provides a thorough check to ensure that the application is deployed and applies
gateway policies.

Every 30 seconds, CloudHub checks the health check endpoint. If CloudHub detects that the health
check endpoint fails three times in a row, the logs print a warning.

CloudHub triggers a notification to the console to alert you that a worker for an application
stopped responding.

If you configure email alerts, the unresponsive worker also triggers an email alert based on the
`Worker Not Responding` event.

## Enable Automatic Restarts

You can enable automatic restarts when you deploy a new application or redeploy an existing
application.

- Deploy a new app

  1.  In Runtime Manager, click **Applications** in the menu on the left.

  2.  Click **Deploy Application** and select **CloudHub** from **Deployment Target**.

  3.  Select the **Automatically restart application when not responding** option:

      ![Automatically restart application when not responding option](/mulesoft/current/en-us/cloudhub/_images/cloudhub-app-autorestart.png)

      Figure 1. The arrow shows the **Automatically restart application when not responding**
      option.

  4.  Click **Deploy Application**.

- Redeploy an existing app

  1.  In Runtime Manager, click **Applications** in the menu on the left.

  2.  Click the app status to display the details pane on the right

  3.  Click the **Manage Application** button to display the **Settings** page for the app.

  4.  Select the **Automatically restart application when not responding** option:

      ![Automatically restart application when not responding option](/mulesoft/current/en-us/cloudhub/_images/cloudhub-app-autorestart.png)

      Figure 2. The arrow shows the **Automatically restart application when not responding**
      option.

  5.  Click **Apply Changes**.

> [!NOTE] If you change the flag `monitoringEnabled` via API, the application doesn’t restart
> automatically and you must restart it manually.

## How Automatic Restarts and Relaunches Work

If you select the **Automatically restart application when not responding** option, CloudHub
monitors the worker and automatically attempts recovery using two mechanisms: application restarts
and application relaunches.

### Application Restarts

CloudHub continuously checks the health of the worker JVM. If the JVM becomes unresponsive, CloudHub
restarts the application on the same worker instance.

- If the restart succeeds, health monitoring continues.

- If the restart fails, CloudHub attempts up to five restarts.

After five restart attempts, CloudHub stops trying to restart the application on that worker.

### Application Relaunches

After CloudHub exhausts all restart attempts, it evaluates the worker state and attempts an
application relaunch. During an application relaunch, CloudHub terminates the failed worker and
provisions a new worker instance.

CloudHub attempts up to three application relaunches.

If all relaunch attempts fail:

- CloudHub stops automatic recovery.

- CloudHub sends you a notification.

- You must manually redeploy the application to restore it.

The logs show the details of the restart and relaunch procedures.

### Without Automatic Restarts

If you don’t select the **Automatically restart application when not responding** option, CloudHub
displays a notification and a log message when the application becomes unresponsive, but doesn’t
attempt automatic recovery. You must manually restart the application.

## See Also

- [Configure Alerts](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)

- [Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)

- [Monitor Applications and Servers](https://docs.mulesoft.com/runtime-manager/monitoring)

<!-- document id=30ba255c6d2afc750363c5e6af11f3091a5bec6d8f385015191429e09c25157c url=/mulesoft/current/en-us/cloudhub/tgw-attach-arm.md -->

---
product: CloudHub
---

# Attach to Transit Gateways

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Use Anypoint Runtime Manager to add a transit gateway and connect your Anypoint Virtual Private
Cloud (VPC) to your private corporate network.

## Prerequisites

Before you can add a transit gateway to CloudHub:

- Create a transit gateway on your corporate AWS account.

  See
  [Getting started with transit gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html)
  in the AWS documentation for information about creating a transit gateway on AWS.

  One transit gateway can support up to 10 VPC attachments.

- The number of attachments you can make to AWS Transit Gateways depends on the network connections
  available to your Business Group.

  > [!NOTE] The **Transit Gateways** page is visible in Runtime Manager to Anypoint organizations
  > that have an Anypoint VPC and VPN license.
  >
  > Attaching one Anypoint VPC to an AWS Transit Gateway uses one Anypoint VPN license. You can
  > check or edit the licenses allocated to the Business Group by navigating to **Access
  > Management** > **Organizations** and choosing the relevant Business Group. Update or view the
  > **Network Connection** options as required, and save any changes.

- Sign in to an Anypoint Platform account with either the CloudHub Network Administrator or the
  CloudHub Network Viewer user permission.

  See
  [Grant Permissions and Roles to Users](https://docs.mulesoft.com/access-management/users#grant-permissions-and-roles-to-users).

- Create an Anypoint VPC in Anypoint Platform.

  See [Create and Update a VPC for Runtime Manager](https://docs.mulesoft.com/cloudhub/vpc-tutorial).

- Identify the subnets in your network (in CIDR notation) that you want to make accessible through
  the transit gateway.

## Transit Gateway Attachment Workflow

The steps for attaching to a transit gateway are:

1.  [Add the transit gateway](#add_tgw) to Anypoint Platform by
    [creating a resource share in AWS](#create_resource_share) to share your transit gateway with
    Anypoint Platform.

2.  [Attach your VPCs](#attach_vpc_tgw) to the transit gateway and
    [accept the VPC attachments](#accept_attachment) in AWS.

3.  [Configure transit gateway routing](#configure_tgw_routing):

    1.  [Enable outbound traffic from Anypoint VPC](#enable_outbound_traffic_from_vpc).

    2.  [Enable inbound traffic through the transit gateway on AWS](#enable_inbound_traffic_on_aws).

## Add a Transit Gateway

To add a transit gateway:

1.  Sign in to Anypoint Platform and select **Runtime Manager**.

2.  From the Runtime Manager navigation menu, click **Transit Gateways**, and then click **Add
    Transit Gateway**.

    The **Here’s what’s coming** page lists the steps to add the transit gateway:

    ![Here’s what’s coming page](/mulesoft/current/en-us/cloudhub/_images/tgw-process-overview.png)

3.  Click **I’m ready**.

4.  Specify a name for your transit gateway:

    ![Add transit gateway page](/mulesoft/current/en-us/cloudhub/_images/tgw-add.png)

    Use the same name for your transit gateway in AWS. You can change this name later. The name can
    contain up to 255 alphanumeric characters (a-z, A-Z, 0-9) and hyphens (-).

5.  Select the region that corresponds to the location of your AWS Transit Gateway.

    See [Regional Services](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide#regional-services).

    Your Anypoint VPC and AWS Transit Gateway must be in the same region.

6.  Click **Next**.

    The **Add transit gateway** page lists the steps to create a resource share in AWS:

    ![Add transit gateway page: Steps to create a resource share](/mulesoft/current/en-us/cloudhub/_images/tgw-add-overview.png)

    > [!NOTE] The MuleSoft AWS Account ID relevant for your Anypoint VPC is displayed at this step.
    > As this ID varies, always use the Account ID displayed in this step for your AWS
    > configuration. If the AWS configuration is performed by other teams or resources within your
    > organization, please share this MuleSoft AWS account ID with them.

## Create a Resource Share

1.  Sign in to your AWS corporate account.

2.  In Anypoint Platform, click the **Create resource share** link on the **Add transit gateway**
    page.

    The link opens the AWS RAM console to the page for creating a resource share in the region you
    specified.

3.  Take the following actions on the AWS **Create resource share** page:

    1.  Under **Description**, enter a descriptive name for the resource share in the **Name**
        field.

    2.  Under **Resources - _optional_**, select **Transit Gateways** from the **Select resource
        type** menu and select the transit gateway resource to share.

        The transit gateway ID appears in the **Selected resources** field.

    3.  Under **Principals - _optional_**, ensure that **Allow external accounts** is selected,
        enter the MuleSoft AWS account ID that appears on the **Add transit gateway** page, and
        click **Add**.

        The AWS account number appears in the **Selected principals** field.

    4.  Under **Tags**, add a tag if you want.

    5.  Click **Create resource share**.

    6.  Copy the **ID** and **Owner** values for the resource share you just created.

4.  Take the following actions in the Anypoint Platform **Add transit gateway** window:

    1.  Click **Next**.

    2.  Paste the values you copied from AWS in the **ID** and **Owner** fields:

        ![Add transit gateway page: Resource share ID and owner ID](/mulesoft/current/en-us/cloudhub/_images/tgw-add-resource-share.png)

        - The resource share **ID** field contains alphanumeric characters (a-z, A-Z, 0-9) and
          hyphens (-).

        - The resource share **Owner** field contains only numbers.

    3.  Click **Add**.

    The **Transit Gateways** page shows the progress for connecting to AWS and adding the transit
    gateway to Anypoint Platform.

When the transit gateway addition succeeds, the **Transit Gateways** page displays the **Transit
gateway added** message. The **Transit Gateways** page updates the owner and ID from AWS and the
state as **Available**:

![Transit gateway added](/mulesoft/current/en-us/cloudhub/_images/tgw-resource-share-available.png)

If the transit gateway addition fails, see
[Troubleshoot Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub/tgw-troubleshoot).

## Attach Anypoint VPC to the Transit Gateway

After the transit gateway attachment succeeds, attach your Anypoint VPC to enable apps to access the
transit gateway.

For information about limitations when attaching an Anypoint VPC to a transit gateway, see
[Transit gateway attachments to a VPC](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)
in the AWS documentation.

To attach Anypoint VPC to the transit gateway:

1.  In Anypoint Platform, on the **Transit Gateways** page, click **Attach VPC**.

    The **Attach VPC** button is disabled if no VPCs are available to attach or if the transit
    gateway addition failed.

2.  From the **Select VPC** window, select the VPC to attach:

    ![Select VPC window](/mulesoft/current/en-us/cloudhub/_images/tgw-select-vpc.png)

    The window displays only the VPCs that are:

    - In the same region as the transit gateway

    - Not already attached to the transit gateway

    - In business groups for which you have CloudHub Network Administrator permissions

3.  Click **Next**.

## Accept the VPC Attachment

1.  Sign in to your AWS corporate account.

2.  In Anypoint Platform, on the **Accept VPC Attachment** page, click the **Transit Gateway
    Attachments** link:

    ![Accept VPC Attachment page](/mulesoft/current/en-us/cloudhub/_images/tgw-accept-vpc-attachment.png)

    The link opens the AWS RAM console to the **Create Transit Gateway Attachment** page.

3.  In the AWS console:

    1.  Select the attachment that shows **pending acceptance** in the **State** column.

        The attachment might take a few minutes to appear.

    2.  Select the transit gateway attachment ID and, on the **Details** tab, ensure that **Resource
        owner account ID** is the MuleSoft AWS account ID.

    3.  Click the pencil icon for the attachment and enter a name.

    4.  Select **Actions** > **Accept** and click **Accept** to confirm.

        When the attachment acceptance succeeds, the **State** column shows **available**.

4.  In Anypoint Platform, in the **Accept VPC Attachment** window, click **Done**.

    The **Transit Gateways** page shows the progress for accepting the VPC attachment from Anypoint
    Platform to AWS:

    ![Checking VPC attachment status](/mulesoft/current/en-us/cloudhub/_images/tgw-checking-attachment-status.png)

5.  Click **Refresh** to update the attachment status.

When the VPC attachment succeeds, the **Transit Gateways** page displays the **VPC attached**
message and the attachment state indicates that it’s attached to AWS Transit Gateway:

![VPC attached successfully](/mulesoft/current/en-us/cloudhub/_images/tgw-attached.png)

If the VPC attachment state is `Rejected`, see
[Troubleshoot Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub/tgw-troubleshoot).

## Configure Transit Gateway Routing

Anypoint VPC supports static routing for transit gateways.

Configure the network routes (subnets) that you want to be accessible through the transit gateway:

- On Anypoint Platform,
  [enable outbound traffic from Anypoint VPC](#enable_outbound_traffic_from_vpc) to an external
  destination.

- On AWS, [enable inbound traffic](#enable_inbound_traffic_on_aws) through your transit gateway.

### Prerequisites

Before configuring routing, consolidate networks to the fewest number possible. A maximum of 95
route table entries is permitted per VPC, regardless of the number of transit gateway attachments.

### Enable Outbound Traffic from Anypoint VPC

After attaching the VPC, enable outbound traffic from Anypoint VPC to an external destination so
that apps can access the transit gateway and the transit gateway routes traffic correctly.

To do this, add routes to the transit gateway route table:

1.  In Anypoint Platform, navigate to **Transit Gateways** > **VPCs** and click **Add Route**.

2.  On the **Add VPC Route** window, use CIDR notation to enter a single subnet for your AWS VPC:

    ![Add VPC route](/mulesoft/current/en-us/cloudhub/_images/tgw-add-vpc-route.png)

3.  Click **Add Route**.

    Anypoint Platform submits the new route to AWS.

When the route addition succeeds, the **Transit Gateways** page shows the **Route added** message
and the **Transit Gateways** page shows the route CIDR in the route tables.

In the route tables, added routes show **Transit Gateway** as the value in the **Next Hop** column.

Specific routes attached to the transit gateway show under **Transit Gateway Routes**. Other routes
in the VPC show under **VPC Routes**.

![Transit Gateway in the Next Hop column of the route table](/mulesoft/current/en-us/cloudhub/_images/tgw-route-added.png)

### Enable Inbound Traffic Through the Transit Gateway

After successfully adding routes to the transit gateway route table in Anypoint Platform, enable
inbound traffic through your transit gateway on AWS.

You might need to coordinate with your network administrator to enable inbound traffic.

## See Also

- [Troubleshoot Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub/tgw-troubleshoot)

- [Manage Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub/tgw-manage-arm)

- [Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub/tgw-about)

- [Transit gateway attachments to a VPC](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)
  in the AWS documentation

- [Transit gateway route tables](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html)
  in the AWS documentation

- [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [Create and Update a VPC for Runtime Manager](https://docs.mulesoft.com/cloudhub/vpc-tutorial)

- [Grant Permissions and Roles to Users](https://docs.mulesoft.com/access-management/users#grant-permissions-and-roles-to-users)

<!-- document id=a76d66346b923ea9c106f583a44c9f7de806ea09fa378ba53f51b9a8a7357a26 url=/mulesoft/current/en-us/cloudhub/autoscaling-in-cloudhub.md -->

---
product: CloudHub
---

# Autoscaling in CloudHub

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

> [!NOTE] To use the autoscaling feature, your organization must have an Enterprise License
> Agreement (ELA). Entitlement is approved based on qualified use cases. If you are interested in
> this feature, contact your account representative.
>
> Autoscaling isn’t available on CloudHub for Usage-based Pricing (UBP) organizations.

CloudHub allows you to make the processing power behind your applications responsive to changes in
their usage. You can define policies that respond to CPU or memory usage thresholds by scaling up or
scaling down the processing resources used by an application.

## Configure Autoscaling

1.  Click the **Applications** tab of Runtime Manager.

2.  Select an application deployed to CloudHub to open its panel.

3.  In the panel, click **Manage Application**.

4.  In the **Settings** section, select the **Autoscaling** tab.  
    You can see all existing autoscaling policies, activate or deactivate them, create or delete
    them, and create associated
    [Alerts on Runtime Manager](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager).

## Create a Policy

To create a policy, click the **Create Policy** button, then configure the fields to set your policy
up.

![policy](/mulesoft/current/en-us/cloudhub/_images/autoscale-create-policy.png)

Changes in worker size or number are triggered when a policy meets its requirements. Policies can be
based either upon CPU or Memory usage, and they can either modify worker numbers or worker size. All
policies include a scale up and a scale down condition.

![form](/mulesoft/current/en-us/cloudhub/_images/policy-form.png)

1.  Provide a **Name** for your policy.

2.  Determine if the scaling will be based on **Memory or CPU usage**.

    > [!NOTE]
    >
    > - For **CPU**: The percentage shown is the worker’s total CPU usage relative to its allocated
    >   CPU capacity. Autoscaling is triggered based on the worker’s overall CPU usage, not JVM CPU
    >   usage alone.
    >
    > - For **Memory**: The percentage shown is the percentage of total memory allocated for the JVM
    >   that’s being used, including memory consumed by the JVM itself.

3.  Determine the **Rules** for your scaling. You must provide the following values for both the
    upscale and the downscale conditions:

    1.  A usage **percentage**

    2.  A period of **time** throughout which this level must be sustained before the policy is
        applied

    3.  A **cool-down period** that blocks this and other policies from affecting scaling from being
        applied

4.  Define what **action** will be performed when the policy is applied:

    1.  If it will affect the **number** of workers or the **size** of them

    2.  Set a **maximum** and **minimum** value to fluctuate in between

> [!NOTE] Maximum number of workers is 4, and maximum worker size is 16 vCores for the Autoscaling
> policy.

## Scaling Considerations

All policies scale your application one step at a time. To scale up to meet a pronounced spike that
requires scaling numerous steps, each step takes CloudHub the sum of the policy evaluation time plus
the cool-down period.

You can apply only one autoscaling policy per application.

The maximum amount and size of workers that you have available is limited by the characteristics of
your account. If multiple applications running in your account compete for limited resources, they
are allocated in a first-come, first-served manner.

Autoscaling fails if your org reaches its vCore limit because there are no available resources to
provision new workers. To continue, increase your org’s vCore limit or stop unused apps to free up
vCores.

## Edit an Existing Policy

To edit an existing policy, open the **Policies** tab. Click the policy name and you will access the
same menu that is used to create a new policy.

## Deactivate a Policy

To deactivate a running policy, open the policies tab and flip the switch in its corresponding
**Status** field:

![enable](/mulesoft/current/en-us/cloudhub/_images/enable-policy.png)

## Delete a Policy

To delete an existing policy, go to the policies tab, then click its corresponding delete icon.

## Set an Alert and View Autoscaling History

Two specific types of Alerts can be set up for applications on CloudHub that warn you whenever a
worker autoscaling event occurs. One alerts you about scale ups and the other about scale downs.

With this alert set, emails will be automatically sent to the addresses you provide whenever such an
event occurs.

You can also see a full history of all of the times that the alert has been triggered. To see this,
from the **Alerts** page, click on an alert name to open its corresponding panel:

![history](/mulesoft/current/en-us/cloudhub/_images/alerts-history-autoscale.png)

## See Also

- [Alerts on Runtime Manager](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager)

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)

- [CloudHub](https://docs.mulesoft.com/cloudhub/)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

- [Clustering](https://docs.mulesoft.com/cloudhub/cloudhub-fabric)

- [Anypoint Platform Command-Line Interface](https://docs.mulesoft.com/anypoint-cli/latest/)

- [Secure Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties)

- [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

<!-- document id=e1ad19137cc48a4a88a499891a01a6f9f2196ca6e03eb4e73f16e7681244471a url=/mulesoft/current/en-us/cloudhub/lb-cert-validation.md -->

---
product: CloudHub
---

# Certificate Validation in Dedicated Load Balancers

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

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

- X-SSL-Client-Verify

  Returns one of:

  - `SUCCESS`

    The client is verified only after `SUCCESS`.

  - `NONE` when the certificate is not present

  - `FAILED` when other validation problems occur

- X-SSL-Client-DN

  Contains the full distinguished name of the client certificate

- X-SSL-Issuer

  Contains the full distinguished name of the issuing certificate

- X-SSL-Client-Serial

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

> [!NOTE] The client certificate is validated at the DLB-level, but it is not re-validated at the
> API-level. TLS is 1-way between the DLB and the API.

## How Client Certificate Validation Works

Client certificate validation succeeds when either of these conditions occurs:

- The list of certificates you uploaded to the DLB includes the client certificate.

- Any CA in the list of certificates you uploaded to the DLB signed the client certificate.

### Trust-Based Validation Behavior

The DLB performs trust-based validation. It trusts any certificate that chains up to a trusted root
CA or intermediate CA that you uploaded.

For example, if you upload this certificate chain to the DLB:

Client Certificate1 → Intermediate CA1 → Intermediate CA2 → Root CA

The DLB also accepts a different client certificate that chains to the same CAs:

Client Certificate2 → Intermediate CA1 → Intermediate CA2 → Root CA

In this case, the DLB accepts `Client Certificate2` even though it’s not part of the intended client
chain. The DLB accepts it because you uploaded `Intermediate CA1` and `CA2` as trusted CAs.

> [!IMPORTANT] The DLB doesn’t enforce client identity. It only verifies that the certificate is
> valid and that a trusted CA signed it.

### Implement Client Identity Verification

To verify client identity beyond CA trust validation, inspect certificate details in your Mule app.
Use the X-SSL-Client-DN header to verify the Subject DN or Common Name (CN) and the
X-SSL-Client-Serial header to match authorized serial numbers. Validating these headers restricts
access to specific authorized clients.

## Add Revocation Lists

The CloudHub load balancer can optionally verify client requests against certificate revocation
lists (CRL). All CRL files must be concatenated into a single, unencrypted PEM-encoded file for
upload. The order of items in the CRL is not important.

To add a revocation list when you create the load balancer, use the `--crl` option with the
[`cloudhub load-balancer create`](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-create) command.

If your load balancer already exists, you can use the
[CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)
to add or update your CRLs. To do so, send a `PATCH` request to the
`/organizations/{myOrgID}/vpcs/{myVpcID}/loadbalancers/{myDlbID}` endpoint and include a
`revocationList` element:

```json
[
  {
    "op": "replace",
    "path": "/sslEndpoints/0/revocationList",
    "value": "-----BEGIN X509 CRL-----\nMIIBTTCBtwIBATANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJBVTETMBEGA1UE\nCBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRk\nMRAwDgYDVQQDEwdvcmcuY29tFw0xNjAzMTUwOTI2MThaFw0xODAzMTUwOTI2MTha\nMBwwGgIJAIBvvO4dJHjhFw0xNjAzMTUwODUwMTZaoA4wDDAKBgNVHRQEAwIBBjAN\nBgkqhkiG9w0BAQUFAAOBgQCCAbGXW+Hnzmd1bXqWsFXfogOsJScoxkJOhhmjui3I\nhTUyO5plGHUBLjBnDkypM+iLfn0W4wPcNj7FZdz4Hu/WLntxwrTtR5YOcfIhEGcq\nwvJq/1+WKUPC6eqGwx0iKOOBIWsaf5CNOOUQMo6RaeTeu8Uba2EGFk1Vu/SoZYAK\nsw==\n-----END X509 CRL-----\n"
  }
]
```

To get the values for `myVpcID` and `myDlbID` values from the CLI, use the
[`cloudhub vpc describe-json`](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-vpc-describe-json) and
[`cloudhub load-balancer describe-json`](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-describe-json)
commands.

To update any other property, send a `PATCH` request to your load balancer endpoint.

## Prepare to Manage Certificate Cipher Suites

To manage cipher suites with the CloudHub API, you must first:

- [Generate your authorization bearer token](#generate-authorization-bearer-token).

- Retrieve your organization ID using the CloudHub API.

  See
  [Retrieve a single organization](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/minor/1.0/console/method/%233736/).

- Retrieve your VPC ID using the CloudHub CLI.

  See [cloudhub vpc describe-json](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-vpc-describe-json).

- Retrieve your DLB ID using the CloudHub CLI.

  See [cloudhub load-balancer describe-json](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-describe-json).

- Install `jq` to format the JSON output.

  See [jq](https://stedolan.github.io/jq/).

### Generate Authorization Bearer Token

To generate your authorization bearer token for Anypoint Platform:

1.  Send your Anypoint Platform user name and password to the API:

    ```json
    curl -X POST 'https://anypoint.mulesoft.com/accounts/login' -H 'Content-Type: application/json' -d '{"username":"myUsername","password":"myPassword"}'
    ```

    This command returns the access token:

    ```json
    {
      "access_token": "myAccessToken",
      "token_type": "bearer",
      "redirectUrl": "/home/"
    }
    ```

2.  Copy the value of `access_token` to use in the API calls.

## Manage Certificate Cipher Suites

Using the CloudHub API, you can:

- [List available cipher suites](#list-available-cipher-suites).

- [Display the default cipher suite for a DLB](#display-the-default-cipher-suite-for-a-dlb).

- [Rotate the cipher by replacing the default cipher suite](#rotate-the-cipher-by-replacing-the-default-cipher-suite).

### List Available Cipher Suites

To list available cipher suites for an organization using the CloudHub API:

1.  [Prepare to manage certificate cipher suites](#prepare-to-manage-certificate-cipher-suites).

2.  Run this GET call:

    ```linenums
    curl https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/loadbalancers/ciphersuites -H 'Authorization: Bearer myAccessToken' | jq
    ```

    - `_myOrgID_` is the organization ID.

    - `_myAccessToken_` is the access token you generated.

The output includes `ciphers`:

```json
{
  "data": [
    {
      "id": "5b4a36e1e65c892316abd4d1",
      "name": "NewDefault-v1",
      "ciphers": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384",
      "description": "Default ciphers (new version)-v1",
      "defaultSuite": true
    },
    {
      "id": "5b4a36e1e65c892316abd4d2",
      "name": "OldDefault",
      "ciphers": "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4",
      "description": "Default ciphers (old version)",
      "defaultSuite": false
    },
    {
      "id": "5b4bfedee4b0f45ab1de6979",
      "name": "EcdheEcdsaRsa",
      "ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384",
      "description": "ECDHE ECDSA RSA ciphers",
      "defaultSuite": false
    },
    {
      "id": "5ba28106e4b00522d78f40b6",
      "name": "RestrictCiphers",
      "ciphers": "AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256",
      "description": "Restricted Ciphers",
      "defaultSuite": false
    }
  ],
  "total": 4
}
```

### Recommended Cipher Suites

The following recommended cipher suites provide a good balance between compatibility and security
for your SSL endpoint:

ECDHE-RSA-AES256-GCM-SHA512 DHE-RSA-AES256-GCM-SHA512 ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384

Most cipher suites offer forward secrecy. RC4-SHA (supports Internet Explorer 8) does not. For this
reason, MuleSoft and Microsoft do not recommend using it.

The CloudHub dedicated load balancer supports TLS 1.2.

### Display the Default Cipher Suite for a DLB

To display the default cipher suite for a DLB using the CloudHub API:

1.  [Prepare to manage certificate cipher suites](#prepare-to-manage-certificate-cipher-suites).

2.  Run this GET call:

    ```linenums
    curl https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/myDlbID -H 'Authorization: Bearer myAccessToken' | jq
    ```

    In the command:

    - `_myOrgID_` is the organization ID.

    - `_myVpcID_` is the ID for the VPC.

    - `_myDlbID_` is the ID for the DLB.

    - `_myAccessToken_` is the access token you generated.

The output includes `defaultCipherSuite`:

```json
"defaultCipherSuite": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384"
```

### Rotate the Cipher by Replacing the Default Cipher Suite

To rotate the cipher by replacing the default cipher suite for a DLB using the CloudHub API:

1.  [Prepare to manage certificate cipher suites](#prepare-to-manage-certificate-cipher-suites).

2.  Run this PATCH call:

    ```linenums
    curl -X PATCH
    https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/
    myDlbID  -H 'Authorization: Bearer myAccessToken'
    -H 'Content-Type: application/json'
    -d '[{"op":"replace", "path":"/defaultCipherSuiteName", "value":"NewDefault-v1"}]' | jq
    ```

    In the command:

    - `_myOrgID_` is the organization ID.

    - `_myVpcID_` is the ID for the VPC.

    - `_myDlbID_` is the ID for the DLB.

    - `_myAccessToken_` is the access token you generated.

    - `NewDefault` is the value of `name` for a cipher suite from the list of available cipher
      suites that you generated in [List Available Cipher Suites](#list-available-cipher-suites).

The output now includes `defaultCipherSuite`:

```json
"defaultCipherSuite": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384"
```

## Limitation

To use an ECDSA-based authentication cipher, generate the certificate and key pair using an
ECDSA-based algorithm and apply the same algorithm to the SSL certificate and key configuration on
the DLB.

If you try to use an ECDSA-based authentication cipher with an RSA-based certificate and key pair,
the SSL handshake fails and you receive either of the following error messages:

```linenums
SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure
```

or

```linenums
Error: write EPROTO 140434219616616:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:594:SSL alert number 40 140434219616616:error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO:../../third_party/boringssl/src/ssl/handshake.cc:603:
```

Because current DLB configuration permits only one type of SSL certificate and key pair per SSL
endpoint, a client using an RSA-based cipher can not connect to an ECDSA-based configuration, and
vice versa.

## See Also

- [Configure SSL Endpoints and Certificates](https://docs.mulesoft.com/cloudhub/lb-ssl-endpoints)

- [Add Certificates to a Dedicated Load Balancer](https://docs.mulesoft.com/cloudhub/lb-cert-upload)

- [Allowlists](https://docs.mulesoft.com/cloudhub/lb-allowlists)

- [Mapping Rules](https://docs.mulesoft.com/cloudhub/lb-mapping-rules)

- [Create a Load Balancer with Runtime Manager](https://docs.mulesoft.com/cloudhub/lb-create-arm)

<!-- document id=05315f55d8315bf4c1878b37124d6598e4ea84583fc46ba13a1f6b049057fbeb url=/mulesoft/current/en-us/cloudhub/cloudhub-api.md -->

---
product: CloudHub
---

# CloudHub API

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The CloudHub management API (CloudHub API) enables you to programmatically access the functions of
Anypoint Runtime Manager, such as:

- Manage applications:

  - Create, deploy, start, stop, list, and delete an application on CloudHub.

  - Update application metadata, including the number of workers, Mule runtime engine version, and
    system properties.

  - Retrieve statistics for an application or worker.

  - Retrieve application transactions and events for a transaction.

  - Check for replay data, replay the flow for a transaction, and delete replay data for an
    application.

  - Manage static IP addresses and release unused IP addresses associated with an application.

  - Download the Mule package file for the application.

  - Update, enable, disable, or run all or some schedules.

- Manage logs, notifications, and alerts:

  - Add, update, or retrieve log levels for an application.

  - Download the log file for an application or instance.

  - Create, update, or retrieve a notification.

  - Mark a notification as read or unread.

  - Create, update, or delete an alert triggered by an application.

  - Retrieve an alert and alert history.

- Manage load balancers:

  - Create, update, or delete a load balancer.

  - List load balancers in an organization.

  - Test load balancer rules and return the number of the rule applied to the input.

- Manage VPCs, VPNs, and TGWs:

  - Create, update, list, and remove a VPC.

  - Create or delete a VPN connection.

  - Add, modify, and remove multiple AWS Transit Gateway attachments to your Anypoint Platform
    organization.

- Manage persistent queues:

  - Retrieve statistics for persistent queues.

  - Clear the entries from a persistent queue.

- Retrieve additional information about:

  - Supported Mule versions

  - The current organization, including usage statistics

  - Workers, including thread dumps and worker regions

  - Users, including permissions

  - Available domain names

For an interactive reference that includes supported resources, methods, required properties, and
expected responses, see the
[CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/).

The CloudHub API manages only applications deployed to CloudHub, the cloud-based version of Runtime
Manager. To manage on-premises applications using the API, see
[Runtime Manager REST Services](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/arm-rest-services).

## Use the CloudHub API

Before getting started, familiarize yourself with operations for applications.

You can use any HTTP client with the CloudHub API. With Java, use the
[Jersey client](https://jersey.github.io/) or
[HttpClient](https://hc.apache.org/httpclient-legacy/index.html) with
[Jackson](https://github.com/codehaus/jackson) for JSON support.

To access operations in the CloudHub API, you must:

1.  Generate an authorization bearer token (AUTH\_BEARER\_TOKEN) to authenticate with the API.

    To get the access token, you need the Anypoint Platform username and password of a user assigned
    the Organization Administrators role. See
    [Authentication](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/pages/Authentication/)
    in the
    [Access Management API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/pages/home/).

    Your username specifies the environment to access. For example, if your username is `consuela`
    and the environment is `Development`, your username is `consuela@Development`. If you don’t
    specify an environment, the API defaults to `Production`.

2.  Get the organization ID (ORG\_ID).

    See the
    [`/api/me`](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/console/method/%234250/)
    endpoint in the
    [Access Management API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/pages/home/).

3.  Get the environment ID (ENV\_ID).

    See the
    [`/api/organizations/_ORG_ID_/environments`](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/console/method/%234762/)
    endpoint in the
    [Access Management API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/pages/home/).

### Get a List of Applications

To get a list of apps deployed to CloudHub, run the following `curl` command:

curl -X GET \\ --url https://anypoint.mulesoft.com/cloudhub/api/applications \\ -H 'authorization:
Bearer AUTH\_BEARER\_TOKEN' \\ -H 'X-ANYPNT-ENV-ID: ENV\_ID' \\ -H 'X-ANYPNT-ORG-ID: ORG\_ID'

## Data Format

Resources and methods that return or accept a type use the JSON data format. Here is an example of
data received in JSON format in response to a request to get an application:

```json
{
  "versionId": "xxxxxxxx",
  "domain": "hello",
  "fullDomain": "hello.us-e1.cloudhub.io",
  "properties": {
    "foo":"bar"
  },
  "propertiesOptions": {},
  "status": "STARTED",
  "workers": {
    "type": {
      "name": "Micro",
      "weight": 0.1,
      "cpu": "0.1 vCores",
      "memory": "500 MB memory"
    },
    "amount": 1,
    "remainingOrgWorkers": 223.7,
    "totalOrgWorkers": 1000.0
  },
  "workerStatuses": [
    {
      "id": "i-xxxxxxxx",
      "host": "xxx.xxx.xxx.xxx",
      "port": 0,
      "status": "STARTED",
      "deployedRegion": "us-east-1",
      "staticIPEnabled": false
    }
  ],
  "lastUpdateTime": 1589868960908,
  "fileName": "hello.zip",
  "muleVersion": {
    "version": "4.3.0",
    "updateId": "xxxxxxxx",
    "latestUpdateId": "xxxxxxxx",
    "endOfSupportDate": 1633737600000
  },
  ...
}
```

## JVM Tuning Fields

The Application API (v2) accepts two optional JVM tuning fields on `POST /applications` and
`PUT /applications/{domain}`, and returns them from `GET /applications/{domain}`:
`openJvmPackagesForArrow` and `gcMethod`. Both fields require a worker replacement to take effect,
so redeploy or restart the app after you change either value.

### openJvmPackagesForArrow

`openJvmPackagesForArrow` is a nullable Boolean that defaults to `false`. When you set it to `true`,
the CloudHub worker starts with these additional JVM flags:

\--add-opens=java.base/java.nio=ALL-UNNAMED -Dmule.module.tweaking.validation.skip=true

Set this field to `true` only for applications that require the Apache Arrow JDBC driver, such as
Snowflake Arrow, DuckDB, or any Arrow-backed connector, on Java 17. Without these flags, Java 17’s
stricter module system blocks Arrow’s use of `sun.misc.Unsafe` and off-heap NIO buffers, and the
application fails at runtime with an `InaccessibleObjectException`.

> [!NOTE] Enabling `openJvmPackagesForArrow` widens the JVM’s reflective access surface, because
> `java.base/java.nio` becomes open to the unnamed module. Enable it only for apps that need Apache
> Arrow, not as a general default.

> [!NOTE] `openJvmPackagesForArrow` is a transitional setting. It’s removed after Mule runtime
> engine delivers Module Layer Propagation, tracked in ADR-MULE-#072.

This table shows how each value behaves:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Value in request</th><th>Effect on POST (create)</th><th>Effect on PUT (update)</th></tr></thead><tbody><tr><td><p><code>true</code></p></td><td><p>Worker starts with both flags</p></td><td><p>Worker starts with both flags</p></td></tr><tr><td><p><code>false</code></p></td><td><p>Worker starts without the flags (default)</p></td><td><p>Worker starts without the flags</p></td></tr><tr><td><p><code>null</code> or omitted</p></td><td><p>Treated as <code>false</code></p></td><td><p>Leaves the stored value unchanged</p></td></tr></tbody></table>

Sample request (POST):

```json
{
  "domain": "my-arrow-app",
  "muleVersion": { "version": "4.7.0" },
  "openJvmPackagesForArrow": true
}
```

Sample response (GET):

```json
{
  "domain": "my-arrow-app",
  "openJvmPackagesForArrow": true
}
```

### gcMethod

`gcMethod` is a nullable String that selects which garbage collector the CloudHub worker’s JVM uses.
It defaults to `null`, which applies the boot-time default. Input is case-insensitive, and CloudHub
persists and returns the canonical form:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Input</th><th>Canonical form</th><th>JVM flag applied to the worker</th></tr></thead><tbody><tr><td><p><code>Serial</code>, <code>serial</code>, <code>SERIAL</code></p></td><td><p><code>Serial</code></p></td><td><p><code>-XX:+UseSerialGC</code></p></td></tr><tr><td><p><code>Parallel</code>, <code>parallel</code>, <code>PARALLEL</code></p></td><td><p><code>Parallel</code></p></td><td><p><code>-XX:+UseParallelGC</code></p></td></tr><tr><td><p><code>G1</code>, <code>g1</code></p></td><td><p><code>G1</code></p></td><td><p><code>-XX:+UseG1GC</code></p></td></tr><tr><td><p><code>null</code>, <code>""</code>, or omitted</p></td><td><p><code>null</code> (no override)</p></td><td><p>Boot-time default GC applies</p></td></tr><tr><td><p>Any other value</p></td><td><p>HTTP 400 with an allow-list error</p></td><td><p>—</p></td></tr></tbody></table>

Only these three canonical names match. CloudHub rejects aliases such as `G1GC` or `ParallelOld`, so
use only `Serial`, `Parallel`, or `G1`.

Choose a collector based on the workload:

- Serial GC minimizes the memory footprint on small workers (0.1 or 0.2 vCore).

- Parallel GC maximizes throughput for batch and ETL-heavy apps.

- G1 delivers lower, more predictable pause times for latency-sensitive request/response apps on 1
  vCore or larger.

> [!NOTE] When `gcMethod` is unset, the worker uses the baseline collector baked into its CloudHub
> AMI’s `wrapper.conf`. On current CloudHub 1.0 AMIs, that baseline is Parallel GC on all Java
> versions (8, 11, and 17) and all worker sizes. This baseline is a CloudHub deployment choice, not
> a JVM ergonomics outcome, so it applies even on Java 17, where the JVM’s own default would
> otherwise be G1. Leaving `gcMethod` unset is the recommended path unless you have a specific
> reason to override it.

This table shows how each value behaves:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Value in request</th><th>Effect on POST (create)</th><th>Effect on PUT (update)</th></tr></thead><tbody><tr><td><p><code>Serial</code>, <code>Parallel</code>, or <code>G1</code> (any case)</p></td><td><p>Stores the canonical form</p></td><td><p>Updates to the canonical form and audits the change</p></td></tr><tr><td><p><code>null</code> or omitted</p></td><td><p>Leaves the field <code>null</code> (boot default applies)</p></td><td><p>Leaves the stored value unchanged</p></td></tr><tr><td><p><code>""</code> or whitespace only</p></td><td><p>Stores <code>null</code> (boot default applies)</p></td><td><p>Clears any existing override and audits the change</p></td></tr><tr><td><p>Any other non-empty string</p></td><td><p>HTTP 400</p></td><td><p>HTTP 400</p></td></tr></tbody></table>

Changing `gcMethod` doesn’t hot-restart running workers. The new selector applies on the next worker
replacement: a redeploy, restart, or scaling event.

Sample request (POST):

```json
{
  "domain": "my-latency-app",
  "muleVersion": { "version": "4.7.0" },
  "gcMethod": "G1"
}
```

Sample request (PUT), which clears the override:

```json
{ "gcMethod": "" }
```

Sample response (GET):

```json
{
  "domain": "my-latency-app",
  "gcMethod": "G1"
}
```

## Rate Limits

The CloudHub management API enforces global usage limits, with some exceptions.

### Global Rate Limits for the CloudHub Management API

The following table lists the rate limits for the CloudHub management API endpoints except those
listed in [Exceptions to the Global Rate Limits](#exceptions-to-the-global-rate-limits).

When the app reaches the rate limit, CloudHub returns a 503 status code.

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Endpoints</th><th>Control Plane</th><th>Rate Limit Per Client IP Address</th><th>Status Code</th></tr></thead><tbody><tr><td rowspan="3"><p>All except specified endpoints</p></td><td><p>U.S.</p></td><td><p>75 requests per second</p></td><td rowspan="3"><p><code>503</code></p></td></tr><tr><td><p>EU</p></td><td rowspan="2"><p>25 requests per second</p></td></tr><tr><td><p>Government Cloud</p></td></tr></tbody></table>

### Exceptions to the Global Rate Limits

The following table lists the exceptions to the
[Global Rate Limits for the CloudHub Management API](#global-rate-limits-for-the-cloudhub-management-api).

When the app reaches the rate limit, CloudHub returns the status codes shown here.

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Endpoints</th><th>Control Plane</th><th>Rate Limit Per Client IP Address</th><th>Status Code</th></tr></thead><tbody><tr><td colspan="4"><p><strong>Endpoints under</strong> <code>/api</code></p></td></tr><tr><td rowspan="3"><p><code>/notifications</code></p></td><td><p>U.S.</p></td><td><p>75 requests per minute</p></td><td rowspan="3"><p><code>503</code></p></td></tr><tr><td><p>EU</p></td><td rowspan="2"><p>25 requests per minute</p></td></tr><tr><td><p>Government Cloud</p></td></tr><tr><td colspan="4"><p><strong>Endpoints under</strong> <code><strong>v2/applications/{domain}</strong></code></p></td></tr><tr><td><p><code>/logs</code></p></td><td rowspan="4"><p>All</p></td><td rowspan="3"><p>10 requests per second</p></td><td rowspan="3"><p><code>429</code></p></td></tr><tr><td><p><code>/deployments/{deploymentId}/logs</code></p></td></tr><tr><td><p><code>/instances/{instanceId}/logs</code></p></td></tr><tr><td><p><code>/instances/{instanceId}/log-file</code></p></td><td><p>1 request per minute</p></td><td><p><code>500</code></p></td></tr></tbody></table>

## Status Codes and Error Handling

When you call the CloudHub API, the following status codes are returned:

<table><colgroup><col> <col></colgroup><thead><tr><th>Status Code</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p>200</p></div></div></td><td><div><div><p>The operation was successful.</p></div></div></td></tr><tr><td><div><div><p>201</p></div></div></td><td><div><div><p>The resource (such as an application) was created.</p></div><div><p>The <code>Location</code> header contains the location of the resource.</p></div></div></td></tr><tr><td><div><div><p>404</p></div></div></td><td><div><div><p>The resource was not found.</p></div></div></td></tr><tr><td><div><div><p>409</p></div></div></td><td><div><div><p>When creating a resource (such as a server, server group, or deployment), a resource with that name already exists.</p></div></div></td></tr><tr><td><div><div><p>429</p></div></div></td><td><div><div><p>The operation was unsuccessful due to reaching the rate limit.</p></div></div></td></tr><tr><td><div><div><p>500</p></div></div></td><td><div><div><p>The operation was unsuccessful.</p></div><div><p>See the HTTP body for details.</p></div></div></td></tr><tr><td><div><div><p>503</p></div></div></td><td><div><div><p>The operation was unsuccessful due to a temporary condition, such as server overload or reaching a rate limit.</p></div><div><p>Retry the operation.</p></div></div></td></tr></tbody></table>

When errors occur, such as a 500 status code, the HTTP response contains a JSON response with an
error message:

```json
500
Content-Type: application/json
Server: Apache-Coyote/1.1
Date: Mon, 10 Aug 2015 00:12:55 GMT

{
  message : "Some error message."
}
```

## See Also

- [CloudHub API Reference](https://docs.mulesoft.com/cloudhub/cloudhub-api-reference)

- [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)

- [Access Management API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)

- [Develop Applications for CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub)

- [Monitor Applications and Servers](https://docs.mulesoft.com/runtime-manager/monitoring)

<!-- document id=a3657a466eda5aa744dc1703b265f82cb36527cb2d4ec93bce0f1e58850d714e url=/mulesoft/current/en-us/cloudhub/cloudhub-api-reference.md -->

---
product: CloudHub
---

# CloudHub API Reference

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

These tables list the most commonly used CloudHub Application Programming Interface (API) endpoints
grouped by category. All endpoints use the base URL `https://anypoint.mulesoft.com/cloudhub/api`.

For full details on request parameters, payloads, and responses, see the
[interactive API reference on Exchange](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/).

## Applications

Use these endpoints to deploy, manage, and delete Mule applications running on CloudHub.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Method</th><th>Endpoint</th><th>Description</th></tr></thead><tbody><tr><td><p><code>GET</code></p></td><td><p><code>/applications</code></p></td><td><p>List all applications.</p></td></tr><tr><td><p><code>POST</code></p></td><td><p><code>/applications</code></p></td><td><p>Create and deploy a new application.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/applications/{domain}</code></p></td><td><p>Get details for a specific application.</p></td></tr><tr><td><p><code>PUT</code></p></td><td><p><code>/applications/{domain}</code></p></td><td><p>Update application metadata (workers, runtime version, properties).</p></td></tr><tr><td><p><code>DELETE</code></p></td><td><p><code>/applications/{domain}</code></p></td><td><p>Delete an application.</p></td></tr></tbody></table>

For more information, see [Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub).

## Logs

Use these endpoints to search and download application log entries.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Method</th><th>Endpoint</th><th>Description</th></tr></thead><tbody><tr><td><p><code>POST</code></p></td><td><p><code>/v2/applications/{domain}/logs</code></p></td><td><p>Search application log entries.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/v2/applications/{domain}/deployments/{deploymentId}/logs</code></p></td><td><p>Retrieve logs for a specific deployment.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/v2/applications/{domain}/instances/{instanceId}/logs</code></p></td><td><p>Retrieve logs for a specific instance.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/v2/applications/{domain}/instances/{instanceId}/log-file</code></p></td><td><p>Download the log file for a specific instance.</p></td></tr></tbody></table>

When filtering by time range, the `startTime` and `endTime` parameters require ISO 8601 UTC format
with microsecond precision (`YYYY-MM-DDTHH:mm:ss.SSSSSSZ`), for example,
`2025-12-25T10:00:00.000000Z`. These parameters don’t accept epoch (Unix) timestamps.

## Notifications and Alerts

Use these endpoints to manage notifications and configure alerts for your CloudHub applications.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Method</th><th>Endpoint</th><th>Description</th></tr></thead><tbody><tr><td><p><code>GET</code></p></td><td><p><code>/notifications</code></p></td><td><p>List notifications.</p></td></tr><tr><td><p><code>POST</code></p></td><td><p><code>/notifications</code></p></td><td><p>Create a notification.</p></td></tr><tr><td><p><code>PUT</code></p></td><td><p><code>/notifications/{notificationId}</code></p></td><td><p>Mark a notification as read or unread.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/v2/alerts</code></p></td><td><p>List alerts for an application.</p></td></tr><tr><td><p><code>POST</code></p></td><td><p><code>/v2/alerts</code></p></td><td><p>Create an alert.</p></td></tr><tr><td><p><code>PUT</code></p></td><td><p><code>/v2/alerts/{alertId}</code></p></td><td><p>Update an alert.</p></td></tr><tr><td><p><code>DELETE</code></p></td><td><p><code>/v2/alerts/{alertId}</code></p></td><td><p>Delete an alert.</p></td></tr></tbody></table>

For more information, see [Custom Application Alerts and Notifications](https://docs.mulesoft.com/cloudhub/custom-application-alerts).

## Schedules

Use these endpoints to view and update scheduled jobs for your CloudHub applications.

> [!NOTE] These schedules endpoints don’t return scheduler or domain details for CloudHub 2.0
> applications. To manage schedulers for CloudHub 2.0 apps, use the CloudHub 2.0 APIs or the Runtime
> Manager **Schedules** tab. See [Managing App Schedules](https://docs.mulesoft.com/cloudhub-2/ch2-manage-schedules).

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Method</th><th>Endpoint</th><th>Description</th></tr></thead><tbody><tr><td><p><code>GET</code></p></td><td><p><code>/applications/{domain}/schedules</code></p></td><td><p>List all schedules for an application.</p></td></tr><tr><td><p><code>PUT</code></p></td><td><p><code>/applications/{domain}/schedules</code></p></td><td><p>Update all schedules for an application.</p></td></tr><tr><td><p><code>PUT</code></p></td><td><p><code>/applications/{domain}/schedules/{scheduleId}</code></p></td><td><p>Update a specific schedule.</p></td></tr></tbody></table>

For more information, see [Manage Schedules](https://docs.mulesoft.com/cloudhub/managing-schedules).

## Load Balancers

Use these endpoints to create, configure, and manage dedicated load balancers (DLBs) for your
CloudHub applications.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Method</th><th>Endpoint</th><th>Description</th></tr></thead><tbody><tr><td><p><code>GET</code></p></td><td><p><code>/organizations/{orgId}/loadbalancers</code></p></td><td><p>List load balancers in an organization.</p></td></tr><tr><td><p><code>POST</code></p></td><td><p><code>/organizations/{orgId}/vpcs/{vpcId}/loadbalancers</code></p></td><td><p>Create a load balancer.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/organizations/{orgId}/vpcs/{vpcId}/loadbalancers/{lbId}</code></p></td><td><p>Get details for a specific load balancer.</p></td></tr><tr><td><p><code>PATCH</code></p></td><td><p><code>/organizations/{orgId}/vpcs/{vpcId}/loadbalancers/{lbId}</code></p></td><td><p>Update a load balancer (mapping rules, certificates, cipher suites).</p></td></tr><tr><td><p><code>DELETE</code></p></td><td><p><code>/organizations/{orgId}/vpcs/{vpcId}/loadbalancers/{lbId}</code></p></td><td><p>Delete a load balancer.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/organizations/{orgId}/loadbalancers/ciphersuites</code></p></td><td><p>List available cipher suites.</p></td></tr><tr><td><p><code>POST</code></p></td><td><p><code>/organizations/{orgId}/logs/download</code></p></td><td><p>Initiate a DLB log download.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/organizations/{orgId}/logs/download/status</code></p></td><td><p>Check DLB log download status.</p></td></tr></tbody></table>

For detailed curl examples, see [Create a Load Balancer with the CloudHub API](https://docs.mulesoft.com/cloudhub/lb-create-api),
[Certificate Validation in Dedicated Load Balancers](https://docs.mulesoft.com/cloudhub/lb-cert-validation),
[Dedicated Load Balancer Mapping Rules](https://docs.mulesoft.com/cloudhub/lb-mapping-rules), and
[Download Dedicated Load Balancer Logs](https://docs.mulesoft.com/cloudhub/lb-download-logs).

## VPCs, VPNs, and Transit Gateways

Use these endpoints to manage Virtual Private Clouds (VPCs), Virtual Private Networks (VPNs), and
transit gateway attachments for your CloudHub network infrastructure.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Method</th><th>Endpoint</th><th>Description</th></tr></thead><tbody><tr><td><p><code>GET</code></p></td><td><p><code>/organizations/{orgId}/vpcs</code></p></td><td><p>List VPCs in an organization.</p></td></tr><tr><td><p><code>POST</code></p></td><td><p><code>/organizations/{orgId}/vpcs</code></p></td><td><p>Create a VPC.</p></td></tr><tr><td><p><code>PUT</code></p></td><td><p><code>/organizations/{orgId}/vpcs/{vpcId}</code></p></td><td><p>Update a VPC (associated environments, firewall rules).</p></td></tr><tr><td><p><code>DELETE</code></p></td><td><p><code>/organizations/{orgId}/vpcs/{vpcId}</code></p></td><td><p>Remove a VPC.</p></td></tr><tr><td><p><code>POST</code></p></td><td><p><code>/organizations/{orgId}/vpcs/{vpcId}/ipsec</code></p></td><td><p>Create a VPN connection.</p></td></tr><tr><td><p><code>DELETE</code></p></td><td><p><code>/organizations/{orgId}/vpcs/{vpcId}/ipsec/{vpnId}</code></p></td><td><p>Delete a VPN connection.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/organizations/{orgId}/tgws</code></p></td><td><p>List Transit Gateway attachments in an organization.</p></td></tr><tr><td><p><code>POST</code></p></td><td><p><code>/organizations/{orgId}/tgws</code></p></td><td><p>Create a Transit Gateway attachment.</p></td></tr><tr><td><p><code>PUT</code></p></td><td><p><code>/organizations/{orgId}/tgws/{tgwId}</code></p></td><td><p>Update a Transit Gateway attachment.</p></td></tr><tr><td><p><code>DELETE</code></p></td><td><p><code>/organizations/{orgId}/tgws/{tgwId}</code></p></td><td><p>Remove a Transit Gateway attachment.</p></td></tr></tbody></table>

For detailed curl examples, see [Create a VPC with the Anypoint Platform CLI](https://docs.mulesoft.com/cloudhub/create-vpc-cli).

## Diagnostics

Use these endpoints to generate, retrieve, and analyze application diagnostics.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Method</th><th>Endpoint</th><th>Description</th></tr></thead><tbody><tr><td><p><code>GET</code></p></td><td><p><code>/v2/applications/{domain}/instances/diagnostics</code></p></td><td><p>List diagnostics for an application.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/v2/applications/{domain}/instances/{instanceId}/diagnostics</code></p></td><td><p>Get diagnostics for an instance without persisting them.</p></td></tr><tr><td><p><code>POST</code></p></td><td><p><code>/v2/applications/{domain}/instances/{instanceId}/diagnostics</code></p></td><td><p>Generate and persist diagnostics for an instance.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/v2/applications/{domain}/instances/diagnostics/{diagnosticId}/download</code></p></td><td><p>Download a diagnostic.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/v2/applications/{domain}/instances/diagnostics/analysis-readiness</code></p></td><td><p>Check if analysis can be triggered.</p></td></tr><tr><td><p><code>GET</code></p></td><td><p><code>/v2/applications/{domain}/instances/{instanceId}/diagnostics/analysis/latest</code></p></td><td><p>Get the latest analysis for an instance.</p></td></tr><tr><td><p><code>POST</code></p></td><td><p><code>/v2/applications/{domain}/instances/{instanceId}/diagnostics/analyze</code></p></td><td><p>Trigger an analysis for an instance.</p></td></tr></tbody></table>

For more information, see
[Generate Apps Diagnostics and Analyze with Einstein](https://docs.mulesoft.com/cloudhub/ch-diagnostics-agent).

## See Also

- [CloudHub API](https://docs.mulesoft.com/cloudhub/cloudhub-api)

<!-- document id=9d1c6a1ed492ce003de40137401abb3c8d6dd221cc986bcafa0f5a88862d9821 url=/mulesoft/current/en-us/cloudhub/cloudhub-architecture.md -->

---
product: CloudHub
---

# CloudHub Architecture

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

[CloudHub](https://docs.mulesoft.com/cloudhub/) is designed to provide enterprises with a multitenant, secure, elastic, and highly
available integration platform as a service (iPaaS). To maximize your use of CloudHub, you should
understand how the underlying mechanisms of the CloudHub platform work to achieve these goals.

Manage CloudHub with the Anypoint Runtime Manager console in Anypoint Platform. You can also
[deploy](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub) to it directly from Anypoint Studio, via the
[CloudHub REST API](https://docs.mulesoft.com/cloudhub/cloudhub-api) or via the
[Anypoint Platform command-line interface](https://docs.mulesoft.com/anypoint-cli/latest/).

> [!NOTE] See [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies) for a better
> understanding of the different possible deployment scenarios, including on-premises and Anypoint
> Platform Private Cloud Edition (Anypoint PCE).

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](/mulesoft/current/en-us/cloudhub/_images/architecture-diagram.png)

<table><colgroup><col> <col> <col></colgroup><tbody><tr><td><div><div><p><span><img src="https://docs.mulesoft.com/cloudhub/_images/blue-1.png" alt="1 Integration Applications" width="40%"></span></p></div></div></td><td><div><div><p><a href="#integration-applications">Integration Applications</a></p></div></div></td><td><div><div><p>Applications that you create and deploy to CloudHub to perform integration logic for your business</p></div></div></td></tr><tr><td><div><div><p><span><img src="https://docs.mulesoft.com/cloudhub/_images/blue-2.png" alt="2 Runtime Manager" width="40%"></span></p></div></div></td><td><div><div><p><a href="#runtime-manager">Runtime Manager</a></p></div></div></td><td><div><div><p>User interface that enables you to deploy and monitor integrations, and configure your account</p></div></div></td></tr><tr><td><div><div><p><span><img src="https://docs.mulesoft.com/cloudhub/_images/blue-3.png" alt="3 Platform Services" width="40%"></span></p></div></div></td><td><div><div><p><a href="#platform-services">Platform Services</a></p></div></div></td><td><div><div><p>Shared CloudHub platform services and APIs, which includes CloudHub Insight, alerting, logging, account management, virtual private cloud/secure data gateway, and load balancing</p></div></div></td></tr><tr><td><div><div><p><span><img src="https://docs.mulesoft.com/cloudhub/_images/blue-4.png" alt="4 CloudHub 2.0" width="40%"></span></p></div></div></td><td><div><div><p><a href="#global-worker-clouds">Global Worker Clouds</a></p></div></div></td><td><div><div><p>An elastic cloud of <em>workers</em>, Mule instances that run integration applications</p></div></div></td></tr></tbody></table>

> [!NOTE] You can view the live status and detailed service history for the Runtime Manager console,
> platform services, and the CloudHub worker cloud on
> [`status.mulesoft.com`](https://status.salesforce.com/products/Mulesoft) for the default (US
> hosted) Control Plane and
> [`eu1-status.mulesoft.com`](https://status.salesforce.com/products/Mulesoft) 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](https://docs.mulesoft.com/cloudhub/) and
[Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub).

## Runtime Manager

The Runtime Manager console is integrated into the
[Anypoint Platform](https://anypoint.mulesoft.com). 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](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub) as well as to
[other registered servers](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers). You can also
[manage deployed applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications).

Administrator account holders can use the Anypoint Platform to
[add and manage other users in the organization, define user roles](https://docs.mulesoft.com/access-management/managing-permissions),
and create and manage sandbox environments.

For more general information about CloudHub, see [CloudHub](https://docs.mulesoft.com/cloudhub/).

## Platform Services

CloudHub 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](https://docs.mulesoft.com/cloudhub/cloudhub-api).

## CloudHub Workers

_Workers_ are dedicated instances of Mule runtime engine that run your integration applications on
CloudHub.

Workers have the following characteristics:

**Capacity**

Each worker has a specific amount of capacity to process data. 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, such as the US, EU, or Asia-Pacific.

The memory capacity and processing power of a worker depends on how you configure it at the
application level.

Worker sizes have different compute, memory, and storage capacities. You can scale workers
vertically by selecting one of the available worker sizes:

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Worker Size</th><th>Worker Memory</th><th>Heap Memory</th><th>Disk Storage Size</th></tr></thead><tbody><tr><td><div><div><p>0.1 vCores</p></div></div></td><td><div><div><p>1 GB</p></div></div></td><td><div><div><p>500 MB</p></div></div></td><td><div><div><p>8 GB</p></div></div></td></tr><tr><td><div><div><p>0.2 vCores</p></div></div></td><td><div><div><p>2 GB</p></div></div></td><td><div><div><p>1 GB</p></div></div></td><td><div><div><p>8 GB</p></div></div></td></tr><tr><td><div><div><p>1 vCore</p></div></div></td><td><div><div><p>4 GB</p></div></div></td><td><div><div><p>2 GB</p></div></div></td><td><div><div><p>12 GB</p></div></div></td></tr><tr><td><div><div><p>2 vCores</p></div></div></td><td><div><div><p>8 GB</p></div></div></td><td><div><div><p>4 GB</p></div></div></td><td><div><div><p>40 GB</p></div></div></td></tr><tr><td><div><div><p>4 vCores</p></div></div></td><td><div><div><p>16 GB</p></div></div></td><td><div><div><p>8 GB</p></div></div></td><td><div><div><p>88 GB</p></div></div></td></tr><tr><td><div><div><p>8 vCores</p></div></div></td><td><div><div><p>32 GB</p></div></div></td><td><div><div><p>16 GB</p></div></div></td><td><div><div><p>168 GB</p></div></div></td></tr><tr><td><div><div><p>16 vCores</p></div></div></td><td><div><div><p>64 GB</p></div></div></td><td><div><div><p>32 GB</p></div></div></td><td><div><div><p>328 GB</p></div></div></td></tr></tbody></table>

Workers with 0.1 vCores and 0.2 vCores:

- Provide limited CPU and I/O for apps with smaller workloads

- Can burst to higher CPU speeds for a short time

  This ability helps to improve application startup times and to process infrequent, large
  workloads. If you need consistent performance, use workers with more vCores.

Workers with 1 or more vCores provide performance consistency.

Each worker has a minimum of 8 GB of storage allocated, which is used for both system and
application storage, with about 3.0 GB used for OS and Mule components. If your application requires
more storage (for example, verbose logging), use a worker with two or more vCores, enabling the
application to access additional storage.

Only running applications count toward worker usage.

If your applications require more vCores than are available, CloudHub allows you to create the
application, but you cannot start it until the additional vCores become available. To increase vCore
allocation, stop another application or contact your account manager to increase your subscription’s
vCore allocation.

The metaspace limit for apps deployed to CloudHub is currently unlimited, regardless of the worker
size. The initial metaspace size is 128 MB; metaspace garbage collection begins after the metaspace
reaches that threshold.

You can scale your applications horizontally by adding multiple workers and enabling persistent
queues to distribute workloads across workers. See
[Worker Scaleout](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#worker-scale-out) and
[Persistent Queues](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#persistent-queues).

CloudHub monitors workers to verify that they are operating correctly. If you enable automatic
restarts, CloudHub also automatically restarts applications, if necessary.

> [!NOTE] The Limit for the **JVM - Heap Used** graph on Runtime Manager and Anypoint Monitoring can
> sometimes dynamically increase. It technically shows JVM property `maxMemory()` under the hood,
> which means the max amount of memory that JVM attempts to use for the heap. Due to the nature of
> Java, it dynamically changes within the JVM runtime heap size available, depending on a number of
> factors such as memory fragmentation, garbage collection, and other memory management used by JVM.

## Global Worker Clouds

CloudHub offers worker clouds in different regions of the world: North America, South America, the
European Union, and Asia-Pacific. For the complete list of supported regions, see
[Regional Services](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide#regional-services).

This global distribution enables you to host your integration in the location closest to your
services, thus reducing latency. It can also provide for adherence to local laws, such as the EU
Data Protection Directive. For the US and US-Gov control planes, MuleSoft hosts the management
console and platform services in the United States. For the EU control plane, MuleSoft hosts these
services in Europe.

The region that you deploy your application to determines the domain provided for your application.
For example, if you deploy an application named `myapp` to Canada (Central), the domain used to
access the application is `myapp.ca-c1.cloudhub.io`. 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
[Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub). For more information about CloudHub security and
compliance, download the
[Anypoint Cloud Security & Compliance](https://www.mulesoft.com/api/security) 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.

## Availability and Scalability

CloudHub is designed to be highly available and scalable through redundancy, intelligent healing,
and zero-downtime updates. It also enables customers to scale and benefit from added reliability
through [high availability features](https://docs.mulesoft.com/cloudhub/cloudhub-fabric).

### Redundant Platform

All of CloudHub 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 problems and provides a self-healing mechanism to recover
from them. 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](https://docs.mulesoft.com/cloudhub/worker-monitoring#enabling-automatic-restarts).

For more information about application monitoring and automatic restarts, see
[Application Monitoring and Automatic Restarts](https://docs.mulesoft.com/cloudhub/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.

### High Availability

High Availability features provide scalability, workload distribution, and added reliability to
applications on CloudHub. These capabilities are powered by the scalable load-balancing service,
[worker scaleout](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#worker-scaleout), and
[persistent queueing](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#persistent-queues) features.

#### Worker Scale Out and Data Center Redundancy

With [high availability](https://docs.mulesoft.com/cloudhub/cloudhub-fabric), you can add multiple workers to your application to make
it horizontally scale. CloudHub automatically distributes multiple workers for the same application
across two or more data centers 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
[High Availability](https://docs.mulesoft.com/cloudhub/cloudhub-fabric).

## Security

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](https://docs.mulesoft.com/cloudhub/secure-application-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](https://www.mulesoft.com/sites/default/files/security-whitepaper.pdf).

## See Also

- [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide)

- [CloudHub FAQ](https://docs.mulesoft.com/cloudhub/cloudhub-faq)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

- [Maintenance and Upgrade Policy](https://docs.mulesoft.com/cloudhub/maintenance-and-upgrade-policy)

- [status.mulesoft.com](https://status.salesforce.com/products/Mulesoft)

- [eu1-status.mulesoft.com](https://status.salesforce.com/products/Mulesoft)

- [High Availability](https://docs.mulesoft.com/cloudhub/cloudhub-fabric)

- [Application Monitoring and Automatic Restarts](https://docs.mulesoft.com/cloudhub/worker-monitoring)

- [Amazon EC2 Instance Types](https://aws.amazon.com/ec2/instance-types/)

<!-- document id=c16b4507619e5b1d0d79cb8a236e33c273f0bd504d18db6efe8b3e3930788d5f url=/mulesoft/current/en-us/cloudhub/cloudhub-cli.md -->

---
product: CloudHub
---

# CloudHub Command-Line Interface

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Platform provides a scripting and command-line tool for CloudHub. The command-line
interface (CLI) supports both the interactive shell and standard CLI modes and works with:

- [CloudHub Applications](#cloudhub-apps)

- [CloudHub Dedicated Load Balancers](#cloudhub-dlb)

- [CloudHub Anypoint VPCs](#cloudhub-vpc)

## CloudHub Applications

<table><colgroup><col> <col></colgroup><thead><tr><th>Command</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-alert-history-describe">runtime-mgr:cloudhub-alert-history:describe</a></p></div></div></td><td><div><div><p>Describes the history of the alarm</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-alert-list">runtime-mgr:cloudhub-alert:list</a></p></div></div></td><td><div><div><p>Lists all alerts in the environment</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-application-copy">runtime-mgr:cloudhub-application:copy</a></p></div></div></td><td><div><div><p>Copies a CloudHub application</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-application-delete">runtime-mgr:cloudhub:application:delete</a></p></div></div></td><td><div><div><p>Deletes an application</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#deploy-to-cloudhub">runtime-mgr:cloudhub-application:deploy</a></p></div></div></td><td><div><div><p>Deploys a new application</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-application-describe">runtime-mgr:cloudhub-application:describe</a></p></div></div></td><td><div><div><p>Shows application details</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-application-download-logs">runtime-mgr:cloudhub-application:download:logs</a></p></div></div></td><td><div><div><p>Download application logs to specified directory</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-application-list">runtime-mgr:cloudhub:application:list</a></p></div></div></td><td><div><div><p>Lists all applications in the environment</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-application-modify">runtime-mgr:cloudhub-application:modify</a></p></div></div></td><td><div><div><p>Modifies an existing application, optionally updating the ZIP file</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-application-restart">runtime-mgr:cloudhub-application:restart</a></p></div></div></td><td><div><div><p>Restarts a running application</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-application-start">runtime-mgr:cloudhub-application:start</a></p></div></div></td><td><div><div><p>Starts an application</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-application-stop">runtime-mgr:cloudhub-application:stop</a></p></div></div></td><td><div><div><p>Stops a running application</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#runtime-mgr-cloudhub-application-tail-logs">runtime-mgr:cloudhub-application:tail:logs</a></p></div></div></td><td><div><div><p>Tail application logs</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#cloudhub-region-list">cloudhub:region:list</a></p></div></div></td><td><div><div><p>Lists all supported regions</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-apps#cloudhub-runtime-list">cloudhub:runtime:list</a></p></div></div></td><td><div><div><p>Lists all available runtimes</p></div></div></td></tr></tbody></table>

### runtime-mgr:cloudhub-alert-history:describe

\> runtime-mgr:cloudhub-alert-history:describe \[flags\] <name>

Describes the history of the alarm passed in `<name>`

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### runtime-mgr:cloudhub-alert:list

\> runtime-mgr:cloudhub-alert:list \[flags\]

Lists all alerts associated with your current environment

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### runtime-mgr:cloudhub-application:copy

\> runtime-mgr:cloudhub-application:copy <source> <target> \[flags\]

Copies the CloudHub application passed in `source` to the target passed in `target`  
Arguments `source` and `target` should be formatted as follows: `([group_id]/)<asset_id>/<version>`
If `group_id` is not specified, it defaults to the currently selected Organization ID

For example:

\> runtime-mgr:cloudhub-application:copy Services:QA/application-1 Development:QA/application-2

Copies the application named `application-1` from the QA environment of the Services organization to
the QA environment of the Development organization.  
If the Anypoint Platform CLI is using the QA environment in the Services organization, the command
can simply take the application name as a `source`:

\> runtime-mgr:cloudhub-application:copy application-1 Development/QA/application-2

> [!NOTE] Running this command requires your user to have read/write access to the `/tmp` directory
> of the OS where CLI is installed.

In addition to the [default flags](https://docs.mulesoft.com/cloudhub/#default-options), this command accepts the following flags:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Flag</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>--property</code></p></div></div></td><td><div><div><p>Set a property (<code>name:value</code>).</p></div></div></td><td><div><div><p><code>--property "salesforce.password:qa\=34534"</code></p></div></div></td></tr></tbody></table>

> [!NOTE] This command has multi-option flags. When using multi-option flags in a command, either
> put the parameter before the flags or use a \`-- \` (two dashes followed by a space) before the
> parameter.

> [!NOTE] When copying an application containing safely hidden application properties, pass the
> properties in the `copy` command using the `--property` flag. For information about safely hidden
> application properties, see [Safely Hide Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties).

### runtime-mgr:cloudhub-application:delete

\> runtime-mgr:cloudhub-application:delete \[flags\] <name>

Deletes the running application you specify in `<name>`

> [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction,
> it does not ask for confirmation.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### runtime-mgr:cloudhub-application:deploy

\> runtime-mgr:cloudhub-application:deploy <name> <zipfile> \[flags\]

Deploys the Mule deployable archive ZIP file that you specify in `<zipfile>` using the name you set
in `<name>`  
You will have to provide the absolute or relative path to the deployable ZIP file in your local hard
drive and the name you give to your application has to be unique.

> [!NOTE] If successful, this command’s output includes the deployment status of `UNDEPLOYED`, which
> indicates that CloudHub uploaded the application successfully.

In addition to the [default flags](https://docs.mulesoft.com/cloudhub/#default-options), this command accepts the following flags:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Flag</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>--runtime</code></p></div></div></td><td><div><div><p>Name and version of the runtime environment.<br>Use this flag to specify the name and version of the runtime you want to deploy<br>If you don’t specify a runtime version, CloudHub API deploys the latest version available considering the values you select for <code>--javaVersion</code> and <code>--releaseChannel</code>.</p></div></div></td><td><div><div><p><code>--runtime 2.1.1-API-Gateway</code>, <code>--runtime 4.6-e-java8</code> (Edge), <code>--runtime 4.6-e-java17</code> (Edge), <code>--runtime 4.6-java8</code> (LTS), <code>--runtime 4.6-java17</code> (LTS)</p></div></div></td></tr><tr><td><div><div><p><code>--releaseChannel</code></p></div></div></td><td><div><div><p>Set the name of the release channel to be used for the selected Mule version<br>Supported values are <code>NONE</code>, <code>EDGE</code>, and <code>LTS</code><br>If you don’t specify a value, CloudHub API imposes the default value. The default release channel is <code>EDGE</code><br>If you don’t specify a Mule version, the default Mule version for the selected release channel is used. If the selected release channel doesn’t exist, you get an error.</p></div></div></td><td><div><div><p><code>--releaseChannel EDGE</code></p></div></div></td></tr><tr><td><div><div><p><code>--javaVersion</code></p></div></div></td><td><div><div><p>Set the name of the Java version to be used for the selected Mule version<br>Supported values are <code>8</code> and <code>17</code><br>If you don’t specify a value, CloudHub API imposes the default value. The default Java version for Mule 4.6 and earlier versions is '8'.<br>If you don’t specify a Mule version, the default Mule version for the selected Java version is used. If the Java version you select is not available for the specified Mule version, you get an error.</p></div></div></td><td><div><div><p><code>--javaVersion 8</code></p></div></div></td></tr><tr><td><div><div><p><code>--workers</code></p></div></div></td><td><div><div><p>Number of workers<br>Default value is '1'</p></div></div></td><td><div><div><p><code>--workers 3</code></p></div></div></td></tr><tr><td><div><div><p><code>--workerSize</code></p></div></div></td><td><div><div><p>Size of the workers in vCores<br>(Default value is '1'</p></div></div></td><td><div><div><p><code>--workerSize 2</code></p></div></div></td></tr><tr><td><div><div><p><code>--region</code></p></div></div></td><td><div><div><p>Name of the region to deploy to</p></div></div></td><td><div><div><p><code>--region Canada</code></p></div></div></td></tr><tr><td><div><div><p><code>--property</code></p></div></div></td><td><div><div><p>Set a property (<code>name:value</code>)<br>Character <code>:</code> is not supported for the property’s name</p></div></div></td><td><div><div><p><code>--property "salesforce.password:qa\=34534"</code></p></div></div></td></tr><tr><td><div><div><p>`--propertiesFile</p></div></div></td><td><div><div><p>Overwrite all properties with values from this file<br>The file format is 1 or more lines in <code>name:value</code> format<br>Set the absolute path of the properties file in your local hard drive</p></div></div></td><td><div><div><p><code>--propertiesFile exampleFile.JSON</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]persistentQueues</code></p></div></div></td><td><div><div><p>Enable or disable persistent queues<br>Default value is <code>disabled</code></p></div></div></td><td><div><div><p><code>--[no-]persistentQueues</code></p></div></div></td></tr><tr><td><div><div><p>`--[no-]persistentQueuesEncrypted `</p></div></div></td><td><div><div><p>Enable or disable persistent queue encryption<br>Default value is <code>disabled</code></p></div></div></td><td><div><div><p><code>--[no-]persistentQueuesEncrypted</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]staticIPsEnabled</code></p></div></div></td><td><div><div><p>Enable or disable static IPs<br>Default value is <code>disabled</code></p></div></div></td><td><div><div><p><code>--[no-]staticIPsEnabled</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]objectStoreV1</code></p></div></div></td><td><div><div><p>Enable or disable Object Store V<br><code>objectStoreV2</code> can’t also be provided when using <code>objectStoreV1</code> flag</p></div></div></td><td><div><div><p><code>--[no-]objectStoreV1</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]objectStoreV2</code></p></div></div></td><td><div><div><p>Enable or disable Object Store V2<br><code>objectStoreV1</code> can’t also be provided when using <code>objectStoreV2</code> flag</p></div></div></td><td><div><div><p><code>--[no-]objectStoreV2</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]autoRestart</code></p></div></div></td><td><div><div><p>Automatically restart app when not responding<br>Default value is <code>enabled</code></p></div></div></td><td><div><div><p><code>--[no-]autoRestart</code></p></div></div></td></tr><tr><td><div><div><p><code>--output</code></p></div></div></td><td><div><div><p>Specify the response format<br>Supported values are <code>table</code> (default) and <code>json</code></p></div></div></td><td><div><div><p><code>--output json</code></p></div></div></td></tr><tr><td><div><div><p><code>--timeout</code></p></div></div></td><td><div><div><p>Set the timeout value in miliseconds<br>Can take values between <code>60000</code> and <code>300000</code></p></div></div></td><td><div><div><p><code>--timeout 90000</code></p></div></div></td></tr></tbody></table>

> [!NOTE] You won’t be able to allocate static IPs Anypoint Platform CLI. You can simply enable and
> disable them.

> [!IMPORTANT] If you deploy without using any flags, your application deploys using all your
> default values.

> [!NOTE] This command has multi-option flags. When using multi-option flags in a command, either
> put the parameter before the flags or use a \`-- \` (two dashes followed by a space) before the
> parameter.

### runtime-mgr:cloudhub-application:describe

\> runtime-mgr:cloudhub-application:describe \[flags\] <name>

Displays information on the application you pass in `<name>`  
Use the flag `-o json` to get the raw JSON response of the application you specify in `<name>`.  
The command returns data such as the application’s domain, its status, the last time it was updated,
the Mule version, the ZIP file name, the region, monitoring, and workers; as well as `TRUE` or
`FALSE` information for persistent queues and static IPs enablement.

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### runtime-mgr:cloudhub-application:download-logs

\> runtime-mgr:cloudhub-application:download-logs \[flags\] <name> <directory>

Downloads logs the for application specified in `<name>` to the specified directory

Contrarily to what you see in the UI, the logs you download from the CLI won’t separate system logs
from worker logs.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### runtime-mgr:cloudhub-application:list

\> runtime-mgr:cloudhub-application:list \[flags\]

Lists all applications available in your Anypoint Platform CLI  
It returns your application name, its status, the number of vCores assigned and the last time it was
updated.

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### runtime-mgr:cloudhub-application:modify

\> runtime-mgr:cloudhub-application:modify <name> \[zipfile\] \[flags\]

Updates the settings of an existing application  
Optionally, you can update it by uploading a new ZIP file. This command can take all the same flags
as the `deploy` command.

> [!NOTE] This command’s output includes `Status`, which is the application’s previous deployment
> status state.

> [!NOTE] This command has multi-option flags. When using multi-option flags in a command, either
> put the parameter before the flags or use a \`-- \` (two dashes followed by a space) before the
> parameter.

In addition to the [default flags](https://docs.mulesoft.com/cloudhub/#default-options), this command accepts the following flags:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Flag</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>--runtime</code></p></div></div></td><td><div><div><p>Name and version of the runtime environment.<br>Use this flag to specify the name and version of the runtime you want to deploy<br>If you don’t specify a runtime version, CloudHub API deploys the latest version available considering the values you select for <code>--javaVersion</code> and <code>--releaseChannel</code>.</p></div></div></td><td><div><div><p><code>--runtime 2.1.1-API-Gateway</code>, <code>--runtime 4.6-e-java8</code> (Edge), <code>--runtime 4.6-e-java17</code> (Edge), <code>--runtime 4.6-java8</code> (LTS), <code>--runtime 4.6-java17</code> (LTS)</p></div></div></td></tr><tr><td><div><div><p><code>--releaseChannel</code></p></div></div></td><td><div><div><p>Set the name of the release channel to be used for the selected Mule version<br>Supported values are <code>NONE</code>, <code>EDGE</code>, and <code>LTS</code><br>If you don’t specify a value, CloudHub API imposes the default value. The default release channel is <code>EDGE</code><br>If you don’t specify a Mule version, the default Mule version for the selected release channel is used. If the selected release channel doesn’t exist, you get an error.</p></div></div></td><td><div><div><p><code>--releaseChannel EDGE</code></p></div></div></td></tr><tr><td><div><div><p><code>--javaVersion</code></p></div></div></td><td><div><div><p>Set the name of the Java version to be used for the selected Mule version<br>Supported values are <code>8</code> and <code>17</code><br>If you don’t specify a value, CloudHub API imposes the default value. The default Java version for Mule 4.6 and earlier versions is '8'.<br>If you don’t specify a Mule version, the default Mule version for the selected Java version is used. If the Java version you select is not available for the specified Mule version, you get an error.</p></div></div></td><td><div><div><p><code>--javaVersion 8</code></p></div></div></td></tr><tr><td><div><div><p><code>--workers</code></p></div></div></td><td><div><div><p>Number of workers<br>Default value is '1'</p></div></div></td><td><div><div><p><code>--workers 3</code></p></div></div></td></tr><tr><td><div><div><p><code>--workerSize</code></p></div></div></td><td><div><div><p>Size of the workers in vCores<br>(Default value is '1'</p></div></div></td><td><div><div><p><code>--workerSize 2</code></p></div></div></td></tr><tr><td><div><div><p><code>--region</code></p></div></div></td><td><div><div><p>Name of the region to deploy to</p></div></div></td><td><div><div><p><code>--region Canada</code></p></div></div></td></tr><tr><td><div><div><p><code>--property</code></p></div></div></td><td><div><div><p>Set a property (<code>name:value</code>)<br>Character <code>:</code> is not supported for the property’s name</p></div></div></td><td><div><div><p><code>--property "salesforce.password:qa\=34534"</code></p></div></div></td></tr><tr><td><div><div><p>`--propertiesFile</p></div></div></td><td><div><div><p>Overwrite all properties with values from this file<br>The file format is 1 or more lines in <code>name:value</code> format<br>Set the absolute path of the properties file in your local hard drive</p></div></div></td><td><div><div><p><code>--propertiesFile exampleFile.JSON</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]persistentQueues</code></p></div></div></td><td><div><div><p>Enable or disable persistent queues<br>Default value is <code>disabled</code></p></div></div></td><td><div><div><p><code>--[no-]persistentQueues</code></p></div></div></td></tr><tr><td><div><div><p>`--[no-]persistentQueuesEncrypted `</p></div></div></td><td><div><div><p>Enable or disable persistent queue encryption<br>Default value is <code>disabled</code></p></div></div></td><td><div><div><p><code>--[no-]persistentQueuesEncrypted</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]staticIPsEnabled</code></p></div></div></td><td><div><div><p>Enable or disable static IPs<br>Default value is <code>disabled</code></p></div></div></td><td><div><div><p><code>--[no-]staticIPsEnabled</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]objectStoreV1</code></p></div></div></td><td><div><div><p>Enable or disable Object Store V<br><code>objectStoreV2</code> can’t also be provided when using <code>objectStoreV1</code> flag</p></div></div></td><td><div><div><p><code>--[no-]objectStoreV1</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]objectStoreV2</code></p></div></div></td><td><div><div><p>Enable or disable Object Store V2<br><code>objectStoreV1</code> can’t also be provided when using <code>objectStoreV2</code> flag</p></div></div></td><td><div><div><p><code>--[no-]objectStoreV2</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]autoRestart</code></p></div></div></td><td><div><div><p>Automatically restart app when not responding<br>Default value is <code>enabled</code></p></div></div></td><td><div><div><p><code>--[no-]autoRestart</code></p></div></div></td></tr><tr><td><div><div><p><code>--output</code></p></div></div></td><td><div><div><p>Specify the response format<br>Supported values are <code>table</code> (default) and <code>json</code></p></div></div></td><td><div><div><p><code>--output json</code></p></div></div></td></tr><tr><td><div><div><p><code>--timeout</code></p></div></div></td><td><div><div><p>Set the timeout value in miliseconds<br>Can take values between <code>60000</code> and <code>300000</code></p></div></div></td><td><div><div><p><code>--timeout 90000</code></p></div></div></td></tr></tbody></table>

### runtime-mgr:cloudhub-application:restart

\> runtime-mgr:cloudhub-application:restart \[flags\] <name>

Restarts the running application you specify in `<name>`

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### runtime-mgr:cloudhub-application:start

\> runtime-mgr:cloudhub-application:start \[flags\] <name>

Starts the running application you specify in `<name>`

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### runtime-mgr:cloudhub-application:stop

\> runtime-mgr:cloudhub-application:stop \[flags\] <name>

Stops the running application you specify in `<name>`

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### runtime-mgr:cloudhub-application:tail-logs

\> runtime-mgr:cloudhub-application:tail-logs \[flags\] <name>

Tails application logs

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:region:list

\> cloudhub:region:list \[flags\]

Lists all supported regions

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:runtime:list

\> cloudhub:runtime:list \[flags\]

Lists all supported runtimes

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

## CloudHub Dedicated Load Balancers

<table><colgroup><col> <col></colgroup><thead><tr><th>Command</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-allowlist-add">cloudhub:load-balancer:allowlist:add</a></p></div></div></td><td><div><div><p>Adds an IP or range of IPs to the load balancer allowlist</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-allowlist-remove">cloudhub:load-balancer:allowlist:remove</a></p></div></div></td><td><div><div><p>Removes an IP or range of IPs from the load balancer allowlist</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-create">cloudhub:load-balancer:create</a></p></div></div></td><td><div><div><p>Creates a load balancer</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-delete">cloudhub:load-balancer:delete</a></p></div></div></td><td><div><div><p>Deletes a load balancer</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-describe">cloudhub:load-balancer:describe</a></p></div></div></td><td><div><div><p>Shows load balancer details</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-dynamic-ips-disable">cloudhub:load-balancer:dynamic-ips:disable</a></p></div></div></td><td><div><div><p>Disables dynamic IPs</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-dynamic-ips-enable">cloudhub:load-balancer:dynamic-ips:enable</a></p></div></div></td><td><div><div><p>Enables dynamic IPs</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-list">cloudhub:load-balancer:list</a></p></div></div></td><td><div><div><p>Lists all load balancers in an organization</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-mappings-add">cloudhub:load-balancer:mappings:add</a></p></div></div></td><td><div><div><p>Adds a proxy mapping rule at the specified index</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-mappings-describe">cloudhub:load-balancer:mappings:describe</a></p></div></div></td><td><div><div><p>Lists the proxy mapping rules for a load balancer</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-mappings-remove">cloudhub:load-balancer:mappings:remove</a></p></div></div></td><td><div><div><p>Removes a proxy mapping rule</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-ssl-endpoint-add">cloudhub:load-balancer:ssl-endpoint:add</a></p></div></div></td><td><div><div><p>Adds an additional certificate to an existing load balancer</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-ssl-endpoint-describe">cloudhub:load-balancer:ssl-endpoint:describe</a></p></div></div></td><td><div><div><p>Shows the load balancer configuration for a particular certificate</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-ssl-endpoint-remove">cloudhub:load-balancer:ssl-endpoint:remove</a></p></div></div></td><td><div><div><p>Removes a certificate from a load balancer</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-ssl-endpoint-set-default">cloudhub:load-balancer:ssl-endpoint:set-default</a></p></div></div></td><td><div><div><p>Sets the default certificate that the load balancer will serve</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-start">cloudhub:load-balancer:start</a></p></div></div></td><td><div><div><p>Starts a load balancer</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-stop">cloudhub:load-balancer:stop</a></p></div></div></td><td><div><div><p>Stops a load balancer</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-whitelist-add">cloudhub:load-balancer:whitelist:add</a></p></div></div></td><td><div><div><p>Adds an IP or range of IPs to the load balancer allowlist</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-whitelist-remove">cloudhub:load-balancer:whitelist:remove</a></p></div></div></td><td><div><div><p>Removes an IP or range of IPs from the load balancer allowlist</p></div></div></td></tr></tbody></table>

### cloudhub:load-balancer:allowlist:add

\> cloudhub:load-balancer:allowlist:add \[flags\] <name> <cidrBlock>

Adds a range of IP addresses specified in `<cidrBlock>` to the allowlist of the load balancer
specified in `<name>`

> [!NOTE] The allowlist works at the load balancer level, not at the CN certificate level. Make sure
> you only pass IP addresses formatted in
> [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#IPv4_CIDR_blocks).

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:allowlist:remove

\> cloudhub:load-balancer:allowlist:remove <name> <cidrBlock>

Removes an IP or range of IPs addresses specified in `<cidrBlock>` to the allowlist of the load
balancer specified in `<name>`

> [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction,
> it does not ask for confirmation.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:create

\> cloudhub:load-balancer:create \[flags\] <vpc> <name> <certificate> <privateKey>

Creates a load balancer using the specified values in the following variables:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Value</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><p><code>vpc</code></p></td><td><div><div><p>Name of the Anypoint VPC to which this load balancer is bound.<br>If your Anypoint VPC name contains spaces, you need to pass it between ´"´ characters.</p></div></div></td><td><div><div><p><code>vpc-demo</code></p></div></div></td></tr><tr><td><p><code>name</code></p></td><td><div><div><p>Name for the load balancer.</p></div></div></td><td><div><div><p><code>newtestloadbalancer</code></p></div></div></td></tr><tr><td><p><code>certificate</code></p></td><td><div><div><p>Absolute path to the <code>.pem</code> file of your server certificate in your local hard drive.<br>Your certificate files need to be PEM encoded and not encrypted.</p></div></div></td><td><div><div><p><code>/Users/mule/Documents/cert.pem</code></p></div></div></td></tr><tr><td><p><code>privateKey</code></p></td><td><div><div><p>Absolute path to the <code>.pem</code> file of your private key of the server certificate in your local hard drive.<br>Your private key file needs to be passphraseless.</p></div></div></td><td><div><div><p><code>/Users/mule/Documents/privateKey.pem</code></p></div></div></td></tr></tbody></table>

> [!CAUTION] The name for the load balancer that you pass in `<name>` must be unique.  
> By default, your load balancer listens external requests on HTTPS and communicates with your
> workers internally through 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](#cloudhub-load-balancer-mappings-add) command.

In addition to the [default flags](https://docs.mulesoft.com/cloudhub/#default-options), this command accepts the following flags:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Flag</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>--clientCertificate</code></p></div></div></td><td><div><div><p>Client certificate file</p></div></div></td><td><div><div><p><code>--clientCertificate /Users/mule/Documents/CertificateFile.pem</code></p></div></div></td></tr><tr><td><div><div><p><code>--crl</code></p></div></div></td><td><div><div><p>Certificate revocation list file</p></div></div></td><td><div><div><p><code>--crl /Users/mule/Documents/crlFile.pem</code></p></div></div></td></tr><tr><td><div><div><p><code>--http</code></p></div></div></td><td><div><div><p>Specifies the Load balancer HTTP behavior. It can be set to <code>on</code> (accepts HTTP requests and forwards it to your configured default <code><em>sslendpoint</em></code>), <code>off</code> (refuses all HTTP requests), or <code>redirect</code> (redirects to HTTPS).</p></div></div></td><td><div><div><p><code>--http off</code></p></div></div></td></tr><tr><td><div><div><p><code>--transportDownstreamProtocols</code></p></div></div></td><td><div><div><p>TLS version used for communication between customer and DLB<br>Supported values: <code>TLSv1.2</code>, <code>TLSv1.3</code></p></div></div></td><td><div><div><p><code>--transportDownstreamProtocols=TLSv1.2</code></p></div></div></td></tr><tr><td><div><div><p><code>--transportUpstreamProtocols</code></p></div></div></td><td><div><div><p>TLS version used for communication between DLB and Mule worker<br>Supported values: <code>TLSv1.2</code>, <code>TLSv1.3</code></p></div></div></td><td><div><div><p><code>--transportUpstreamProtocols=TLSv1.2</code></p></div></div></td></tr><tr><td><div><div><p><code>--[no-]dynamic-ips</code></p></div></div></td><td><div><div><p>Uses dynamic IPs, which are not persistent through restarts</p></div></div></td><td><div><div><p><code>--[no-]dynamic-ips</code></p></div></div></td></tr><tr><td><div><div><p><code>--verificationMode</code></p></div></div></td><td><div><div><p>Specifies the client verification mode. It can be set to <code>on</code> (verify always), <code>off</code> (don’t verify), or <code>optional</code> (verification optional).</p></div></div></td><td><div><div><p><code>--verificationMode optional</code></p></div></div></td></tr></tbody></table>

> [!NOTE] CloudHub does not implement the Online Certificate Status Protocol (OCSP). To keep your
> certification revocation list up to date, it’s recommended to use the
> [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)
> to update your certificates programmatically.

For more configuration information, see
[Configure SSL Endpoints and Certificates](https://docs.mulesoft.com/cloudhub/lb-ssl-endpoints).

### cloudhub:load-balancer:delete

\> cloudhub:load-balancer:delete \[flags\] <name>

Deletes the load balancer specified in `<name>`.

> [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction,
> it does not ask for confirmation.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:describe

\> cloudhub:load-balancer:describe \[flags\] <name>

Displays information about the load balancer that is specified in `<name>`  
Use the flag `-o json` to get the raw JSON response of the application you specify in `<name>`  
It displays load balancer’s name, domain, its state and the Anypoint VPC Id to which the load
balancer is bound.

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:dynamic-ips:disable

\> cloudhub:load-balancer:dynamic-ips:disable \[flags\] <name>

Disables dynamic IPs for the load balancer specified in `<name>`

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:dynamic-ips:enable

\> cloudhub:load-balancer:dynamic-ips:enable \[flags\] <name>

Enables dynamic IPs for the load balancer specified in `<name>`

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:list

\> cloudhub:load-balancer:list \[flags\]

Lists all load balancers in your Anypoint Platform  
It displays load balancer’s name, domain, its state, and the Anypoint VPC ID to which the load
balancer is bound.

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:mappings:add

\> cloudhub:load-balancer:mappings:add \[flags\] <name> <index> <inputUri> <appName> <appUri>
\[certificateName\]

Adds a proxy mapping rule to the load balancer specified in `<name>` in the CN passed under the
`certificateName` flag.  
If no `certificateName` is passed, Anypoint Platform CLI adds the mappings to the default SSL
endpoint.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Value</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>name</code></p></div></div></td><td><div><div><p>Name of the load balancer to which this rule is applied.</p></div></div></td><td><div><div><p><code>testloadbalancer</code></p></div></div></td></tr><tr><td><div><div><p><code>inputUri</code></p></div></div></td><td><div><div><p>Name of the URI of your input URL</p></div></div></td><td><div><div><p><code>example.com</code></p></div></div></td></tr><tr><td><div><div><p><code>appName</code></p></div></div></td><td><div><div><p>Name of the app of your output URL to which the request is forwarded</p></div></div></td><td><div><div><p><code>{app}-example</code></p></div></div></td></tr><tr><td><div><div><p><code>appUri</code></p></div></div></td><td><div><div><p>URI of the app of your output URL to which the request is forwarded</p></div></div></td><td><div><div><p>/</p></div></div></td></tr></tbody></table>

For the values in the example above, for an input call to
`my-superapp.api.example.com/status?limit=10`, the endpoint `my-superapp-example: /status?limit=10`
will be called for the application.

If no upstream protocol is set, HTTP is used as default.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Flag</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p>`--certificateName `</p></div></div></td><td><div><div><p>Certificate name</p></div></div></td><td><div><div><p><code>--certificateName exampleName</code></p></div></div></td></tr><tr><td><div><div><p><code>--upstreamProtocol &lt;protocol&gt;</code></p></div></div></td><td><div><div><p>Set the protocol used by your application to communicate internally with your load balancer<br>Supported Values: <code>http</code>, <code>https</code></p></div></div></td><td><div><div><p><code>--upstreamProtocol http</code></p></div></div></td></tr></tbody></table>

### cloudhub:load-balancer:mappings:describe

\> cloudhub:load-balancer:mappings:describe <name> \[certificateName\]

Lists the mapping rules for the load balancer specified in `<name>`  
If no `certificateName` is passed, Anypoint Platform CLI returns the mappings for the default SSL
endpoint.

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:mappings:remove

\> cloudhub:load-balancer:mappings:remove \[flags\] <name> <index> \[certificateName\]

Removes the proxy mapping rules from the load balancer specified in `<name>` at the priority index
specified in `<index>` and the CN specified as the `certificateName` flag  
If no `certificateName` is passed, Anypoint Platform CLI removes the mappings for the default SSL
endpoint.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:ssl-endpoint:add

\> cloudhub:load-balancer:ssl-endpoint:add \[flags\] <name> <certificate> <privateKey>

Adds an SSL endpoint to the load balancer specified in `<name>`, using the certificate and private
key passed:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Value</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>name</code></p></div></div></td><td><div><div><p>Name for the load balancer.</p></div></div></td><td><div><div><p><code>newtestloadbalancer</code></p></div></div></td></tr><tr><td><div><div><p><code>certificate</code></p></div></div></td><td><div><div><p>Absolute path to the <code>.pem</code> file of your certificate in your local hard drive.<br>Your certificate files need to be PEM encoded and not encrypted.</p></div></div></td><td><div><div><p><code>/Users/mule/Documents/cert.pem</code></p></div></div></td></tr><tr><td><div><div><p><code>privateKey</code></p></div></div></td><td><div><div><p>Absolute path to the <code>.pem</code> file of your private key in your local hard drive.<br>Your private key file needs to be passphraseless.</p></div></div></td><td><div><div><p><code>/Users/mule/Documents/privateKey.pem</code></p></div></div></td></tr></tbody></table>

> [!NOTE] CloudHub does not implement the Online Certificate Status Protocol (OCSP). To keep your
> certification revocation list up to date, it’s recommended to use the
> [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)
> to update your certificates programmatically.

In addition to the [default flags](https://docs.mulesoft.com/cloudhub/#default-options), this command accepts the following flags:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Flag</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>--clientCertificate</code></p></div></div></td><td><div><div><p>Client certificate file</p></div></div></td><td><div><div><p><code>--clientCertificate /Users/mule/Documents/CertificateFile.pem</code></p></div></div></td></tr><tr><td><div><div><p><code>--crl</code></p></div></div></td><td><div><div><p>Certificate Revocation List file</p></div></div></td><td><div><div><p><code>--clientCertificate /Users/mule/Documents/crlFile.pem</code></p></div></div></td></tr><tr><td><div><div><p><code>--verificationMode</code></p></div></div></td><td><div><div><p>Specifies the client verification mode. It can be set to <code>on</code> (verify always) <code>off</code> (don’t verify) or <code>optional</code> (Verification optional).</p></div></div></td><td><div><div><p><code>--verificationMode on</code></p></div></div></td></tr></tbody></table>

For more configuration information, see
[Configure SSL Endpoints and Certificates](https://docs.mulesoft.com/cloudhub/lb-ssl-endpoints).

### cloudhub:load-balancer:ssl-endpoint:describe

\> cloudhub:load-balancer:ssl-endpoint:set-describe \[flags\] <name> <certificateName>

Shows information about the configuration of the load balancer passed in `<name>` for the
certificate specified in `<certificateName>`

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:ssl-endpoint:remove

\> cloudhub:load-balancer:ssl-endpoint:remove \[flags\] <name> <certificateName>

Removes the ssl certificate specified in `<certificateName>` from the load balancer specified in
`<name>`

> [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction,
> it does not ask for confirmation.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:ssl-endpoint:set-default

\> cloudhub:load-balancer:ssl-endpoint:set-default \[flags\] <name> <certificateName>

Sets the certificate specified in `<certificateName>` as the default certificate for the load
balancer passed in `<name>`

In addition to the [default flags](https://docs.mulesoft.com/cloudhub/#default-options), this command accepts the following flags:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Flag</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>--http</code></p></div></div></td><td><div><div><p>Specifies the Load balancer HTTP behavior<br>It can be set to <code>on</code> (accepts HTTP requests and forwards it to your configured default <code><em>sslendpoint</em></code>), <code>off</code> (refuses all HTTP requests), or <code>redirect</code> (redirects to HTTPS)</p></div></div></td><td><div><div><p><code>--http redirect</code></p></div></div></td></tr></tbody></table>

### cloudhub:load-balancer:start

\> cloudhub:load-balancer:start \[flags\] <name>

Starts the load balancer specified in `<name>`

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:stop

\> cloudhub:load-balancer:stop \[flags\] <name>

Stops the load balancer specified in `<name>`

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:whitelist:add

\> cloudhub:load-balancer:whitelist:add \[flags\] <name> <cidrBlock>

Adds a range of IP addresses specified in `<cidrBlock>` to the allowlist of the load balancer
specified in `<name>`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:load-balancer:whitelist:remove

\> cloudhub:load-balancer:whitelist:remove \[flags\] <name> <cidrBlock>

Removes an IP or range of IPs specified in `<cidrBlock>` from the allowlist of the load balancer
specified in `<name>`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

## CloudHub Anypoint VPCs

<table><colgroup><col> <col></colgroup><thead><tr><th>Command</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-business-groups-add">cloudhub:vpc:business-groups:add</a></p></div></div></td><td><div><div><p>Shares an Anypoint VPC with a list of Business Groups</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-business-groups-remove">cloudhub:vpc:business-groups:remove</a></p></div></div></td><td><div><div><p>Shares an Anypoint VPC with a list of Business Groups</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-create">cloudhub:vpc:create</a></p></div></div></td><td><div><div><p>Creates a new Anypoint VPC</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-delete">cloudhub:vpc:delete</a></p></div></div></td><td><div><div><p>Deletes an existing Anypoint VPC</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-describe">cloudhub:vpc:describe</a></p></div></div></td><td><div><div><p>Show Anypoint VPC details</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-dns-servers-set">cloudhub:vpc:dns-servers:set</a></p></div></div></td><td><div><div><p>Sets the domain names that are resolved using your internal DNS servers</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-dns-servers-unset">cloudhub:vpc:dns-servers:unset</a></p></div></div></td><td><div><div><p>Clears the list domain names that are resolved using your internal DNS servers</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-environments-add">cloudhub:vpc:environments:add</a></p></div></div></td><td><div><div><p>Modifies the Anypoint VPC association to Runtime Manager environments</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-environments-remove">cloudhub:vpc:environments:remove</a></p></div></div></td><td><div><div><p>Modifies the Anypoint VPC association to Runtime Manager environments</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-firewall-rules-add">cloudhub:vpc:firewall-rules:add</a></p></div></div></td><td><div><div><p>Adds a firewall rule for Mule applications in this Anypoint VPC</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-firewall-rules-describe">cloudhub:vpc:firewall-rules:describe</a></p></div></div></td><td><div><div><p>Shows firewall rule for Mule applications in this Anypoint VPC</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-firewall-rules-remove">cloudhub:vpc:firewall-rules:remove</a></p></div></div></td><td><div><div><p>Removes a firewall rule for Mule applications in this Anypoint VPC</p></div></div></td></tr><tr><td><div><div><p><a href="https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-vpc#cloudhub-vpc-list">cloudhub:vpc:list</a></p></div></div></td><td><div><div><p>Lists all Anypoint VPCs</p></div></div></td></tr></tbody></table>

### cloudhub:vpc:business-groups:add

\> cloudhub:vpc:business-groups:add \[flags\] <vpc> <businessGroups...>

Assigns the Anypoint VPC defined in `<vpc>` to the business group(s) passed as argument(s)
thereafter

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:business-groups:remove

\> cloudhub:vpc:business-groups:remove \[flags\] <vpc> <businessGroups...>

Removes the Anypoint VPC defined in `<vpc>` from the business group(s) passed as argument(s)
thereafter

> [!WARNING] This command does not prompt twice before removing the Anypoint VPC from the specified
> resource. If you send a remove instruction, it does not ask for confirmation.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:create

\> cloudhub:vpc:create \[flags\] <name> <region> <cidrBlock> \[environments...\]

Creates an Anypoint VPC using the name in `<name>`, in the region specified in `<region>`, with the
[size](https://docs.mulesoft.com/cloudhub/vpc-provisioning-concept#faq_how_to_size_vpc) passed in `<cidrBlock>` in the form of a
Classless Inter-Domain Routing (CIDR) block, using
[CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#IPv4_CIDR_blocks) and
associates it to the [environments](https://docs.mulesoft.com/access-management/environments) passed as argument(s)
thereafter.

> [!NOTE] An Anypoint VPC needs to be bound to a business group within your organization. When
> creating an Anypoint VPC, make sure to assign it a business group using the
> [business-groups add](#cloudhub-vpc-business-groups-add) command.

This command accepts the `--default` flag. When passed, the Anypoint VPC is created as the default
Anypoint VPC for the selected environment.

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:delete

\> cloudhub:vpc:delete <name>

Deletes the Anypoint VPC specified in `<name>`

> [!WARNING] This command does not prompt twice before deleting. If you send a delete instruction,
> it does not ask for confirmation.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:describe

\> cloudhub:vpc:describe \[flags\] <name>

Displays information about the Anypoint VPC that is specified in `<name>`

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:dns-servers:set

\> cloudhub:vpc:dns-servers:set \[flags\] <vpc>

Sets a list of local host names (internal domain names) to be resolved using your DNS servers for
which you need to provide their IP addresses (whether private or public addresses).  
Whenever those private domains are provided, your worker resolves them using your private DNS, so
you can still use the internal host names of your private network.

> [!NOTE] This feature is supported by workers running Mule versions 3.5.x, 3.6.x, 3.7.4, 3.8.0-HF1,
> 3.8.1 and 3.8.2.

In addition to the [default flags](https://docs.mulesoft.com/cloudhub/#default-options), this command accepts the following flags:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Flag</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>--domain</code></p></div></div></td><td><div><div><p>A domain to resolve on the special DNS server list<br>Can be specified multiple times</p></div></div></td><td><div><div><p><code>--domain example.com</code></p></div></div></td></tr><tr><td><div><div><p><code>--server</code></p></div></div></td><td><div><div><p>IP address for a DNS server to resolve special domains on<br>Can be specified up to 3 times</p></div></div></td><td><div><div><p><code>--server 192.168.1.10</code></p></div></div></td></tr></tbody></table>

Every time you run this command, you overwrite your previous DNS set command.  
To remove a DNS set, you need to use the [vpc dns-servers unset](#cloudhub-vpc-dns-servers-unset)
command.

### cloudhub:vpc:dns-servers:unset

\> cloudhub:vpc:dns-servers:unset \[flags\] <vpc>

Clears the list of local host names (internal domain names) to be resolved using your DNS servers
from the Anypoint VPC passed in `<vpc>`

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:environments:add

\> cloudhub:vpc:environments:add \[flags\] <vpc> \[environments...\]

Assigns the Anypoint VPC defined in `<vpc>` to the environment(s) passed as argument(s) thereafter
The `--default` flag allows setting an Anypoint VPC as the default for the organization, which
applies to all environments which don’t have an Anypoint VPC explicitly associated.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:environments:remove

\> cloudhub:vpc:environments:remove \[flag\] <vpc> \[environments...\]

Removes the Anypoint VPC defined in `<vpc>` from the environment(s) passed as argument(s) thereafter

This command accepts the `--default` flag, that removes this Anypoint VPC as the default Anypoint
VPC for the environment.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:firewall-rules:add

\> cloudhub:vpc:firewall-rules:add \[flags\] <vpc> <cidrBlock> <protocol> <fromPort> \[toPort\]

Adds a firewall rule to the Anypoint VPC defined in `<vpc>` using the values set in the variables:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Value</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>vpc</code></p></div></div></td><td><div><div><p>Name of the Anypoint VPC to which this load balancer is bound<br>If your Anypoint VPC name contains spaces, you need to pass it between ´"´ characters</p></div></div></td><td><div><div><p><code>vpc-demo</code></p></div></div></td></tr><tr><td><div><div><p><code>cidrBlock</code></p></div></div></td><td><div><div><p>IP address in CIDR notation for the firewall to allow</p></div></div></td><td><div><div><p><code>192.0.1.0/27</code></p></div></div></td></tr><tr><td><div><div><p><code>protocol</code></p></div></div></td><td><div><div><p>The protocol to use in the rules. It can be <code>tcp</code> or <code>udp</code></p></div></div></td><td><div><div><p><code>tcp</code></p></div></div></td></tr><tr><td><div><div><p><code>fromPort</code></p></div></div></td><td><div><div><p>The port from which the firewall will allow requests. It can go from 0 to 65535</p></div></div></td><td><div><div><p><code>8888</code></p></div></div></td></tr><tr><td><div><div><p><code>toPort</code></p></div></div></td><td><div><div><p><strong>optional</strong> In case a port range is needed, the <code>fromPort</code> and <code>toPort</code> variables define such range</p></div></div></td><td><div><div><p><code>8090</code></p></div></div></td></tr></tbody></table>

> [!CAUTION] When creating an Anypoint VPC, make sure to allow your outbound address.  
> By default, all IP addresses are blocked, and you need to authorize IP addresses or range of
> addresses to your Anypoint VPC firewall rule.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:firewall-rules:describe

\> cloudhub:vpc:firewall-rules:describe <vpc>

Describes all the firewall rules for the Anypoint VPC defined in `<vpc>`

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:firewall-rules:remove

\> cloudhub:vpc:firewall-rules:remove <vpc> <index>

Removes the firewall rule from the workers inside the Anypoint VPC specified in `<vpc>` at the index
passed in the `<index>`

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

### cloudhub:vpc:list

\> cloudhub:vpc:list \[flags\]

Lists all available Anypoint VPCs  
It returns ID, region, and environment of the network and whether it is the default Anypoint VPC or
not.

Use the `--output` flag to specify the response format. Supported values are `table` (default) and
`json`.

This command accepts the [default flags](https://docs.mulesoft.com/cloudhub/#default-options).

## See Also

- [Anypoint Platform CLI 3.x](https://docs.mulesoft.com/anypoint-cli/latest/)

<!-- document id=0c91cbe216f4d564d0cffa4c50f4307ae2efd261b99cf4f40a25e3cf92e7a671 url=/mulesoft/current/en-us/cloudhub/cloudhub-faq.md -->

---
product: CloudHub
---

# CloudHub FAQ

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

## What is CloudHub?

CloudHub is a cloud-based integration platform as a service (iPaaS) that enables developers to
integrate and orchestrate applications and services while giving operations the control and
visibility they require for mission-critical demands, all without the need to install or manage
middleware or hardware infrastructure. You can deploy applications to CloudHub through Anypoint
Runtime Manager, found on [Anypoint Platform](https://anypoint.mulesoft.com). Read more about the
CloudHub [architecture](https://docs.mulesoft.com/cloudhub/cloudhub-architecture).

## What is iPaaS?

As the name suggests, iPaaS (integration platform as a service) is a development platform for
building integration applications. It provides a set of services and capabilities for integrating
applications in the cloud and within the enterprise. The core tenets of iPaaS are the same as PaaS,
except the services on the platform are geared towards integration. In addition to some base
expectations, such as multi-tenancy, elasticity and reliability, iPaaS also provides intermediation
of data and events, orchestration, a service container for publishing REST and SOAP services, strong
security capabilities, and monitoring and developer tooling.

For more information, see
[Introducing integration PaaS (iPaaS)](https://blogs.mulesoft.com/api-integration/cloud/introducing-integration-paas-ipaas/).

## How can I create a CloudHub account?

As of November 2014, accounts in both CloudHub and Anypoint Platform for APIs have been merged into
a single platform.

An [Anypoint Platform account](https://anypoint.mulesoft.com/home/) gives you access to both the
**Runtime Manager** – for deploying and managing applications both on **CloudHub** and on other
servers – and to the Anypoint Platform for APIs – for creating and managing APIs through their
entire lifecycle.

- [Creating an Account](https://docs.mulesoft.com/access-management/managing-your-account)

- [Managing Accounts Roles and Permissions](https://docs.mulesoft.com/access-management/managing-permissions)

## Where can I get Anypoint Studio?

Anypoint Studio can be downloaded [here](https://www.mulesoft.com/lp/dl/anypoint-mule-studio). From
Studio, you can deploy directly to CloudHub or run your applications locally on an embedded Mule
runtime engine (Mule).

## How much does CloudHub cost?

For specific pricing, reach out to either your account executive or your account development
representative.

## How do I get support?

The CloudHub team is committed to providing the best customer experience possible. Contact the
CloudHub team in the [Salesforce Help](https://help.salesforce.com).

You can browse and search the online
[MuleSoft Trailblazer Community](https://trailhead.salesforce.com/trailblazer-community/neighborhoods/mulesoft)
to find answers. Or post a question and start a new thread.

If you have a paid plan, you can access the Support portal.

To file a case through the Support portal:

1.  Sign in to Anypoint Platform.

2.  From the **?** menu, select **Support Center**.

3.  Click the **Support** tile.

    You can browse open cases or click **Contact Support** to open a new case.

4.  When you create a new case, complete the required fields (marked in red).

    Provide a detailed description of your issue and any supporting information. Hover over the
    information (**i**) icon for field-specific guidelines or instructions.

5.  When finished, click **Submit**.

    The portal generates a unique case number and refers you to possibly relevant areas of the
    knowledge base that you can browse while you await a response to your case.

## What happens when my subscription expires?

Seven days before your Anypoint Platform account subscription expires, you receive an email
notifying you that your account is about to expire and prompting you to contact your account
representative to retain your account.

When your subscription expires, you can’t restart existing apps or create new apps. Running apps
might stop without notice at the discretion of MuleSoft.

To renew your subscription, contact your account representative.

## What is a worker?

Applications that expose real-time services or APIs run on one or more "workers." Each worker is an
instance of Mule that runs your integration applications. See [High Availability](https://docs.mulesoft.com/cloudhub/cloudhub-fabric)
for details of how workers can be shared or doubled to scale your application and provide high
availability.

## What is an integration application?

An integration application is one that integrates two or more applications or services. This might
be as simple as synchronizing Salesforce data to a local database, or as complicated as creating a
mashup using Google Apps, Facebook, and Salesforce. These applications perform functions by grabbing
data from different sources and publishing it to a new location or as a REST or web service. In the
traditional three-tier application model an integration app represents the data tier through
connectivity to application data and the service tier through logic used to combine, transform, and
route this data to consumers.

## What are Anypoint Connectors?

Anypoint Connectors provide an easy way to integrate with SaaS and Cloud APIs, such as Salesforce,
Facebook, AWS, PayPal, and then to use them as services within Mule. With these connectors you are
then able to create orchestration that spans both SaaS and on-premises applications, using Mule.

## What is a Mule flow?

A Mule flow defines how Mule processes messages between different applications. A flow defines a
series of processors that act on a message triggered by an event in an application, a request to a
web or REST service, or a scheduled trigger.

## What Java version are you using?

- Workers that use Mule 4.6.x and later run on JDK 8 or JDK 17.

- Workers that use Mule 4.5.x and later run on JDK 8 or JDK 11.

- Workers that use Mule 4.4.x and later run on JDK 8 or JDK 11.

- Workers that use Mule 4.3.x and later run on JDK 8 or JDK 11.

- Workers that use Mule 4.2.x and later run on JDK 8 or JDK 11.

## How much storage does each worker have?

The amount of storage each worker has depends on the worker size. For information about worker
sizes, see [CloudHub Workers](https://docs.mulesoft.com/cloudhub/cloudhub-architecture#cloudhub-workers).

## What are environment variables?

Environment variables are properties you can set to pass in configuration to your Mule application.
For example, you can create a JDBC connector with a username is set to `${db.username}`. In the
environment variables, you can then set the name to `db.username` and the value to the actual
username when you add or update your application.

## Can I deploy my application to a different region?

Yes! Visit [Salesforce Help](https://help.salesforce.com) to file a support case to enable global
deployments for your account. Applications can be deployed to: US East (N. Virginia, Ohio), US West
(N. California, Oregon), Canada, South America (Brazil - Sao Paulo), Europe (Ireland, Frankfurt), UK
(London), and Asia-Pacific (Sydney, Tokyo, Singapore). Administrators can
[set the default region](https://docs.mulesoft.com/cloudhub/managing-cloudhub-specific-settings) on the **Organization** tab in Account
Settings, but that region can be adjusted when the application is deployed, if necessary.

Note that the domains of applications deployed to different regions are automatically updated to
reflect the region.

## Why do I get "Failed to bind to uri" when my application starts?

If you’re seeing messages like this, it’s because you’re trying to bind to a specific host instead
of 0.0.0.0:

```console
INFO 11-04-06 20:13:50 [DefaultSystemExceptionStrategy] Failed to bind to uri `+http://foo.cloudhub.io:8081/+`
```

Change your HTTP Connector to use 0.0.0.0 instead of your CloudHub domain name, and redeploy.

## How do I stop my application?

In the Runtime Manager console, select your application, and click **Deployment** in the left
navigation bar. Then, click **Stop application**.

## Can the platform restart my Mule app running on CloudHub?

Yes. The following scenarios can result in the platform restarting your application (all restarts
are [zero-downtime](https://docs.mulesoft.com/cloudhub/cloudhub-architecture#zero-downtime-updates), unless the initial state of the
app was down):

- **Underlying infrastructure issues**

  If the underlying infrastructure suffers a failure, the platform migrates your application to a
  new worker.

- **Infrastructure impairment**

  Any applications running on hardware marked as impaired or end-of-life are restarted to
  preemptively migrate the app to a new worker to prevent a possible outage.

- **Security patching**

  If any security vulnerabilities are identified, the relevant applications are patched and
  restarted. See the
  [Critical Security Vulnerabilities](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf)
  policy.

- **Application crash**

  The platform recognizes an application crash (due to a problem with custom code or a bug in the
  underlying stack) and restarts the worker automatically if the automatic restart option is
  selected.

## Why can’t I deploy more than one application?

MuleSoft is limiting the free accounts to one worker, which allows you to deploy one application.
You can upgrade to a
[paid subscription](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration)
to deploy more applications, or you can scale your single application across more than one worker.

## My application has deployed successfully, so why do I see "you need to change the configuration of your docroot" when I go to mysubdomain.cloudhub.io?

If you are seeing this message, your application’s endpoint might be configured to show up in a
different path. If you want to make it show up at mysubdomain.cloudhub.io, reconfigure your endpoint
to remove the path variable. If you are using generic endpoints, change the address (not the path).

## How long is the HTTP read timeout?

Our load balancers time out after 300 seconds if no data is read.

## Can I get a static IP for my application?

You can assign a static IP to your application by using the **Static IPs** application settings tab.
For details, see [Static IPs Tab Settings](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub#static-ips-tab-settings). By
default, you are allocated a number of static IPs equal to twice the number of production vCores in
your subscription. To increase the number of static IPs allocated to your organization, reach out
directly to your Account Team. Your Account Team can start the request process with you.

## How do I know what my static IP is?

The static IPs assigned to your application are displayed in the **Static IPs** tab in the
application settings page.

## Can I modify my application after it has been assigned a static IP?

Yes, you can stop and start the application, upload a new project zip file, change its settings, and
redeploy it.

## In what situations could my static IP change?

Your static IP might be removed or reassigned in a couple of specific situations:

- Deleting an application also removes its static IP. If you create a new application with the same
  name, it has a new dynamically assigned IP address.

- Adding a new application by moving it from Sandbox to Production This requires a new application
  name and a new static IP.

- If [Anypoint Virtual Private Cloud (Anypoint VPC)](https://docs.mulesoft.com/cloudhub/virtual-private-cloud) is built for your
  organization, any existing application that is not already in Anypoint VPC receives a new IP
  address when it restarts inside Anypoint VPC.

- An application is redeployed to a different geographic region.

  You can preallocate a static IP in the new region in the **Static IPs** tab in the application
  settings page.

## Can I request a specific static IP address?

No. CloudHub uses a pool of static IP addresses that are assigned to a CloudHub application only
upon first deployment. If that application releases that static IP, then that IP address returns to
the pool and is available to other applications.

## If I am running in a CloudHub VPC, how do I assign a static IP to my internal private IP?

CloudHub can set the worker’s public IP address to be static. However, the internal private IP
address always remains dynamic. The private IP address is assigned from the range specified in the
CloudHub worker’s address space, which was determined when your
[Anypoint VPC](https://docs.mulesoft.com/cloudhub/virtual-private-cloud) was created.

## What are the possible IP ranges that can be assigned to static IP addresses?

Because CloudHub deploys on Amazon EC2, IP addresses are chosen from the Amazon EC2 IP pool. For a
list of these ranges, see
[Amazon EC2 Public IP Ranges](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html).

## How can I change the timezone for my app?

Customers with an Enterprise account can choose any global region in which to deploy their app. The
actual worker is always running in the UTC timezone.

## Proactive Monitoring

The CloudHub platform is monitored 24 hours a day, 7 days a week, by automated systems. Should any
issue affect the health of the CloudHub infrastructure, the operations team is notified and responds
immediately to diagnose and correct it. This 24x7 monitoring covers the entire CloudHub platform,
benefiting all CloudHub users. You can view the current status of CloudHub services and upcoming
maintenance at [`status.mulesoft.com`](https://status.salesforce.com/products/Mulesoft) and
[`eu1-status.mulesoft.com`](https://status.salesforce.com/products/Mulesoft).

## Can I request access to heap dumps for troubleshooting purposes?

No. Heap dumps cannot be shared. Instead, our **Support Center** representatives can analyze the
dumps and share the required information with you.

## See Also

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)

- [Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [CloudHub](https://docs.mulesoft.com/cloudhub/)

- [Develop Applications for CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

- [CloudHub Architecture](https://docs.mulesoft.com/cloudhub/cloudhub-architecture)

- [Monitor Applications](https://docs.mulesoft.com/runtime-manager/monitoring)

- [High Availability](https://docs.mulesoft.com/cloudhub/cloudhub-fabric)

- [Manage Queues](https://docs.mulesoft.com/cloudhub/managing-queues)

- [Manage Schedules](https://docs.mulesoft.com/cloudhub/managing-schedules)

- [Manage Application Data with Object Stores](https://docs.mulesoft.com/cloudhub/managing-application-data-with-object-stores)

- [Anypoint Platform Command-Line Interface](https://docs.mulesoft.com/anypoint-cli/latest/)

- [Safely Hide Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties)

- [Anypoint Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [Penetration Testing Policies](https://docs.mulesoft.com/cloudhub/penetration-testing-policies)

<!-- document id=8f1b7e4739c20663083ce2d40318c81ffbb463a4d6d7bba7f13ff2bd62e5a439 url=/mulesoft/current/en-us/cloudhub/cloudhub-hadr.md -->

---
product: CloudHub
---

# CloudHub High Availability and Disaster Recovery

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

CloudHub provides high availability (HA) and disaster recovery (DR) that protect your applications
from application and hardware failures.

For an overview of HA and DR across all Mule deployment models, and to compare CloudHub with other
options, see [High Availability and Disaster Recovery](https://docs.mulesoft.com/hosting-home/hadr-guide).

CloudHub runs on Amazon AWS, so its availability depends on Amazon. CloudHub maps each deployment
region to an Amazon region. If an Amazon region goes down, applications in that region become
unavailable, and CloudHub doesn’t replicate them to other regions.

## High Availability Versus Disaster Recovery

High availability (HA) measures a system’s ability to remain accessible when a component fails. You
implement HA by building multiple levels of fault tolerance and load balancing into a system. On
CloudHub, you achieve HA by deploying your application with multiple workers and by enabling
persistent queues where appropriate.

Disaster recovery (DR) restores a system to an acceptable previous state after a natural or man-made
disaster, such as flooding, fires, power failures, server failures, or misconfigurations.

Both strategies increase availability but differ in scope: on CloudHub, HA keeps your application
serving requests through worker and availability-zone failures with no loss of service, whereas DR
restores service and data after a region-level disruption but usually incurs a brief loss of service
while the DR plan runs.

Two measurable objectives drive your DR plan:

Recovery Time Objective (RTO)

The maximum downtime a business tolerates. RTO is the time the system takes to recover after a
disruption.

Recovery Point Objective (RPO)

The maximum data loss a business accepts after a disaster. RPO drives how often you back up data.

## High Availability in CloudHub

CloudHub builds high availability into its default deployment model, and MuleSoft manages it for
you.

When your application uses multiple workers, CloudHub deploys the workers in separate availability
zones by default, which provides HA across availability zones. The distance between availability
zones varies and generally stays under 350 miles.

![CloudHub deploying an application’s workers across separate availability zones within a single region](/mulesoft/current/en-us/cloudhub/_images/hadr-am-web-services.png)

When your application uses a single worker and that availability zone goes down, CloudHub restarts
the application in a different availability zone. The application can experience downtime during the
restart.

To receive alerts when a failure occurs in an availability zone or region, set up
`status.mulesoft.com`.

## Disaster Recovery in CloudHub

MuleSoft manages the CloudHub control plane and worker infrastructure within each region. You own
the cross-region strategy, application-level failover, and data synchronization. Disaster recovery
responsibilities on CloudHub divide between MuleSoft and you:

<table><colgroup><col> <col></colgroup><thead><tr><th>Party</th><th>Responsibility</th></tr></thead><tbody><tr><td><div><div><p>MuleSoft</p></div></div></td><td><div><div><p>Keeps the control plane available, including the Anypoint Platform UI, deployment APIs, and platform services within the provisioned region.</p></div></div></td></tr><tr><td><div><div><p>MuleSoft</p></div></div></td><td><div><div><p>Patches infrastructure, applies security updates, and maintains the worker cloud.</p></div></div></td></tr><tr><td><div><div><p>MuleSoft</p></div></div></td><td><div><div><p>Distributes workers across two or more availability zones within the same region when you use multiple workers.</p></div></div></td></tr><tr><td><div><div><p>MuleSoft</p></div></div></td><td><div><div><p>Restarts applications automatically in a different availability zone when a worker or availability zone fails.</p></div></div></td></tr><tr><td><div><div><p>You</p></div></div></td><td><div><div><p>Define and implement a cross-region DR strategy for your primary and backup regions.</p></div></div></td></tr><tr><td><div><div><p>You</p></div></div></td><td><div><div><p>Decide when to trigger a regional failover, for example, based on health checks or business criteria.</p></div></div></td></tr><tr><td><div><div><p>You</p></div></div></td><td><div><div><p>Configure Global Server Load Balancing (GSLB) or a Dedicated Load Balancer (DLB), and set routing rules that direct traffic to a backup region during a disaster.</p></div></div></td></tr><tr><td><div><div><p>You</p></div></div></td><td><div><div><p>Deploy and maintain applications in more than one region when you need cross-region DR.</p></div></div></td></tr><tr><td><div><div><p>You</p></div></div></td><td><div><div><p>Replicate and back up the external data stores that your applications use across regions, such as databases and object stores.</p></div></div></td></tr><tr><td><div><div><p>You</p></div></div></td><td><div><div><p>Set up Anypoint VPC in each region where you need network connectivity for DR.</p></div></div></td></tr></tbody></table>

MuleSoft keeps the platform and workers resilient within a region, and you own everything that spans
regions: when to fail over, how to route traffic, which applications to run in a backup region, and
how to replicate data.

### Your Responsibilities for Disaster Recovery

If your organization needs cross-region DR, design and operate your applications for it. MuleSoft
doesn’t automatically replicate applications or fail over traffic to another region. You own these
areas:

- **Regional failover strategy** - Decide when to switch traffic to a backup region, for example,
  after a region outage or based on health checks.

- **Traffic management** - Route traffic across regions with a cloud-based or on-premises load
  balancer, such as a Dedicated Load Balancer (DLB) or an external GSLB, and switch to the backup
  region as part of your DR plan.

- **Application deployment** - Deploy the same or equivalent applications in a backup region, and
  keep their configuration and code in sync.

- **Data and state** - Replicate or back up the external data stores that your integrations use,
  such as databases, caches, and object stores, so that applications in a DR region access the data
  they need. Anypoint Object Store v1 and v2 are regional and don’t provide cross-region failover.

For guidance on designing HA and DR topologies, including active-active, warm standby, and cold
standby, see [High Availability and Disaster Recovery](https://docs.mulesoft.com/hosting-home/hadr-guide).

### Restoring After a Disaster

Your restoration steps depend on the DR strategy you put in place. After you confirm that the
primary region or application is unavailable, generally follow these steps:

1.  Switch traffic to the backup region.

    Use your load balancer, such as a GSLB or a Dedicated Load Balancer (DLB), to route traffic to
    the backup region. The health checks you configured mark the primary as unhealthy and direct
    traffic to the backup endpoints.

2.  Bring backup applications online when you use cold or warm standby.

    If the control plane is available, use Anypoint Runtime Manager or the CloudHub API to start or
    scale up the backup application. If the control plane sits in the same region as the failed
    primary, it’s unavailable, and you can’t start or scale applications until the control plane
    recovers, unless you use automation that doesn’t depend on the control plane.

3.  Verify that the backup region serves traffic and that dependent systems use the correct
    endpoints and data stores.

4.  Fail back when the primary region recovers, switching traffic from the backup region to the
    primary and resyncing data as needed.

Your RTO depends on how quickly you complete these steps and, for cold or warm standby, on how long
the backup application takes to start or scale. For active-active setups, traffic continues on the
remaining region without a switch. For more on recovery types and topologies, see
[High Availability and Disaster Recovery Across Deployment Models](https://docs.mulesoft.com/hosting-home/hadr-guide) and
[CloudHub 2.0 High Availability and Disaster Recovery](https://docs.mulesoft.com/cloudhub-2/ch2-ha-dr).

## Considerations and Limitations

Account for these CloudHub behaviors when you plan HA and DR:

Control plane availability

When the US East region goes down, the CloudHub management UI and the REST services that enable
deployments stay unavailable until the region recovers, and you can’t deploy new applications during
that time.

Log and telemetry buffering

While the control plane is unavailable, the runtime plane sends log and telemetry data, and the
worker buffers up to 1 GB of data until the control plane recovers.

Persistent queues

Within a region, persistent queues stay highly available. When the region or part of it goes down,
usually for seconds or minutes, the queues become inaccessible and you might lose some data.
CloudHub resumes communication with the queues after the region recovers.

Object stores

Anypoint Object Store v1, application settings, and insight-related information reside in the US
East region for all applications, and Anypoint Object Store v2 resides in the same region as the
deployed application. For both versions, data persists during a region outage and becomes available
again when the region returns to service. Neither version provides cross-region failover.

Anypoint VPC

Anypoint Virtual Private Cloud (Anypoint VPC) applies at the region level. When a region goes down,
that region’s VPC goes down unless you set up a VPC instance in another region.

### Suggested Alternative Deployment Model

To strengthen your DR strategy, route traffic across regions with a cloud-based or on-premises load
balancer. Configure the load balancer to run health checks and to route traffic to your backup
region when the primary region goes down. For CloudHub-specific options, see
[CloudHub Load Balancers](https://docs.mulesoft.com/cloudhub/dedicated-load-balancer-tutorial) and
[Dedicated Load Balancers](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer).

![A load balancer running health checks and routing traffic to a backup region when the primary region goes down](/mulesoft/current/en-us/cloudhub/_images/hadr-load-balancer.png)

## Best Practices

- Keep your integrations stateless.

- Don’t share transactional information between client invocations or scheduled runs.

- When the middleware must retain data because of a system limitation, store it in an external
  store, such as a database or a messaging queue, rather than in the middleware infrastructure or
  memory.

- As you scale, especially in the cloud, keep each worker’s state and resources independent of the
  other workers to deliver better performance, scalability, and reliability.

## See Also

- [High Availability and Disaster Recovery](https://docs.mulesoft.com/hosting-home/hadr-guide)

- [Anypoint Object Store v2](https://docs.mulesoft.com/object-store/)

- [CloudHub 2.0 High Availability and Disaster Recovery](https://docs.mulesoft.com/cloudhub-2/ch2-ha-dr)

- [Dedicated Load Balancers](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer)

<!-- document id=5f2fd63722af22e60375271f428c99bd5291a574de0789953c083223af778903 url=/mulesoft/current/en-us/cloudhub/cloudhub-fabric.md -->

---
product: CloudHub
---

# CloudHub High Availability Features

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

CloudHub High Availability (HA) features provide scalability, workload distribution, and added
reliability to your applications on CloudHub. This functionality is powered by CloudHub’s scalable
load-balancing service, worker scale-out, and persistent queues features.

You can enable HA features on a per-application basis using the Anypoint Runtime Manager console
when either deploying a new application or redeploying an existing application.

## Prerequisites

CloudHub HA requires:

- A CloudHub Enterprise or Partner account type that allows you to use this feature.

- Familiarity with deploying applications using the Runtime Manager console.

## Worker Scale-out

CloudHub allows you to select an amount and a size for the workers of your application, providing
horizontal scalability. This fine-grained control over computing capacity provisioning gives you the
flexibility to scale up your application to handle higher loads (or scale down during low-load
periods) at any time.

Use the drop-down menus next to **workers** to select the number and size of workers of your
application and to configure the computing power that you need.

Depending on your subscription, you can deploy your application with up to 8 workers of any kind, up
to a maximum of 128 vCores per application. To ensure that you have sufficient resources, see
[CloudHub Workers](https://docs.mulesoft.com/cloudhub/cloudhub-architecture#cloudhub-workers).

Worker scale out also adds additional reliability. Mule runtime engine (Mule) automatically
distributes multiple workers for the same application across two or more data centers for maximum
reliability.

When deploying your application to two or more workers, you can distribute workloads across these
instances of Mule. CloudHub provides the following:

1.  The HTTP load balancing service automatically distributes HTTP requests among your assigned
    workers.

2.  Persistent message queues (see below)

Batch jobs only run on a single worker at a time, and cannot be distributed across multiple workers.
If mule restarts in the same deployment, the status will persist and batch will continue processing.
If the entire application is updated or redeploying while batch is running, the rest of the batch
job will not continue. The main solution for persistent batch jobs in CloudHub is to use Cloud
Object Store.

## Persistent Queues

Persistent queues ensure zero message loss and let you distribute workloads across a set of workers.

- If your application is deployed to more than one worker, persistent queues allow communication
  between workers and workload distribution. For example, if a large file is placed in the queue,
  your workers can divide it up and process it in parallel.

- Persistent queues guarantees delivery of your messages, even if one or more workers or data
  centers go down, providing additional message security for high-stakes processing.

- With persistent queues enabled on your application, you have runtime visibility into your queues
  on the **Queues** tab in the Runtime Manager console.

- You can enable data-at-rest encryption for all your persistent queues. By enabling this feature,
  you ensure that any shared application data written out to a persistent queue is encrypted,
  allowing you to meet your security and compliance needs.

- Retention time for messages in a persistent queue is up to 4 days. There is no limit on message
  size or the number of messages in a persistent queue.

- The worker’s persistent queue is located in the same region as the worker

Note that persistent queues do not guarantee one-time-only message delivery. Duplicate messages may
be sent. If one-time-only message delivery is critical for your use case, do not enable persistent
queues.

To learn more about how to work with persistent queues in your application, see
[Manage Queues](https://docs.mulesoft.com/cloudhub/managing-queues).

## Enable CloudHub HA Features

You can enable and disable either or both features of CloudHub HA in one of two ways:

- When you deploy an application to CloudHub for the first time using the Runtime Manager console

- By accessing the **Deployment** tab in the Runtime Manager console for a previously deployed
  application

  1.  Next to **Workers**, select options from the drop-down menus to define the number and type of
      workers assigned to your application.

See [CloudHub Workers](https://docs.mulesoft.com/cloudhub/cloudhub-architecture#cloudhub-workers) for more information about deploying
to multiple workers.

Click an application to see the overview and click **Manage Application**. Click **Settings** and
click the **Persistent Queues** checkbox to enable queue persistence.

If your application is already deployed, you must redeploy it for your new settings to take effect.

## How HA is Implemented

HTTP load balancing is implemented by an internal reverse proxy server. Requests to the application
(domain) URL `http://appname.cloudhub.io` are automatically load balanced between all the
application’s worker URLs.

Clients can bypass an application’s load balancer by using a worker’s direct URL. See:
[CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide) for more information on how to access an
application in a specific CloudHub worker.

## Use Cases

You can use either, both, or no HA features in a single application.

- To take advantage of persistent queueing, set your Mule application to support this feature. See
  [Building Mule Applications to Support Persistent Queues](#building-mule-applications-to-support-persistent-queues)
  for more information.

- Enabling persistent queues has a performance implication: Putting a small message (50KB or less)
  on a queue can take 10-20 milliseconds (ms); taking the same message off a queue can take 70-100
  milliseconds.

- Adding additional workers increases the cost of service.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Use Case</th><th>Suggested HA Configuration</th><th>Implications</th></tr></thead><tbody><tr><td><div><div><p>You want to scale out your application, but you are satisfied with the existing highly available CloudHub architecture in terms of preventing service interruption or message loss.</p></div></div></td><td><div><div><p>Persistent queues are not enabled.</p></div><div><p>Number of Workers: 2 or more</p></div></div></td><td><div><div><ul><li><p>Application performance is not affected by queue latency.</p></li><li><p>No need to configure your application to support queue persistence.</p></li><li><p>If one data center experiences an outage, your workers are available in a different data center.</p></li></ul></div></div></td></tr><tr><td><div><div><p>You have a high-stakes process for which you need to protect against message loss, but you are not experiencing issues with handling processing load and are OK with some service interruption in the case of a data center outage.</p></div></div></td><td><div><div><p>Persistent queues are enabled.</p></div><div><p>Number of Workers: 1</p></div></div></td><td><div><div><ul><li><p>Application may experience some queue latency.</p></li><li><p>You need to configure your application to support queue persistence before deploying.</p></li><li><p>If the data center in which your worker operates experiences an outage, CloudHub automatically migrates your application to another availability zone. You may experience downtime during the migration; however, your persistent queue ensures zero message loss.</p></li></ul></div></div></td></tr><tr><td><div><div><p>You have a high-stakes process for which you need to protect against message loss, avoid any chance of service interruption, and handle large processing loads.</p></div></div></td><td><div><div><p>Persistent queues are enabled.</p></div><div><p>Number of Workers: 2 or more</p></div></div></td><td><div><div><ul><li><p>Application may experience some queue latency.</p></li><li><p>You need to configure your application to support queue persistence before deploying.</p></li><li><p>If one data center experiences an outage, your workers are automatically distributed to ensure redundancy.</p></li></ul></div></div></td></tr><tr><td><div><div><p>You have an application that does not have any special requirements regarding either processing load or message loss.</p></div></div></td><td><div><div><p>Persistent queues are not enabled.</p></div><div><p>Number of Workers: 1</p></div></div></td><td><div><div><ul><li><p>Application performance is not affected by queue latency.</p></li><li><p>No need to configure your application to support queue persistence.</p></li><li><p>If the data center in which your worker operates experiences an outage, CloudHub automatically migrates your application to another availability zone, but you may experience some downtime and message loss during the migration.</p></li></ul></div></div></td></tr></tbody></table>

## Persistent Queues for Applications Containing Batch Jobs

When you deploy an application containing batch jobs to CloudHub with persistent queues enabled, the
batch jobs use CloudHub persistent queuing for the batch queuing functionality.

If you enable persistent queues, note the following limitations:

- Batch jobs using CloudHub persistent queues experience additional latency.

  For better performance, disable persistent queues.

- CloudHub persistent queues occasionally process a message more than once.

  To ensure that messages are processed only once, disable persistent queues.

- When an application restarts, message loss can occur.

Because of these limitations, Mulesoft recommends that you disable persistent queues for batch jobs.

To disable a persistent queue for a batch job, add the following property to the application:

```xml
batch.persistent.queue.disable=true
```

By default, the value of this property is `false`. When set to true, the application doesn’t use the
persistent queue for the batch job, but the persistent queue remains enabled for other Mule
components.

## Building Mule Applications to Support Persistent Queues

For your application to benefit from persistent queuing, implement reliability patterns in your
application code, separating individual XA transactions from VM transports. See
[Reliability Patterns](https://docs.mulesoft.com/mule-runtime/latest/reliability-patterns) for more information.

![Reliability Pattern](/mulesoft/current/en-us/cloudhub/_images/ch-fabric.png)

The reliable acquisition flow reliably delivers a message from an inbound HTTP connector to an
outbound VM endpoint. If the reliable acquisition flow cannot put the message into the VM queue, it
ensures that the message is not lost by returning an "unsuccessful request" response to the client
so that the client can retry the request.

The application logic flow delivers the message from an inbound VM endpoint to the business logic
processing in your application. This flow represents one transaction. (Your business logic may
involve several other transactions, not shown.)

In between these two flows, a persistent VM queue holds the messages committed by the reliable
acquisition flow until they are ready for processing by the application logic flow. In case of a
processing error within the transaction or in case of a transaction timeout (the time allotted for
the transaction is exceeded), Mule triggers a rollback. This rollback erases any partial processing
that has occurred on the message and places the message back on the queue. If your Mule instance
experiences an outage and is unable to explicitly roll back a transaction, the transaction
automatically rolls back once the time allotted for the transaction is exceeded. The allotted time
is determined by the `timeout` attribute of the transaction element. You can configure the timeout
yourself, or accept the default.

It is helpful to think of each transaction in terms of three steps:

1.  Begin. Mule kicks off the processing of all subcomponents within the transaction.

2.  Commit. Mule sends the result of the completed transaction on to the next step. (For XA
    transactions, the commit step has two phases: a _commit-request phase_ and a _commit phase_.
    During the commit-request phase, Mule coordinates the results of the multiple resources within
    the scope of the transaction and confirms that all processing executed successfully and is ready
    to commit. The commit phase then calls each resource to commit its processing.)

3.  Rollback. If an error occurs in either the Begin or Commit steps, Mule rolls back the operations
    within the transaction so that no one part results in partial completion.

The following code snippet provides an example of an application set up in a reliability pattern
using VM transports for queue persistence on CloudHub.

```xml
<mule xmlns:vm="http://www.mulesoft.org/schema/mule/vm" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd

http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd

http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd

http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/current/mule-vm.xsd

http://www.mulesoft.org/schema/mule/jbossts http://www.mulesoft.org/schema/mule/jbossts/current/mule-jbossts.xsd">

    <vm:connector name="vmConnector" doc:name="VM">
    </vm:connector>
    <http:listener-config name="listener-config" host="..." port="..."/>

    <!-- This is the reliable acquisition flow in the reliability pattern.  -->

    <flow name="reliable-data-acquisition" doc:name="reliable-data-acquisition">
        <http:listener config-ref="listener-config" path="/" doc:name="HTTP Connector"/>
        <expression-filter expression="#[message.inboundProperties.'http.request.path' != '/favicon.ico']" nullReturnsTrue="true" doc:name="Expression"/>
        <vm:outbound-endpoint exchange-pattern="one-way" path="input" connector-ref="vmConnector" doc:name="VM"/>
    </flow>

    <!-- This is the application logic flow in the reliability pattern.
         It is a wrapper around a subflow, "business-logic-processing".
    -->
    <flow name="main-flow" doc:name="main-flow">
        <vm:inbound-endpoint exchange-pattern="one-way" path="input" connector-ref="vmConnector" doc:name="VM">
            <xa-transaction action="ALWAYS_BEGIN" timeout="30000"/>
        </vm:inbound-endpoint>
        <flow-ref name="business-logic-processing" doc:name="Flow Reference"/>
        <vm:outbound-endpoint exchange-pattern="one-way" path="output" connector-ref="vmConnector" doc:name="VM">
    </flow>

    <!--
            This subflow is where the actual business logic is performed.
        -->
    <sub-flow name="business-logic-processing" doc:name="business-logic-processing">
    ....
    </sub-flow>
</mule>
```

### Differences Between Hybrid VM Queues and CloudHub VM Queues

The following table describes key differences between hybrid VM queues and CloudHub VM queues.

<table><colgroup><col> <col></colgroup><thead><tr><th>VM Queues in On-Premises Applications</th><th>VM Queues in Applications deployed to CloudHub</th></tr></thead><tbody><tr><td><div><div><p>You can configure the maximum number of outstanding messages using the queue-profile element.</p></div></div></td><td><div><div><p>There is no limit to the number of outstanding messages in CloudHub. Even if you have a queue-profile element coded in your application with a maximum number of outstanding messages, CloudHub allows unlimited outstanding messages if you deploy the application to CloudHub with the <strong>Persistent Queues</strong> checkbox checked.</p></div></div></td></tr><tr><td><div><div><p>You can toggle the persistence of the queue using the queue-profile element.</p></div></div></td><td><div><div><p>The persistence of your queue is managed using the <strong>Persistent Queues</strong> checkbox in the <strong>Advanced Details</strong> section of the deployment dialog. Even if you have a queue-profile element coded in your application, CloudHub overrides these settings when you deploy the application to CloudHub with the <strong>Persistent Queues</strong> checkbox checked.</p></div></div></td></tr><tr><td><div><div><p>You can define a queue store for your VM queue to use.</p></div></div></td><td><div><div><p>CloudHub manages the queue store for you, so there is no need to define a queue store.</p></div></div></td></tr><tr><td><div><div><p>Transaction commits and rollbacks for XA transactions operate according to the two-phase commit algorithm.</p></div></div></td><td><div><div><p>In CloudHub, there is an important exception to the way the two-phase commit algorithm works for XA transactions when a message is being added to a queue. See the known issue described below for details. Note: when CloudHub consumes messages from a persistent queue, this exception to the two-phase commit algorithm does not apply.</p></div></div></td></tr></tbody></table>

## Considerations

When messages are added to a VM queue in CloudHub, the two-phase commit protocol for XA transactions
can fail to roll back a complete transaction if the following conditions are true:

- The commit-request phase has completed successfully. All participating processes within the
  transaction execute successfully, so the message is ready to commit to the queue.

- During the commit phase, an error occurs that causes a subprocess within the transaction to fail
  to commit, triggering a rollback of the transaction.

- The VM outbound endpoint completes its commit before the rollback occurs.

If all three above conditions are true, the message is added to the queue instead of being rolled
back as intended by the transaction rollback process. No message loss occurs, and the transaction
can still repeat, but the outbound VM queue contains an unintended message.

> [!NOTE] This issue occurs only when a flow produces messages that need to be added to a VM queue.
> There is no effect on the process of consuming messages from queues.

## See Also

- [CloudHub Workers](https://docs.mulesoft.com/cloudhub/cloudhub-architecture#cloudhub-workers)

- [Manage Queues](https://docs.mulesoft.com/cloudhub/managing-queues)

- [CloudHub architecture](https://docs.mulesoft.com/cloudhub/cloudhub-architecture)

- [Transaction Management](https://docs.mulesoft.com/mule-runtime/latest/transaction-management)

- [VM Connector](https://docs.mulesoft.com/vm-connector/latest/)

- [Reliability Patterns](https://docs.mulesoft.com/mule-runtime/latest/reliability-patterns)

<!-- document id=cf4e420846739601f73dd4711571265fad612e855c57e21085652effbd1aeb1c url=/mulesoft/current/en-us/cloudhub/dedicated-load-balancer-tutorial.md -->

---
product: CloudHub
---

# CloudHub Load Balancers

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

CloudHub provides two types of load balancers:

- Shared Load Balancer

  Provides basic load balancing functionality.

- Dedicated Load Balancer

  Enables you to deploy and configure one or more custom load balancers within an Anypoint Virtual
  Private Cloud (Anypoint VPC).

## Shared Load Balancers

CloudHub provides a default shared load balancer that is available in all environments. The shared
load balancer provides basic functionality, such as TCP load balancing.

Shared load balancers don’t allow you to configure custom SSL certificates or proxy rules. The
shared load balancer has its own SSL certificate. If you use the shared load balancer to access your
application, the system uses this certificate. If you access your application directly, the system
uses the SSL certificate configured in the application.

Additionally, shared load balancers have lower rate limits that help ensure platform stability.
MuleSoft regularly monitors and scales these limits as necessary. Rate limits on shared load
balancers are applied according to region. If you’re deploying an application to workers in multiple
regions, the rate limit for each region can be different.

If an application exceeds the rate limit for a shared load balancer, the load balancer returns a 429
Service Unavailable response.

To perform custom load balancer configuration or have higher rate limit thresholds, you must use a
dedicated load balancer.

The shared load balancer supports only TLS 1.2. It doesn’t support TLS 1.3.

> [!IMPORTANT] If your application uses only TLS 1.3, for example
> `jdk.tls.client.protocols=TLSv1.3`, connectivity to internal MuleSoft subsystems that use TLS 1.2
> fails. Handshake exceptions or connection failures can occur.
>
> Keep TLS 1.2 enabled in your application configuration. For compatibility with the shared load
> balancer and platform services, set `jdk.tls.client.protocols=TLSv1.2,TLSv1.3`.

## Dedicated Load Balancers

Dedicated load balancers enable you to:

- Handle load balancing among the different CloudHub workers that run your application.

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

- Configure proxy rules that map your applications to custom domains.

  This enables you to host your applications under a single domain.

- Enable HTTP Streaming via the API in CloudHub.

  > [!NOTE] The uploaded file size can’t be over 1000MB.

Dedicated load balancers are an optional component of Anypoint Platform.

For information about dedicated load balancers, see
[Dedicated Load Balancers](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer).

> [!NOTE] CloudHub load balancers use Nginx HTTP server capabilities. Nginx reverse proxies ignore
> HTTP header fields with invalid names. Valid HTTP header names are composed of English letters,
> numbers, hyphens, and underscores. Only valid headers are forwarded to the Mule application. Use
> only valid header names to avoid any issues. This applies to both shared and dedicated load
> balancers.

## See Also

- [CloudHub](https://docs.mulesoft.com/cloudhub/)

- [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [Dedicated Load Balancer Architecture](https://docs.mulesoft.com/cloudhub/lb-architecture)

- [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)

- [How to Enable DLB Streaming Feature via the API in CloudHub](https://help.salesforce.com/s/articleView?id=001116458&type=1)

<!-- document id=6083e93d3129c8a791c13dc77bb5004c4858675f14ac2024fdb2103fd6d9437c url=/mulesoft/current/en-us/cloudhub/cloudhub-networking-guide.md -->

---
product: CloudHub
---

# CloudHub Networking Guide

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This guide is for cloud deployments using the cloud-based version of Runtime Manager. See
[Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies) for information about different
deployment scenarios.

## Overview

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

![CloudHub Network Overview](/mulesoft/current/en-us/cloudhub/_images/ch-networking-guide.png)

Figure 1. The image shows the CloudHub components: Load Balancer, Virtual Private Cloud, and the DNS
records of the Mule workers.

See the sections below for information about load balancing and DNS records. For information about
VPC, see [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud).

## Load Balancing

CloudHub provides a load balancing service for all integrations. You can use the default load
balancing service or obtain a [dedicated load balancer](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer). For TLS
version requirements and JVM TLS configuration when using the shared load balancer, see
[Shared Load Balancers](https://docs.mulesoft.com/cloudhub/dedicated-load-balancer-tutorial#shared-load-balancers).

The CloudHub load balancing service does round robin load distribution across workers, which allows
workers to scale linearly as they receive more requests. The load balancing service also provides
transparent switchover when an application is upgraded. See
[Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub).

Each application deployed on CloudHub has a `CNAME` record that refers to the load balancer, for
example `myapp.region.cloudhub.io`. Mule apps deployed in CloudHub must listen on host `0.0.0.0` and
to either the HTTP port (`8081`) or to the HTTPS port (`8082`).

The following ports are assigned on the Mule worker:

- `http.port` is set to `8081`

- `https.port` is set to `8082`

The load balancer then forwards requests to the assigned ports on the Mule worker. Forwarded traffic
still uses HTTP and HTTPS protocols, which means it can’t listen for HTTPS on `${http.port}` or
plain HTTP on `${https.port}`.  
You must reference these ports using the reserved properties `${http.port}` and `${https.port}`
respectively. CloudHub services can then dynamically allocate a port at deployment time.

Here is an example of a Mule configuration that exposes an HTTPS endpoint:

```xml
<http:listener-config name="HTTP_Listener_Configuration" protocol="HTTPS" host="0.0.0.0" 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" />
		</tls:context>
</http:listener-config>
```

> [!IMPORTANT] On the Mule worker, the CloudHub load balancer automatically proxies the `http.port`
> `:80` to port `:8081` for HTTP and the `https.port` `:443` to `:8082` for HTTPS.  
> If other values for `http.port` and `https.port` are specified in the `mule-app.properties` file,
> these are overwritten at deployment time.

> [!NOTE] For each request a client makes through CloudHub’s load balancer
> (`myapp.region.cloudhub.io`), the load balancer maintains two connections. One connection ​is
> from​ the client and one is 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
> is sent or received during this time period, the load balancer closes ​both connections.
>
> For connections that take longer than 300 seconds to process from either side, consider handling
> the processing asynchronously.

## DNS Records

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

<table><colgroup><col> <col></colgroup><tbody><tr><td><div><div><p><strong>myapp.region.cloudhub.io</strong></p></div></div></td><td><div><div><p>Load balancer. Ports 80 and 443 forward to <code>${http.port}</code> and <code>${https.port}</code> respectively.</p></div></div></td></tr><tr><td><div><div><p><strong>mule-worker-myapp.region.cloudhub.io</strong></p></div></div></td><td><div><div><p>The external IP address of the Mule workers. Public HTTP services are exposed on: <code>${http.port}</code> and <code>${https.port}</code></p></div></div></td></tr><tr><td><div><div><p><strong>mule-worker-internal-myapp.region.cloudhub.io</strong></p></div></div></td><td><div><div><p>The internal IP address of the Mule workers. The IP addresses for this DNS record are accessible only within a customer’s private <a href="https://docs.mulesoft.com/cloudhub/virtual-private-cloud">Anypoint VPC</a>. <strong>These IP addresses are not accessible for workers running in the MuleSoft shared VPC.</strong> Internal HTTP services are exposed on: <code>${http.private.port}</code> and <code>${https.private.port}</code>. The default assigned ports are 8091 and 8092 respectively, and cannot be changed.</p></div></div></td></tr></tbody></table>

In certain situations, you may want to know an application’s internal IP addresses, for example:

- When communicating with the worker directly within the customer’s
  [Anypoint VPC](https://docs.mulesoft.com/cloudhub/virtual-private-cloud) without sending data over the public internet

- When setting up your own load balancer

You can access these IP addresses through the `mule-worker-internal-myapp.region.cloudhub.io` record
from within the Anypoint VPC. If you access the workers directly, any load distribution benefits
from the CloudHub load balancing layer are lost.

## IP Ranges and Static IPs

CloudHub IP addresses are chosen from the Salesforce EC2 IP pool or the Amazon EC2 IP pool,
depending on availability. For a list of AWS ranges, see
[Amazon AWS IP Address Ranges API](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html).
The download link on that page retrieves a dynamically generated JSON representation of all ranges
that include the region.

This table summarizes the Salesforce IP pool ranges available for your application in each region:

<table><colgroup><col> <col></colgroup><thead><tr><th>AWS Region</th><th>CIDR</th></tr></thead><tbody><tr><td><div><div><p>ca-central-1</p></div></div></td><td><div><div><p><code>149.60.32.0/21</code>, <code>149.60.40.0/21</code>, <code>149.60.48.0/21</code>, <code>149.60.56.0/21</code></p></div></div></td></tr><tr><td><div><div><p>us-west-1</p></div></div></td><td><div><div><p><code>149.60.64.0/20</code>, <code>149.60.80.0/20</code>, <code>149.60.96.0/20</code>, <code>31.67.56.0/23</code></p></div></div></td></tr><tr><td><div><div><p>us-west-2</p></div></div></td><td><div><div><p><code>149.60.128.0/18</code>, <code>149.60.192.0/19</code>, <code>149.60.112.0/20</code>, <code>149.60.4.0/22</code>, <code>149.60.1.0/24</code>, <code>31.67.52.0/23</code>, <code>31.67.54.0/24</code></p></div></div></td></tr><tr><td><div><div><p>us-east-2</p></div></div></td><td><div><div><p><code>157.232.0.0/18</code>, <code>157.232.64.0/18</code>, <code>149.60.224.0/19</code>, <code>149.60.12.0/22</code>, <code>149.60.8.0/23</code>, <code>149.60.11.0/24</code>, <code>31.67.48.0/22</code>, <code>31.67.47.0/24</code></p></div></div></td></tr><tr><td><div><div><p>us-east-1</p></div></div></td><td><div><div><p><code>157.232.128.0/18</code>, <code>157.232.192.0/18</code>, <code>170.139.0.0/18</code>, <code>170.139.64.0/18</code>, <code>170.139.128.0/18</code>, <code>170.139.192.0/19</code>, <code>170.139.224.0/20</code>, <code>149.60.24.0/21</code>, <code>31.67.0.0/19</code>, <code>31.67.32.0/21</code>, <code>31.67.40.0/22</code>, <code>31.67.44.0/23</code>, <code>31.67.46.0/24</code></p></div></div></td></tr><tr><td><div><div><p>ap-northeast-1</p></div></div></td><td><div><div><p><code>31.69.224.0/20</code>, <code>31.69.240.0/21</code>, <code>31.69.27.0/24</code>, <code>31.69.30.0/23</code></p></div></div></td></tr><tr><td><div><div><p>ap-southeast-1</p></div></div></td><td><div><div><p><code>31.69.0.0/20</code>, <code>31.69.16.0/21</code>, <code>31.69.24.0/23</code>, <code>31.69.26.0/24</code>, <code>31.69.248.0/23</code></p></div></div></td></tr><tr><td><div><div><p>ap-southeast-2</p></div></div></td><td><div><div><p><code>31.69.64.0/18</code>, <code>31.69.32.0/19</code>, <code>31.69.28.0/23</code>, <code>31.69.250.0/23</code>, <code>31.69.252.0/24</code></p></div></div></td></tr><tr><td><div><div><p>eu-central-1</p></div></div></td><td><div><div><p><code>31.68.192.0/18</code>, <code>31.69.128.0/18</code>, <code>31.68.86.0/23</code></p></div></div></td></tr><tr><td><div><div><p>eu-central-1 (EU Control Plane)</p></div></div></td><td><div><div><p><code>31.68.96.0/19</code>, <code>31.69.192.0/19</code>, <code>31.68.88.0/21</code>, <code>31.68.85.0/24</code>, <code>31.68.18.0/24</code>, <code>31.68.17.0/24</code>, <code>31.67.55.0/24</code>, <code>31.67.58.0/23</code>, <code>31.67.128.0/21</code>, <code>31.67.80.0/20</code>, <code>31.67.96.0/19</code></p></div></div></td></tr><tr><td><div><div><p>eu-west-1</p></div></div></td><td><div><div><p><code>31.68.128.0/18</code>, <code>31.68.24.0/21</code>, <code>31.68.80.0/22</code>, <code>31.68.84.0/24</code></p></div></div></td></tr><tr><td><div><div><p>eu-west-1 (EU Control Plane)</p></div></div></td><td><div><div><p><code>31.68.0.0/20</code>, <code>31.68.16.0/24</code></p></div></div></td></tr><tr><td><div><div><p>eu-west-2</p></div></div></td><td><div><div><p><code>31.68.32.0/19</code>, <code>31.68.64.0/20</code>, <code>31.68.20.0/22</code>, <code>31.68.19.0/24</code></p></div></div></td></tr><tr><td><div><div><p>sa-east-1</p></div></div></td><td><div><div><p><code>31.67.64.0/20</code>, <code>31.67.60.0/22</code></p></div></div></td></tr><tr><td><div><div><p>us-gov-west-1</p></div></div></td><td><div><div><p><code>31.66.160.0/19</code>, <code>31.66.144.0/20</code></p></div></div></td></tr></tbody></table>

> [!NOTE] This information is subject to change. Check back regularly for new regions, IP ranges,
> and a download link for Salesforce IP ranges.

For business or compliance requirements involving IP allowlisting, use static IPs in CloudHub.
Otherwise, refer to this page for the latest IP ranges and ensure your security team updates
allowlists in advance of any infrastructure changes.

CloudHub supports allocating a static IP for applications so that they can be allowlisted 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 [Salesforce Help](https://help.salesforce.com).

After a static IP has been allocated for your application, the IP address is visible in the **Static
IPs** tab in the application settings. For more information about static IPs, see
[Static IPs Tab Settings](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub#static-ips-tab-settings).

> [!NOTE] Static IP addresses are not supported for private IP addresses inside an Anypoint VPC.

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

If you need to allow the IP addresses for the communication between the
[Runtime Manager Agent](https://docs.mulesoft.com/runtime-manager/runtime-manager-agent) and the Runtime Manager console,
see [Ports, IP Addresses, and Hostnames to Allow](https://docs.mulesoft.com/runtime-manager/rtm-agent-allowlists).

> [!NOTE] 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 records are available for your
application in each region:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Region Name</th><th>Region</th><th>Example DNS Record</th></tr></thead><tbody><tr><th colspan="3"><p>US Control Plane Regions</p></th></tr><tr><td><div><div><p>US East (N. Virginia)</p></div></div></td><td><div><div><p>us-e1</p></div></div></td><td><div><div><p><code>myapp.us-e1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>US East (Ohio)</p></div></div></td><td><div><div><p>us-e2</p></div></div></td><td><div><div><p><code>myapp.us-e2.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>US West (N. California)</p></div></div></td><td><div><div><p>us-w1</p></div></div></td><td><div><div><p><code>myapp.us-w1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>US West (Oregon)</p></div></div></td><td><div><div><p>us-w2</p></div></div></td><td><div><div><p><code>myapp.us-w2.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>Canada (Central)</p></div></div></td><td><div><div><p>ca-c1</p></div></div></td><td><div><div><p><code>myapp.ca-c1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>South America (Sao Paulo)</p></div></div></td><td><div><div><p>br-s1</p></div></div></td><td><div><div><p><code>myapp.br-s1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>Asia Pacific (Singapore)</p></div></div></td><td><div><div><p>sg-s1</p></div></div></td><td><div><div><p><code>myapp.sg-s1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>Asia Pacific (Sydney)</p></div></div></td><td><div><div><p>au-s1</p></div></div></td><td><div><div><p><code>myapp.au-s1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>Asia Pacific (Tokyo)</p></div></div></td><td><div><div><p>jp-e1</p></div></div></td><td><div><div><p><code>myapp.jp-e1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>EU (Ireland)</p></div></div></td><td><div><div><p>ir-e1</p></div></div></td><td><div><div><p><code>myapp.ir-e1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>EU (Frankfurt)</p></div></div></td><td><div><div><p>de-c1</p></div></div></td><td><div><div><p><code>myapp.de-c1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>UK (London)</p></div></div></td><td><div><div><p>uk-e1</p></div></div></td><td><div><div><p><code>myapp.uk-e1.cloudhub.io</code></p></div></div></td></tr><tr><th colspan="3"><p>MuleSoft Government Cloud</p></th></tr><tr><td><div><div><p>US Gov West</p></div></div></td><td><div><div><p>usg-w1.gov</p></div></div></td><td><div><div><p><code>myapp.usg-w1.gov.cloudhub.io</code></p></div></div></td></tr><tr><th colspan="3"><p>EU Control Plane Regions</p></th></tr><tr><td><div><div><p>EU (Ireland)</p></div></div></td><td><div><div><p>ir-e1.eu1</p></div></div></td><td><div><div><p><code>myapp.ir-e1.eu1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p>EU (Frankfurt)</p></div></div></td><td><div><div><p>de-c1.eu1</p></div></div></td><td><div><div><p><code>myapp.de-c1.eu1.cloudhub.io</code></p></div></div></td></tr></tbody></table>

Note that DNS records are unique to each control plane. Though the EU control plane supports some of
the same regions that the U.S. control plane supports, the DNS records are different.

Deploying to a region also affects your internal and external worker DNS address. For example, if
you are using the US control plane and deploy to the Ireland region, the DNS records for internal
and external IP addresses are `mule-worker-myapp.ir-e1.cloudhub.io` and
`mule-worker-internal-myapp.ir-e1.cloudhub.io`.

## 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 want to access other ports, you can do so through the
[Anypoint Virtual Private Cloud (Anypoint VPC)](https://docs.mulesoft.com/cloudhub/virtual-private-cloud) offering.

Additional ports can be opened inside the Anypoint VPC, for example, for JMX based monitoring. Refer
to the Firewall Rules section in [Anypoint VPC documentation](https://docs.mulesoft.com/cloudhub/virtual-private-cloud#firewall-rules).

## Dedicated Load Balancing Configurations

In some cases, 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.

You can set your own [dedicated load balancer](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer) after configuring
your own [Anypoint VPC](https://docs.mulesoft.com/cloudhub/virtual-private-cloud).

## Avoid Public Discoverability for Applications on CloudHub

If you have [Anypoint VPC](https://docs.mulesoft.com/cloudhub/virtual-private-cloud) and a
[CloudHub dedicated load balancer](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer), you can prevent your
applications hosted in CloudHub from being publicly accessible:

1.  Remove the [Anypoint VPC firewall rule](https://docs.mulesoft.com/cloudhub/virtual-private-cloud#firewall-rules) for ports 8081 and
    8082 using:

    1.  The **Firewall Rules** tab in your Anypoint VPC management center. Remove both rules with
        **source** `Anywhere (0.0.0.0/0)` and ports 8081 and 8082.

    2.  The Anypoint Platform CLI. Run the
        [`cloudhub vpc firewall-rules remove`](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-vpc-firewall-rules-remove)
        command with the index `1` and `3`.

2.  Create an [allowlist](https://docs.mulesoft.com/cloudhub/lb-allowlists) in your dedicated load balancer with the IP addresses you
    want to authorize.

> [!IMPORTANT] If you don’t have a
> [CloudHub dedicated load balancer](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer), performing the first step is
> sufficient to ensure that applications deployed in your Anypoint VPCs are not publicly accessible.

## See Also

- [Providing an External HTTP/HTTPS Port when deploying to CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub#providing-an-external-http-https-port)

- [CloudHub architecture](https://docs.mulesoft.com/cloudhub/cloudhub-architecture)

- [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

<!-- document id=6c2bac5a49d2393ed99af4a8b14397bbdfbf87a5e12dddf8db9a6a07452ca710 url=/mulesoft/current/en-us/cloudhub/notifications-on-runtime-manager.md -->

---
product: CloudHub
---

# CloudHub Notifications on Runtime Manager

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

## Overview

**Notifications** are standard messages that appear in the Runtime Manager console to provide status
information about your applications. You can access them via the bell icon on the top-right corner
of the console. When you have new notifications, the bell turns red.

> [!TIP] You can also set up email [alerts](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager) that can
> be sent to any email address to warn whenever a certain event has occurred. Notifications are
> currently only produced by applications deployed to CloudHub, for applications deployed
> on-premises, you should use Alerts.

## Manage Notifications

Each notification has a priority level and a message associated with it. If the notification is
associated with a specific application, the application name is also provided.

![AlertMessage](/mulesoft/current/en-us/cloudhub/_images/alertmessage.png)

Click **Show All Notifications** to view all notifications including those that have already been
read.

## Standard Notifications

For applications deployed to CloudHub, certain events that may occur to one of your applications
automatically produces a notification:

<table><colgroup><col> <col></colgroup><thead><tr><th>Event</th><th>Message</th></tr></thead><tbody><tr><td><div><div><p>Worker will restart</p></div></div></td><td><div><div><p>A worker <code>&lt;ip&gt;</code> has become unresponsive. Restarting the worker.</p></div></div></td></tr><tr><td><div><div><p>Worker has restarted</p></div></div></td><td><div><div><p>Restart SUCCEEDED for worker <code>&lt;ip&gt;</code>.</p></div></div></td></tr><tr><td><div><div><p>Worker restart failed</p></div></div></td><td><div><div><p>Restart FAILED for worker <code>&lt;ip&gt;</code>.</p></div></div></td></tr><tr><td><div><div><p>Maximum Restarts attempted for a worker</p></div></div></td><td><div><div><p>We’ve reached the maximum amount of restart attempts.</p></div></div></td></tr><tr><td><div><div><p>Worker needs restarting, but restarts are disabled</p></div></div></td><td><div><div><p>A worker <code>&lt;ip&gt;</code> has become unresponsive. Restarts are disabled.</p></div></div></td></tr></tbody></table>

## Custom Notifications

On applications that are deployed to CloudHub, you can create custom notifications using the
CloudHub connector that must exist in your application.

1.  Download the CloudHub connector from [Anypoint Exchange](https://docs.mulesoft.com/exchange/).

    ![cloudhub connector](/mulesoft/current/en-us/cloudhub/_images/cloudhub-connector.png)

2.  Place an instance of the CloudHub connector in one of your project’s flows, to be triggered when
    something meaningful happens.

3.  Configure the connector. In the **Operation** field select **Create Notification** and then set
    the **Domain**, **Message** and **Priority** for it.

    You should now be receiving notifications.

4.  Optionally, set up email alerts to inform you when one of these custom events occurs. To set up
    email alerts, see [Alerts on Runtime Manager](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager). You
    must create an alert of type **Custom Notification Alert** that matches your custom
    notification.

See the tutorial.

## Notification Retention

Notifications are retained by Anypoint Platform within the bounds of the following limits, whatever
happens first:

- for 30 days

- up to 1000 notifications per application

## See Also

- [Custom Application Alerts](https://docs.mulesoft.com/cloudhub/custom-application-alerts) tutorial.

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [CloudHub Overview](https://docs.mulesoft.com/cloudhub/)

- [Develop Applications for CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

- [Clustering](https://docs.mulesoft.com/cloudhub/cloudhub-fabric)

- [Monitor Applications](https://docs.mulesoft.com/runtime-manager/monitoring)

- [Manage Queues](https://docs.mulesoft.com/cloudhub/managing-queues)

- [Manage Schedules](https://docs.mulesoft.com/cloudhub/managing-schedules)

- [Manage Application Data with Object Stores](https://docs.mulesoft.com/cloudhub/managing-application-data-with-object-stores)

- [Anypoint Platform Command-Line Interface](https://docs.mulesoft.com/anypoint-cli/latest/)

- [Secure Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties)

- [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [Penetration Testing Policies](https://docs.mulesoft.com/cloudhub/penetration-testing-policies)

<!-- document id=a9a4b44353c78b92f3caa0939a9919ec413d54dae9afd6043d8ee70bdb44b889 url=/mulesoft/current/en-us/cloudhub/index.md -->

---
product: CloudHub
---

# CloudHub Overview

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

[CloudHub](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration) is an
integration platform as a service (iPaaS) where you can deploy sophisticated cross-cloud integration
applications in the cloud, create new APIs on top of existing data sources, integrate on-premises
applications with cloud services, and much more.

## Create an Application for CloudHub

![app](/mulesoft/current/en-us/cloudhub/_images/logo-app.png)

- See [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub).

- See [Build an HTTPS Service](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service) to include HTTPS
  support in this application.

> [!TIP] For examples of more applications, see [Anypoint Exchange](https://docs.mulesoft.com/exchange/).

You can deploy the same Mule applications to CloudHub or to an
[on-premises server](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers). There are some differences
in how features work between the environments, which you need to consider when you plan your
deployment strategy. See [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies).

## Deploy your Application to CloudHub

![deploy](/mulesoft/current/en-us/cloudhub/_images/logo-deploy.png)

Learn how you can deploy your applications to CloudHub:

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [Anypoint Platform Command-Line Interface (CLI)](https://docs.mulesoft.com/anypoint-cli/latest/)

### Easy Scalability

CloudHub is an elastic cloud, meaning it scales on demand. You can start small and scale up as your
needs grow, without changing your applications or experiencing downtime. CloudHub provides a
scalable architecture – one on which you can build integration applications, publish REST APIs, or
Web services, and much more.

### Integration with Anypoint Studio

Using [Anypoint Studio (Studio)](https://docs.mulesoft.com/studio/), you can build integration applications and deploy them
to CloudHub with just a few clicks. You can then access them like any other application deployed
through the platform, by [signing in to](https://anypoint.mulesoft.com/home/) Anypoint Platform and
then navigating to Runtime Manager. See
[Deploy an Application from Studio](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub#from-anypoint-platform).

### Integrate Cloud and Enterprise Applications

The CloudHub [Anypoint Virtual Private Cloud (Anypoint VPC)](https://docs.mulesoft.com/cloudhub/virtual-private-cloud) enables you to
construct a secure pipe to on-premises applications through an IPsec VPN tunnel, Anypoint VPC
peering, a transit gateway, or AWS Direct Connect.

### CloudHub API

To automate tasks or automatically deploy to CloudHub, use the
[CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api).
This enables you to perform tasks such as manage and monitor your applications, and scale your
applications.

## Manage your Application

![manage](/mulesoft/current/en-us/cloudhub/_images/logo-manage.png)

Learn how you can manage an application that is currently running in CloudHub:

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications) has information
  about settings that are general to all applications—both those deployed to CloudHub and to
  on-premises servers.

- [Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub) has information about
  settings that are specific to applications on CloudHub.

### Manage Applications in Runtime Manager

Maintain your applications on CloudHub through the [Runtime Manager](https://docs.mulesoft.com/runtime-manager/), an
intuitive cloud console where you can [manage](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)
and [monitor](https://docs.mulesoft.com/runtime-manager/monitoring) every aspect of your applications in a centralized
location.

> [!NOTE] You can view the live status and detailed service history for the Runtime Manager console,
> platform services, and the CloudHub worker cloud on
> [`status.mulesoft.com`](https://status.salesforce.com/products/Mulesoft) for the US platform. For
> the EU platform, visit
> [`eu1-status.mulesoft.com`](https://status.salesforce.com/products/Mulesoft).

## Monitor your Applications

![monitor](/mulesoft/current/en-us/cloudhub/_images/logo-monitor.png)

Through various tools, Runtime Manager enables you to triage problems, view logs, set up alerts,
view dashboards, and more. See [Monitor Applications](https://docs.mulesoft.com/runtime-manager/monitoring) for an overview
on the different ways that Runtime Manager enables you to monitor your running applications.

> [!NOTE] Heap dumps cannot be shared. Instead, our **Support Center** representatives can analyze
> the dumps and share the required information with you.

## Limitations

When deploying to CloudHub, keep in mind the following limitation:

- CloudHub blocks outbound SMTP traffic when more than 20 emails are sent in one hour.

## See Also

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

- [Develop Applications for CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub)

- [CloudHub FAQ](https://docs.mulesoft.com/cloudhub/cloudhub-faq)

- [CloudHub Architecture](https://docs.mulesoft.com/cloudhub/cloudhub-architecture)

- [High Availability](https://docs.mulesoft.com/cloudhub/cloudhub-fabric)

- [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide)

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)

- [Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)

- [Penetration Testing Policies](https://docs.mulesoft.com/cloudhub/penetration-testing-policies)

- [Cloud Security and Compliance Whitepaper](https://www.mulesoft.com/api/security)

- [CloudHub Overview](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration)

<!-- document id=9828d8d1241f1d8e3d5f5ccef1dcb05b84f2bb3f90b3d577655ffee827eedb20 url=/mulesoft/current/en-us/cloudhub/cloudhub-release-notes.md -->

---
product: CloudHub
---

# CloudHub Release Notes

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

- [CloudHub Release Notes](https://docs.mulesoft.com/release-notes/cloudhub/cloudhub-release-notes)

- [CloudHub Runtime and OS Release Notes](https://docs.mulesoft.com/release-notes/cloudhub/cloudhub-runtimes-release-notes)

- [CloudHub Dedicated Load Balancer Release Notes](https://docs.mulesoft.com/release-notes/cloudhub/cloudhub-dedicated-load-balancer-release-notes)

- [Anypoint VPN Updates Release Notes](https://docs.mulesoft.com/release-notes/cloudhub/anypoint-vpn-release-notes)

<!-- document id=ac57783ba113624b3bc2ed085b6f0a4427a979e45ae320816984ec2c651b466b url=/mulesoft/current/en-us/cloudhub/cloudhub-app-runtime-version-updates.md -->

---
product: CloudHub
---

# CloudHub Runtime Continuous Updates

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Because CloudHub is an integration platform as a service (iPaaS), it manages operating system and
Mule runtime engine patching, enabling you to focus on developing and updating your applications.

CloudHub applies security patches as needed to ensure that your application is secure and, once per
month, it updates Mule to maintain the stability of your application.

Patch updates use blue-green deployment, which ensures zero downtime.

CloudHub applies continuous updates to all three MuleSoft-managed deployment platforms:

- US cloud

- EU cloud

- MuleSoft Government Cloud

## Security Updates

MuleSoft regularly runs scans to identify security vulnerabilities in Mule runtime engine, JVM, and
the underlying operating system, and then automatically applies security patches based on the
following SLA:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Severity Level</th><th>Severity Definition</th><th>Patch Applied Within</th></tr></thead><tbody><tr><td><p>P0</p></td><td><p>Critical</p></td><td><p>7 days</p></td></tr><tr><td><p>P1</p></td><td><p>High</p></td><td><p>30 days</p></td></tr></tbody></table>

## Monthly Date-Patch Updates

Once per month, MuleSoft releases a _date-patch update_, which includes backward-compatible bug
fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might
include security patches if the scheduled date is within the security SLA.

The format of the version number for these updates is:

_Major_._Minor_._Patch_ - _Date_

Here’s an example version number, including the patch date:

`4.2.2 - 05-04-2020`

The monthly patches update applications only to the latest date patch for the patch version. They do
not change the patch version number.

Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term Support
(LTS). The Mule runtime versioning schema for the new release channels is:

_Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge,
nothing for LTS\]_

Some examples of these values are: `4.5.0:1e` for Edge, and `4.6.0:1` for LTS.

### Update Schedule

The schedule for date-patch updates is:

- In the first full week of the month, MuleSoft releases the date patch.

- In the third full week of the month, MuleSoft automatically applies the date patch that was
  released in the first week of the month.

  Applications in environments other than production are updated during the week. Production
  applications are updated on the weekend.

  > [!NOTE] All releases occur in GMT-3 time. All automatic updates occur in the local time zone of
  > the app’s deployment region. For example, CloudHub applies updates to apps deployed in the
  > Asia-Pacific (Sydney) region in the AEST time zone and to apps deployed in the US West region in
  > the PST time zone.

  When an automatic update occurs, the audit log for your app contains an entry by user
  `Anypoint Staff`, which shows the date and time an update occurred and whether it was successful.

  If the update is successful, no action is required. See
  [Zero-Downtime Restart Limitations](#zero-downtime-restart-limitations).

If your application does not support zero-downtime updates or requires a manual update, you can
apply the date patch released in the first full week of the month in week 1 or week 2. See
[Update the Runtime Version Manually](#update-the-runtime-version-manually).

To update multiple applications, use the CloudHub API. See
[Update Multiple Apps to the Latest Runtime Release](#update-multiple-apps-to-the-latest-runtime-release).

## Live Patching

CloudHub uses kernel live patching in the underlying VMs to apply the latest security and critical
bug patches to the OS. You do not have to restart the CloudHub application between the monthly
patching cycles.

> [!IMPORTANT] CloudHub applications must be running 90-day-old or newer releases to be
> live-patched.
>
> The CloudHub live patching process checks the application to ensure that it has enough memory and
> CPU available to live patch. If there is not enough capacity, it skips the patching and retries at
> a later time.

### Determine if an Application Has Been Live-patched

You can check your [application logs](https://docs.mulesoft.com/cloudhub/viewing-log-data#view-logs) to determine if an application has
been live patched.

![Application live patching log](/mulesoft/current/en-us/cloudhub/_images/live-patching-log.png)

## Edge and LTS Releases for Mule

Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support
(LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric,
CloudHub, CloudHub 2.0, and Hybrid Standalone.

Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue
to follow the monthly patch update schedule.

Consider these factors to determine the approach that best suits your requirements ahead of the Mule
4.4 End of Standard Support.

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Channel Type</th><th>Release Cadence</th><th>Differentiators</th><th>Support Coverage</th></tr></thead><tbody><tr><td><div><div><p>Edge</p></div></div></td><td><div><div><p>Up to three times per year</p></div></div></td><td><div><div><ul><li><p>Includes new features on a frequent release cadence with shorter maintenance coverage.</p></li><li><p>Versions aren’t FedRAMP approved.</p></li></ul></div></div></td><td><div><div><p>For versions 4.9 and later:</p></div><div><ul><li><p>Standard Support until one month after the next Edge version is released</p></li><li><p>3 months of Extended Support</p></li></ul></div><div><p>For version 4.8:</p></div><div><ul><li><p>5 months of Standard Support</p></li><li><p>3 months of Extended Support</p></li></ul></div><div><p>For versions 4.5 to 4.7:</p></div><div><ul><li><p>4 months of Standard Support</p></li><li><p>4 months of Extended Support</p></li></ul></div></div></td></tr><tr><td><div><div><p>LTS</p></div></div></td><td><div><div><p>Periodic (Scheduled for February)</p></div></div></td><td><div><div><ul><li><p>Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.</p></li></ul></div></div></td><td><div><div><p>For version 4.6 and later:</p></div><div><ul><li><p>A minimum of 18 months of Standard Support</p></li><li><p>A minimum of 6 months of Extended Support</p></li></ul></div></div></td></tr></tbody></table>

If an LTS version is released in February, both Edge and LTS share the same underlying version,
including the same minor Mule runtime version and new features.

To review the new support policy that aligns with the new release periods and types of releases, see
[MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).

> [!NOTE] For information about the monthly patch update process, see
> [Update Patches to Mule](https://docs.mulesoft.com/release-notes/mule-runtime/patching-mule-versions).

## Edge Channel

Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge
channel if you want to stay on top of the latest features and feel comfortable with a more frequent
release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and
innovations available on the MuleSoft platform.

## LTS Channel

Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled
for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because
Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed
by the end of Extended Support in October 2025.

For CloudHub and CloudHub 2.0 customers, once Standard Support for Mule 4.4 ends, if you want to
deploy new apps, you must do so on Mule 4.6 LTS or Mule 4.8 Edge.

Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts
new capabilities after they have been introduced via Edge releases.

## Switch from an Edge Version to an LTS Version

You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge
to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to
implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then
merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from
Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might
result in losing some of the new features in the older LTS version.

## Mule Runtime Release Cadence Support

The following table shows the Mule runtime release cadence support for CloudHub:

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Mule Version</th><th>Release Date</th><th>Java Version</th><th>End of Standard Support</th><th>End of Extended Support</th></tr></thead><tbody><tr><td><p>4.13 Edge</p></td><td><p>October 2026</p></td><td><p>17</p></td><td><p>March 2027</p></td><td><p>June 2027</p></td></tr><tr><td><p>4.12 Edge</p></td><td><p>June 2026</p></td><td><p>17</p></td><td><p>November 2026</p></td><td><p>February 2027</p></td></tr><tr><td><p>4.11 Edge</p></td><td><p>February 2026</p></td><td><p>17</p></td><td><p>July 2026</p></td><td><p>October 2026</p></td></tr><tr><td><p>4.10 Edge</p></td><td><p>October 2025</p></td><td><p>17</p></td><td><p>March 2026</p></td><td><p>June 2026</p></td></tr><tr><td><p>4.9 LTS</p></td><td><p>February 2025</p></td><td><p>17</p></td><td><p>August 2027</p></td><td><p>February 2028</p></td></tr><tr><td><p>4.9 Edge</p></td><td><p>February 2025</p></td><td><p>17</p></td><td><p>November 2025</p></td><td><p>February 2026</p></td></tr><tr><td><p>4.8 Edge</p></td><td><p>October 2024</p></td><td><p>8, 11, and 17</p></td><td><p>March 2025</p></td><td><p>June 2025</p></td></tr><tr><td><p>4.7 Edge</p></td><td><p>June 2024</p></td><td><p>8, 11, and 17</p></td><td><p>October 2024</p></td><td><p>February 2025</p></td></tr><tr><td><p>4.6 LTS</p></td><td><p>February 2024</p></td><td><p>8, 11, and 17</p></td><td><p>August 2026</p></td><td><p>February 2027</p></td></tr><tr><td><p>4.6 Edge</p></td><td><p>February 2024</p></td><td><p>8, 11, and 17</p></td><td><p>June 2024</p></td><td><p>October 2024</p></td></tr><tr><td><p>4.5 Edge</p></td><td><p>October 2023</p></td><td><p>8 and 11</p></td><td><p>February 2024</p></td><td><p>June 2024</p></td></tr></tbody></table>

> [!NOTE] MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility
> with Java 8, 11, and 17.

> [!NOTE] If you are a CloudHub or a CloudHub 2.0 customer and you want to create or test Mule 4.6
> applications in Anypoint Studio, the Studio version required is the next upcoming release in
> March. Meanwhile, MuleSoft enables you to deploy new apps in Mule runtime 4.5e version via API,
> Mule Maven plugin, and Anypoint Platform CLI starting February 14 until April 19. Auto-upgrade
> from Mule 4.5 Edge to Mule 4.6 Edge for CloudHub and CloudHub 2.0 applications will be performed
> in April instead of February. See
> [Temporary changes to auto-upgrade and new app deployment for Mule 4.5 Edge](https://help.salesforce.com/s/articleView?id=001117251&type=1).

## Deployment Models and Application Lifecycle Management

Application lifecycle management depends on the deployment model.

<table><colgroup><col> <col></colgroup><thead><tr><th>Action</th><th>CloudHub</th></tr></thead><tbody><tr><td><p>Deploy net new apps</p></td><td><p>Deploy to the latest minor-patch version available under Standard Support of each channel.</p></td></tr><tr><td><p>Auto-upgrade</p></td><td><div><div><p>MuleSoft applies two distinct types of automatic updates:</p></div><div><ul><li><p>Auto-patching (within the same minor version): Every month, apps in both the Edge and LTS channels are automatically updated to the latest available patch of their current minor version, as long as the app’s TLS version is compatible with the new patch. For example, an app can be updated from Mule <code>4.9.19</code> to <code>4.9.20</code>. Monthly auto-patching doesn’t change the minor version. Patches are backward compatible and include bug fixes and security updates. Security updates can also be applied outside the regular schedule to address critical vulnerabilities. See the patching schedule for <a href="https://docs.mulesoft.com/release-notes/cloudhub/cloudhub-runtimes-release-notes">CloudHub</a> and <a href="https://docs.mulesoft.com/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes">CloudHub 2.0</a>.</p></li><li><p>Auto-upgrade (to a new minor version): When a minor version reaches End of Standard Support, apps are handled differently depending on the release channel:</p><div><ul><li><p>Edge: Apps are automatically upgraded to the latest minor version in the Edge channel. The auto-upgrade occurs six weeks after the version reaches End of Standard Support, during that month’s patching schedule. Before the auto-upgrade, you have a self-upgrade window to move to the new minor version yourself.</p></li><li><p>LTS: Apps aren’t automatically upgraded to a new minor version when the version reaches End of Standard Support. To move to a later LTS minor version, upgrade your application manually. Apps that remain on a version through End of Extended Support are subject to the forced-upgrade behavior described in End of Extended Support.</p></li></ul></div></li></ul></div><div><p>Runtime version compatibility: Apps running Mule runtime 4.9 or earlier aren’t auto-upgraded to Mule runtime 4.10 or later. Mule 4.10 removes support for TLS 1.0 and 1.1, which can cause compatibility issues and break existing applications if upgraded automatically. Apps running earlier versions, such as Mule 4.6, can be auto-upgraded only as far as the Mule 4.9 release line and are moved to the latest available Mule 4.9 patch. To use Mule runtime 4.10 or later, upgrade your application manually.</p></div></div></td></tr><tr><td><p>Self-upgrade</p></td><td><div><div><p>For apps in the Edge channel, you can manually upgrade during the fixed window after the runtime version reaches End of Standard Support. See patching schedule for <a href="https://docs.mulesoft.com/release-notes/cloudhub/cloudhub-runtimes-release-notes">CloudHub</a> and <a href="https://docs.mulesoft.com/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes">CloudHub 2.0</a>.</p></div><div><ul><li><p>Edge: Six weeks</p></li><li><p>LTS: Manual upgrade only (no automatic minor upgrade schedule)</p></li></ul></div></div></td></tr><tr><td><p>Rollback</p></td><td><p>Available to the previously used version</p></td></tr><tr><td><p>Restart apps</p></td><td><p>Always</p></td></tr><tr><td><p>Keep running applications</p></td><td><p>Until End of Extended Support</p></td></tr><tr><td><p>End of Extended Support</p></td><td><p>Shutdown running apps.<br>Starting with Mule 4.7, CloudHub and CloudHub 2.0 applications in the Edge or LTS channels that are still running <a href="https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf">End of Life versions</a> will undergo a forced upgrade to the latest version during the monthly upgrade window (See upgrade window for <a href="https://docs.mulesoft.com/release-notes/cloudhub/cloudhub-runtimes-release-notes">CloudHub</a> and <a href="https://docs.mulesoft.com/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes">CloudHub 2.0</a>).</p></td></tr><tr><td><p>Retirement</p></td><td><p>Mule apps don’t reach End of Life because they’re always auto-upgraded.</p></td></tr><tr><td><p>Supportability</p></td><td><p>All Mule apps are under Standard Support.</p></td></tr></tbody></table>

## Mule Runtime Version Naming Changes

The version naming convention depends on the deployment model you’re using. A version increments:

- MAJOR when a release includes features that introduce breaking changes and backward
  incompatibility.

- MINOR when a release includes all new features keeping backward compatibility with previous
  minors.

- PATCH when a release includes bug fixes and security updates that include upgrades to libraries
  with reported vulnerabilities. We build a new runtime and do a full validation test.

- BUILD when a release includes changes related to Image/AMI, including OS changes, OS security
  updates, and changes in products outside the runtime. It doesn’t include any runtime changes.

### CloudHub

The Mule runtime versioning schema for the new release channels is:

_Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge,
nothing for LTS\]_

Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_
version. To distinguish the versions, they’re represented as:

- Edge: 4.6.0:1e

- LTS: 4.6.0:1

CloudHub requires regular OS updates, hence the addition of the build enumeration in the full
runtime version schema.

Here are examples of the version numbers:

- Edge: 4.5.0:1e

- Edge: 4.6.0:1e

- LTS: 4.6.0:1

Mule runtime does not introduce a semVer increment if there is a month with no fixes.

Here is an example of the versioning schema using different patch and builds:

<table><colgroup><col> <col> <col> <col> <col> <col></colgroup><thead><tr><th></th><th></th><th></th><th></th><th>Hybrid Standalone</th><th>CloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image</th></tr></thead><tbody><tr><th><p>Case</p></th><th><p>Release Date</p></th><th><p>Description</p></th><th><p>Patch/Build</p></th><th><p>Mule Runtime</p></th><th><p>Runtime Manager/Maven/API Tag for New Deployment</p></th></tr><tr><td><p>1</p></td><td><p>Oct 3, 2023</p></td><td><p>First release of 4.5.0</p></td><td><p>0th patch and 1st build</p></td><td><p>4.5.0</p></td><td><p>4.5.0:1e</p></td></tr><tr><td><p>2</p></td><td><p>Nov 7, 2023</p></td><td><p>Second release of 4.5</p></td><td><p>1st patch and 1st build</p></td><td><p>4.5.1</p></td><td><p>4.5.1:1e</p></td></tr><tr><td><p>3</p></td><td><p>Nov 7, 2023</p></td><td><p>Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric</p></td><td><p>1st patch and 2nd build</p></td><td><p>Not Available</p></td><td><p>4.5.1:2e</p></td></tr><tr><td><p>4</p></td><td><p>Nov 7, 2023</p></td><td><p>OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric</p></td><td><p>1st patch and 3rd build</p></td><td><p>Not Available</p></td><td><p>4.5.1:3e</p></td></tr><tr><td><p>5</p></td><td><p>Dec 5, 2023</p></td><td><p>Second patch version of 4.5</p></td><td><p>2nd patch and 1st build</p></td><td><p>4.5.2</p></td><td><p>4.5.2:1e</p></td></tr><tr><td><p>6</p></td><td><p>Jan 2, 2024</p></td><td><p>Hot fix for a Mule runtime regression</p></td><td><p>3rd patch &amp; 1st build</p></td><td><p>4.5.3</p></td><td><p>4.5.3:1e</p></td></tr><tr><td><p>7</p></td><td><p>Feb 6, 2024</p></td><td><p>Release of new minor</p></td><td><p>0th patch and 1st build</p></td><td><p>4.6.0</p></td><td><p>4.6.0:1e (Edge) / 4.6.0:1 (LTS)</p></td></tr></tbody></table>

The Mule runtime versioning schema uses these conventions:

- Patch number in schema

  - In the schema `4.5.X:2e`, the patch number is the X.

  - The patch number starts from `0`, introducing a new minor version.

  - The patch number increments when the release introduces new code changes, including hotfixes to
    regressions or other bug fixes.

- Build number in schema

  - In the schema `4.5.1:Ye`, the build number is Y.

  - The build number starts from `1`, introducing the first AMI or Docker image build of the patch.

  - The build number increments whenever the release introduces a new build of the AMI or Docker
    image for the same Mule runtime version. This increment does not indicate code changes to Mule
    runtime.

## Update the Runtime Version Manually

The **Update Available** column indicates which apps require a runtime version update. You can
schedule the update to occur at your convenience.

Before updating apps in the production environment, update them in the sandbox environment and run
the required tests.

### Update a Single App to the Latest Runtime Release

To update an app to the latest date patch:

1.  In the Runtime Manager navigation menu, click **Applications**.

2.  Click the name of the application you want to update to display the details pane.

3.  Access the **Settings** page for the application.

4.  Click the **Runtime** tab.

    If the app requires an update, **Update available** appears in the **Runtime version** menu:

    ![Update available and the Runtime version menu on the application Settings page](/mulesoft/current/en-us/cloudhub/_images/cloudhub-app-update-available-setting.png)

5.  Select the latest version from the **Runtime version** drop-down menu.

6.  If you want to see details about the version, click the **Read release notes** link.

7.  Click the **Apply Changes** button to update the app.

CloudHub updates the app with the version you selected and displays a message indicating success or
failure.

If the app update is unsuccessful, the app remains in the **Update Available** tab. In this case,
the app continues to run correctly on the previous runtime version and no action is required.

If you select the Edge release channel, a banner appears indicating the date of the next automatic
update.

![Banner indicating the date of automatic update for Edge release channel.](/mulesoft/current/en-us/cloudhub/_images/cloudhub-app-edge-auto-update.png)

### Update Multiple Apps to the Latest Runtime Release

Although the Runtime Manager UI doesn’t support updating multiple apps to the latest runtime
version, you can use the CloudHub API to perform a bulk update. See
[How to Perform a Bulk CloudHub Application Update to the Latest Runtime Releases](https://help.salesforce.com/s/articleView?id=001116902&type=1).

> [!NOTE] Applications updated using the Bulk Update API are processed with a lower priority and may
> take slightly longer to update.

## Update Notification

When a new runtime version is available:

- The **Applications** page displays an **Update Available** column that indicates if there is an
  update available for the application:

  ![Applications page with banner and Update Available tab](/mulesoft/current/en-us/cloudhub/_images/cloudhub-app-update-req-page.png)

- **Update available** and the new available updates appear in the **Runtime version** tab of the
  **Settings** page for the application:

  ![Runtime update version and Update available in the Runtime version menu.](/mulesoft/current/en-us/cloudhub/_images/cloudhub-app-update-versions.png)

MuleSoft applies the updates automatically, based on the published schedules. If you want, you can
update them manually at your convenience.

## Zero-Downtime Restart Limitations

Zero-downtime restarts don’t work in the following cases:

- The CloudHub application is a durable subscriber.

  In this case, only one unique subscriber can be active at a time. For these applications, you must
  manually stop and start the application to apply the latest update.

- The CloudHub application connects to an external dependency that is unavailable, unresponsive, or
  requires warmup.

  In this case, CloudHub waits up to three minutes for the application to connect to any
  dependencies before assigning the application domain and related static IP addresses (if used) to
  the new version of the application.

If either case applies to your application, contact Support and your CSM account representative for
information about updating the application to be cloud-ready.

## Check Your Application Status After an Update

After a new update occurs, you can check your
[application status state](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#application_status_states)
in the **Status** column in Runtime Manager’s **Applications** tab.

You can also check your application logs to verify if your application was deployed correctly and
take any remediation actions in the event of some auto-minor update-related issue. For more
information, visit [View Logs](https://docs.mulesoft.com/cloudhub/viewing-log-data#view-logs).

To be notified by e-mail when an error occurs after an automated update, you can
[create an alert](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager#create-an-alert).

## Failed Automated Updates

With blue-green deployments, when an automated update fails to be deployed to a new worker, the
application continues to run the non-latest patch version on the currently running worker.

Possible failure reasons include but are not limited to:

- Removing one of the application properties from the Anypoint Runtime Manager UI after deployment.

- Incompatibility of a custom module with the latest patch version release.

> [!IMPORTANT] To avoid introducing security vulnerabilities, if your application doesn’t receive
> any patches for two consecutive months, the application is stopped and force-updated to the latest
> patch version. Applications that fail to start require your action to address patches.

## See Also

- [Edge and LTS Releases for Mule](https://docs.mulesoft.com/release-notes/mule-runtime/lts-edge-release-cadence).

- [CloudHub API Portal](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)

- [Zero-Downtime Updates](https://docs.mulesoft.com/cloudhub/cloudhub-architecture#zero-downtime-updates)

- [Regional Services](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide#regional-services)

<!-- document id=0f406b5f014ba2a03999b67de2b0ee02c5b5284ae9b2b4d18d3770125c6542be url=/mulesoft/current/en-us/cloudhub/app-migration.md -->

---
product: CloudHub
---

# CloudHub to CloudHub 2.0 Application Migration

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

After your Anypoint Virtual Private Cloud (VPC) upgrade is complete, you can migrate all associated
applications. Migration involves creating an equivalent CloudHub 2.0 application for every CloudHub
application, and linking them.

The current CloudHub application runs without disruption until the upgrade completes. Then, you can
use the same CloudHub URL for your CloudHub 2.0 application.

> [!NOTE] During the application upgrade process, MuleSoft doesn’t provide any out-of-the-box
> entitlements. Work with your account representative to remain compliant with entitlements and
> finish the upgrade on time.

## Eligibility

To link a CloudHub application with a CloudHub 2.0 application and gradually switch traffic using
the application migration tool, first upgrade the CloudHub VPC to a CloudHub 2.0 private space by
using the [VPC upgrade tool](https://docs.mulesoft.com/cloudhub/vpc-upgrade).

You can use the application upgrade tool only in CloudHub 2.0 private spaces that were upgraded from
a CloudHub VPC.

## Upgrade Your CloudHub Application to CloudHub 2.0 via Anypoint Platform

1.  From **Anypoint Platform**, select **Runtime Manager** > **Applications**.

2.  Select the CloudHub application to upgrade and go to **Settings**.

    If your application is eligible for the upgrade, the upgrade tooling is available on the
    **Settings** page.

3.  Click **Upgrade to CloudHub 2.0**, then click **Start Upgrade**.

    ![CloudHub to CloudHub 2.0 upgrade window summarizing the application migration process and containing the Start Upgrade button.](/mulesoft/current/en-us/cloudhub/_images/upgrade-application-window.png)

    The **Upgrade Application to CloudHub 2.0** page opens.

    - The **Application Name** field shows the inherited CloudHub application name by default.

      To use a different name for your CloudHub 2.0 application, change it by editing the field.

    - The **Upgrading From** field shows the name of the CloudHub application the new application is
      migrated from.

      You can’t edit this field. The **Deployment Target** field shows the preselected private space
      for the application deployment based on the upgraded CloudHub VPC.

      You can’t edit this field.

4.  For **Application File**, you can either:

    - Upload your application file: Download the application asset from the link under **Application
      File**, make the necessary changes, and upload it to deploy your new application to the
      CloudHub 2.0 private space.

    - Import file from Exchange: Import the CloudHub application you want to upgrade.

5.  In the **Ingress** tab, specify the **Endpoint** configuration:

    1.  Select a **Host** from the dropdown list.

        > [!NOTE] If you’re using the `anypoint.dns.net` endpoint without a TLS context, the
        > **Ingress** tab doesn’t show it as a possible endpoint.

    2.  Select a specific subdomain from the dropdown list.

    3.  Add a specific path.

    4.  Optionally, provide a specific path rewrite.

    5.  Select whether you want to provide internal or external access to your endpoint.

6.  Follow the steps to [deploy an application to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-deploy).

> [!WARNING] If you use a different name for the CloudHub 2.0 application, make sure you put the
> CloudHub application name in the **Ingress** tab settings in the subdomain field of the endpoint
> configuration. If you configure URLs incorrectly, traffic doesn’t reach the CloudHub 2.0
> application during [traffic switching](#next-steps-after-application-upgrade).
>
> In applications with inbound traffic, the Shared Load Balancer (SLB) handles traffic switching if
> your Ingress configuration includes the default CloudHub application endpoint in the format:
> `<app_name>.<region>.cloudhub.io`. However, if that default endpoint is missing, and you have
> configured a vanity domain or an `anypointdns.net endpoint` instead, the Dedicated Load Balancer
> (DLB) switches the traffic. For more information about SLB and DLB traffic switching, see
> [Understanding the Traffic Source](#understanding-the-traffic-source).

> [!NOTE] The **Host** dropdown list shows only the domains initially added under the certificates
> of the underlying VPC’s DLB configuration. If you add a new certificate to the original VPC’s DLB
> after the application upgrade starts, add it manually under the **Domain & TLS** tab of your newly
> created private space for that domain to appear on the **Host** dropdown list.

### Considerations and Limitations

The upgrade process doesn’t automatically map some configuration settings to the new CloudHub 2.0
application.

#### Application Properties

The upgrade process doesn’t carry over application properties to CloudHub 2.0. Reconfigure these
properties manually for a successful upgrade:

- The upgrade process copies your CloudHub app’s properties during the CloudHub 2.0 application
  configuration. These properties don’t persist unless you edit at least one property or add a new
  property. Editing a single property, or adding a new one, causes the edited or new property and
  all other copied properties to persist.

- The upgrade process copies the protected properties added during CloudHub 1.0 with `******` as
  their displayed value. Change this displayed value manually to the correct protected value within
  your CloudHub 2.0 application settings.

#### Managing Migrated Apps via Mule Maven Plugin (MMP)

To manage a migrated app using the Mule Maven plugin (MMP), copy the public URL configured in
Runtime Manager during the migration. If the endpoints specified in the `publicUrl` field of your
`pom.xml` file don’t match the ones configured in the UI, the Ingress configuration is lost.

#### CloudHub Application Default Domain

When deploying a new CloudHub 2.0 application during migration, don’t configure it to use the
inherited CloudHub default domain (the shared `*.cloudhub.io` endpoint in the format
`<app_name>.<region>.cloudhub.io`). This domain is automatically carried over to the CloudHub 2.0
private space, but it’s globally shared and can’t be managed by you. Route traffic through your
vanity domain or `anypointdns.net` endpoint instead. Using the default domain interferes with how
traffic switching determines the traffic source (SLB versus DLB) and can cause traffic outages.

#### Scheduler Concurrent Execution

Before you migrate the application, review Scheduler configurations for the
[known Scheduler concurrent-execution issue](https://docs.mulesoft.com/cloudhub/ch-ch2-migration-configuration#scheduler-concurrent-execution).

## Next Steps After Application Upgrade

After the upgrade process deploys your CloudHub 2.0 application, test the app by directing traffic
to it and verifying network connectivity and the app behavior.

To avoid updating your client applications that connect to CloudHub, retain the domains from
CloudHub on CloudHub 2.0. To link your applications, apply either of these options:

> [!NOTE] You can also use APIs for
> [application linking](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/amc-application-manager/minor/4.1/console/method/%231340/)
> using the `upgradeData` object while creating CloudHub 2.0 deployments, and for
> [traffic switching](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/amc-application-manager/minor/4.1/console/method/%231736/)
> using the newly introduced endpoint.

Customer-Managed

Switch the application’s [DNS](https://docs.mulesoft.com/cloudhub-2/ch2-config-endpoints-paths) to point to CloudHub 2.0.

MuleSoft-Managed

Carry over vanity URLs while incrementally switching percentage of traffic from CloudHub to CloudHub
2.0.

> [!IMPORTANT] Restart your DLB before initiating the traffic switching.

> [!NOTE] To switch application traffic, you must have the CloudHub Network Administrator
> permission. Without this permission, the traffic switching fails. For more information about
> assigning permissions, see
> [Permissions by Product in Anypoint Platform](https://docs.mulesoft.com/access-management/permissions-by-product).

> [!IMPORTANT] The CloudHub application must remain in STARTED state until the link between CloudHub
> and CloudHub 2.0 is successfully established. Stopping the CloudHub application before the link is
> established can cause traffic disruptions.

To gradually switch traffic from CloudHub to CloudHub 2.0:

1.  In **Runtime Manager**, go to **Finish Upgrade**.

2.  Select the percentage of traffic to direct from CloudHub to CloudHub 2.0, and click **Save
    Changes**.

    ![Traffic switching window showing the percentage slider to gradually redirect traffic from CloudHub to CloudHub 2.0 and the Save Changes button](/mulesoft/current/en-us/cloudhub/_images/traffic-switching.png)

> [!NOTE] You can roll back to CloudHub if there are failures during this stage.

### Understanding the Traffic Source

The traffic source determines which type of DNS record the process updates to manage the traffic
flow between your CloudHub and CloudHub 2.0 applications during the migration process. Understanding
this concept helps you anticipate how the system manages traffic based on your application’s
existing and new endpoint configurations.

CloudHub receives traffic from two main sources:

- Shared Load Balancer (SLB): This source is typically associated with the default endpoints of your
  CloudHub application. In applications with inbound traffic, the SLB handles traffic switching if
  your Ingress configuration includes the default CloudHub application endpoint in the format:
  `<app_name>.<region>.cloudhub.io`.

- Dedicated Load Balancer (DLB): This source is usually associated with vanity domains configured
  for your CloudHub application. If the default CloudHub endpoint is missing, and you have
  configured a vanity domain or an `anypointdns.net` endpoint, the DLB switches the traffic.

During traffic switching, CloudHub needs to know the traffic source to correctly switch traffic
between CloudHub and CloudHub 2.0. If you change your application’s endpoint configuration, the
inferred traffic source also changes. For example, if you initially have only vanity domains (DLB)
and then add a CloudHub default endpoint, CloudHub infers the traffic source as the SLB.

> [!NOTE] If your CloudHub 1.0 application has the default endpoint configured, traffic switches at
> the SLB. To switch traffic from the DLB instead, remove the CloudHub 1.0 default endpoint, apply
> changes, and then change the traffic switch percentage.

To ensure successful traffic switching, follow specific configurations depending on the type of load
balancer you want to use and the type of traffic you expect.

#### DLB with HTTPS Traffic Switching

For applications using a DLB and expecting HTTPS traffic:

1.  Enable the **Last-Mile Security** setting in the **Ingress** tab of the deployment settings for
    the CloudHub 2.0 application.

2.  Enable **Upstream TLS 1.2** or higher in your DLB settings.

3.  Make sure that vanity domains on CloudHub 2.0 match those on the CloudHub application to prevent
    dropped traffic.

#### DLB with HTTP Traffic Switching

For applications using a DLB and expecting HTTP traffic:

1.  Add a firewall rule allowing HTTP from the local private network.

> [!WARNING] The CloudHub DLB routes requests from clients to Mule apps deployed within the VPC. The
> DLB sends requests to a Mule application and uses the HTTP Host header to find the certificate
> endpoint that matches the request. Then, the DLB uses the URL mapping rules for that endpoint to
> send the request to the Mule application. If the request doesn’t match any certificate configured
> on the DLB, the DLB uses the "default" certificate endpoint to match the request against its URL
> mapping rules. During traffic switching, CloudHub 2.0 doesn’t contain mapping rules for this
> unmatched host within the default certificate.

#### SLB with HTTPS Traffic Switching

For applications using an SLB and expecting HTTPS traffic:

- Enable the **Last-Mile Security** setting in the **Ingress** tab of the deployment settings for
  the CloudHub 2.0 application.

#### SLB with HTTP Traffic Switching

For applications using an SLB and expecting HTTP traffic:

1.  Enable the **Accept HTTP** option within the **Advanced** tab of your private space settings.

2.  Add a firewall rule allowing HTTP from any source.

### Managing API Policies During Traffic Switching

When you apply API policies to your new application, they begin with a clean internal status.

#### Policies Unchanged by the App Migration

These policies don’t rely on internal status and their behavior remains consistent:

- http-basic-authentication

- cors

- client id enforcement

- Header injection

- Header removal

- ip-allowlist

- ip-blocklist

- ldap-authentication

- message-logging

- json-threat-protection

- xml-threat-protection

#### Policies Affected by Internal Status (Caching)

These policies rely on internal status to cache data:

- external-oauth2-access-token-enforcement

- openam-access-token-enforcement

- openidconnect-access-token-enforcement

- pingfederate-access-token-enforcement

- mule-http-caching-policy

- jwt-validation

When transitioning to the new application, these policies can either trigger additional requests to
the origin servers or have different cached values depending on which application receives the
requests.

#### Policies Affected by Internal Status (Request Counting)

These policies track the number of processed requests and can sometimes exhibit unexpected behavior
during the transition to the new application:

- rate-limiting

- rate-limiting-sla-based

- spike-control

If there’s a hard change in traffic from one application to the other, policy counters behave as if
they were reset. In a balanced round-robin traffic distribution, the effective number of requests
can sometimes double because each application maintains an independent counting mechanism.

During the CloudHub to CloudHub 2.0 application migration, traffic gradually shifts, and both
applications are active simultaneously. If your API Manager policies are integrated with your
original CloudHub application, the system can’t share or migrate these configurations in real time.
To maintain consistent policy enforcement, configure equivalent policies on your CloudHub 2.0
application’s API instance during traffic switching.

Autodiscovery connects a deployed Mule application with an API defined in API Manager. Throughout
the migration, both your CloudHub and CloudHub 2.0 applications link to the same API.

## Complete the Application Upgrade

After traffic fully redirects to the CloudHub 2.0 application, stop your CloudHub application within
30 days and mark the upgrade as complete.

If you change your CloudHub application after it stops, the changes aren’t replicated in your new
CloudHub 2.0 application. Make any required changes to the CloudHub 2.0 application settings.

After your CloudHub application stops, delete it within 30 days.

> [!NOTE] After the CloudHub application stops, traffic switches to the linked CloudHub 2.0
> application. To roll back the application upgrade, restart your CloudHub application and configure
> the traffic switching percentage. After you delete the CloudHub application, the migration is
> complete. You then can’t create another CloudHub application with the same application name.

Complete or delete all CloudHub applications in a given upgraded VPC to release entitlements.

## Perform DLB Failover

After the VPC upgrade and CloudHub application migration to CloudHub 2.0, perform a DLB failover to
retain domains during the transition from CloudHub to CloudHub 2.0. This ensures client application
compatibility.

To perform a DLB failover:

1.  For each DLB linked to your upgraded VPC, go to the DLB settings page and click **Failover to
    CloudHub 2.0**.

    This fails over the `anypointdns.net` domain to CloudHub 2.0, removes any additional DLB hop,
    and redirects traffic to your new CloudHub 2.0 private space URL.

2.  After the traffic failover completes, stop and delete the CloudHub DLB linked to the VPC.

> [!NOTE] If there are failures during this stage, restart the DLB to point `anypointdns.net` to
> CloudHub while the DLB is in a stopped state. After you delete the DLB, you can’t roll back to
> CloudHub.

For the final steps after VPC upgrade and CloudHub application migration, see
[CloudHub to CloudHub 2.0 Migration Completion](https://docs.mulesoft.com/cloudhub/ch-ch2-migration-completion).

## See Also

- [CloudHub VPC to CloudHub 2.0 Private Space Upgrade](https://docs.mulesoft.com/cloudhub/vpc-upgrade)

- [CloudHub to CloudHub 2.0 Migration Completion](https://docs.mulesoft.com/cloudhub/ch-ch2-migration-completion)

- [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space)

<!-- document id=abd38889e03127f03d1ba8c1afa17d585dde66adfc727db6fdddb5723ef83a73 url=/mulesoft/current/en-us/cloudhub/ch-ch2-migration-completion.md -->

---
product: CloudHub
---

# CloudHub to CloudHub 2.0 Migration Completion

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

After completing the VPC upgrade and application migration phases, complete the CloudHub to CloudHub
2.0 migration process and release associated entitlements within the recommended time frame:

## Mark Upgrade as Complete

> [!WARNING] Marking the upgrade as complete is an irreversible action. This action deletes the
> original VPC, stopped DLBs, and all CloudHub 1.0 applications marked as upgraded. All traffic then
> flows through the CloudHub 2.0 private space.

Marking the upgrade as complete finishes the entire VPC upgrade process. Go to the **Upgrade** tab
and click **Mark Upgrade Complete**.

![\*Mark Upgrade Complete\* button within the Upgrade tab](/mulesoft/current/en-us/cloudhub/_images/mark-upgrade-complete.png)

After you mark the upgrade complete, CloudHub 2.0 replaces all CloudHub resources and CloudHub
assets become immutable. Perform any required changes on CloudHub 2.0.

## Entitlements for VPCs, Private Spaces, and Network Connections (VPNs/TGW)

After you complete the VPC upgrade and bring over any existing TGW and VPN network connections, your
old and new infrastructure count separately against your usage. Therefore, if your organization uses
all purchased quota, your usage can exceed the allowed quota until you move all your applications to
CloudHub 2.0 and decommission your old VPC.

Work with your account representative to plan for additional entitlements, and decommission your
CloudHub infrastructure (VPCs and associated DLBs) within six months after the upgrade to avoid
interruptions when trying to create or edit VPCs, private spaces, or network connections.

> [!NOTE] Deleting the upgraded VPC after all applications and their associated DLBs are removed
> doesn’t affect your CloudHub 2.0 Private Spaces or CloudHub 2.0 applications.

## See Also

- [CloudHub VPC to CloudHub 2.0 Private Space Upgrade](https://docs.mulesoft.com/cloudhub/vpc-upgrade)

- [CloudHub to CloudHub 2.0 Application Migration](https://docs.mulesoft.com/cloudhub/app-migration)

<!-- document id=3054df701379cab7ece508018ea4830273f5a5f24850bf337a14dbd8dec895f7 url=/mulesoft/current/en-us/cloudhub/ch-ch2-migration-configuration.md -->

---
product: CloudHub
---

# CloudHub to CloudHub 2.0 Migration Configuration

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Migrate your CloudHub configurations to CloudHub 2.0 by following critical steps, handling
customizations, and ensuring all configuration dependencies resolve correctly. This process reduces
risks and keeps your systems compliant and efficient.

## Understand the Differences

Identify critical architectural differences and configuration gaps between ClouHub and CloudHub 2.0.
Review deployment models and environmental dependencies that affect custom configurations. Use this
information to accurately scope the migration effort and reduce incompatibility risk during upgrade
planning.

### Infrastructure and Networking Differences

Architecture

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>The CloudHub architecture includes two major components: Anypoint Platform services and a multitenant cloud of virtual machines distributed across global regions where your applications run. Individual instances of an application are called workers. CloudHub uses a VM-based infrastructure.</p></td><td><p>The CloudHub 2.0 architecture includes two major components: Anypoint Platform services and a multitenant cloud of containerized replicas distributed across global regions where your applications run. Individual instances of an application are called replicas. CloudHub 2.0 uses a container-based infrastructure.</p></td></tr><tr><td><p><span><img src="https://docs.mulesoft.com/cloudhub/_images/ch1-architecture-diagram-new.png" alt="Diagram showing CloudHub architecture"></span></p></td><td><p><span><img src="https://docs.mulesoft.com/cloudhub/_images/ch2-architecture-diagram-new.png" alt="Diagram showing CloudHub 2.0 architecture"></span></p></td></tr></tbody></table>

Private Network

The Private Network extends your corporate network and helps CloudHub workers and CloudHub 2.0
replicas to access resources behind the corporate firewall. Creating a private network differs
between CloudHub and CloudHub 2.0.

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>A <a href="https://docs.mulesoft.com/cloudhub/virtual-private-cloud">Virtual Private Cloud (VPC)</a> is a virtual, private, and isolated cloud network segment for hosting CloudHub workers.</p></td><td><p>A private space is a virtual, private, and isolated logical space in CloudHub 2.0 for running Mule apps.</p></td></tr><tr><td><p>Static IPs are managed per application, not at the VPC level. Turn on <strong>Static IPs</strong> for individual apps to receive their own set of egress static IPs.</p></td><td><p>Static IPs are provisioned at the private space level. All applications in the same private space share these outbound static IPs.</p></td></tr><tr><td><p>CloudHub provides a Shared Load Balancer (SLB) by default for all apps. The Dedicated Load Balancer (DLB) is optional, and you create and configure it within the VPC.</p></td><td><p>CloudHub 2.0 automatically provisions a fully managed ingress load balancer for the private space.</p></td></tr><tr><td><p>TLS/SSL certificates require manual configuration. The SLB uses the platform’s wildcard certificate. For custom domains, create a DLB and upload PEM-encoded certificates and private keys.</p></td><td><p>CloudHub 2.0 automatically creates a default TLS context for the private space with wildcard certificates for both internal and public endpoints. You can configure custom vanity domains with your own TLS context for both internal and external endpoints.</p></td></tr></tbody></table>

Connectivity Methods

The private network connects to the corporate network using these connectivity methods:

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><div><div><ul><li><p>VPC peering (AWS VPC to Mule VPC)</p><div><p>Requires configuration. Contact the MuleSoft Support team to enable.</p></div></li><li><p>AWS Direct Connect + Requires configuration. Contact the MuleSoft Support team to enable.</p></li><li><p>Transit Gateway Attachments</p></li><li><p>VPN tunnel/IPsec tunnel</p></li></ul></div></div></td><td><div><div><ul><li><p>VPN tunnel</p></li><li><p>Transit Gateway Attachments</p></li></ul></div></div></td></tr><tr><td><p>Contact the MuleSoft Support team to enable VPC peering and AWS Direct Connect.</p></td><td><p>CloudHub 2.0 supports Transit Gateway or VPN tunnel.</p></td></tr></tbody></table>

Firewall Rules

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub Ingress (Inbound) Rules</th><th>CloudHub 2.0 Ingress (Inbound) Rules</th></tr></thead><tbody><tr><td><p>CloudHub adds firewall rules automatically when you create a VPC.</p></td><td><p>CloudHub 2.0 adds firewall rules automatically when you create a private space.</p></td></tr><tr><td><p>By default, all traffic to a VPC is blocked unless explicitly allowed by a firewall rule. However, CloudHub automatically creates four default inbound firewall rules when you create a VPC.</p></td><td><p>Traffic to a private space is blocked unless explicitly allowed by a firewall rule.</p></td></tr><tr><td><div><div><p>CloudHub creates four default inbound rules automatically:</p></div><div><ul><li><p>Two rules to allow inbound connections from within your local Anypoint VPC through ports 8091 and 8092.</p><div><ul><li><p>Specifically for DLB interactions.</p></li></ul></div></li><li><p>Two rules allow inbound connections from anywhere through ports 8081 and 8082.</p><div><ul><li><p>Specifically for SLB interactions.</p></li></ul></div></li></ul></div></div></td><td><div><div><p>CloudHub 2.0 creates two default inbound rules automatically:</p></div><div><ul><li><p>Two rules to allow inbound connections from any host:</p><div><ul><li><p>HTTPS: port 443</p></li><li><p>HTTP: port 80</p></li></ul></div></li></ul></div></div></td></tr><tr><td><p>CloudHub supports HTTP, HTTPS, and TCP protocols. The Dedicated Load Balancer (DLB) also supports WebSockets (ws and wss).</p></td><td><p>CloudHub 2.0 supports HTTP, HTTPS, and TCP protocols. The upgrade tooling does not support TCP traffic migration yet.</p></td></tr><tr><td><p>The maximum number of firewall rules is approximately 35 per VPC, depending on the number of rules CloudHub requires.</p></td><td><p>The maximum number of inbound firewall rules is 300.</p></td></tr></tbody></table>

<table><colgroup><col></colgroup><thead><tr><th>Egress (Outbound) Rules</th></tr></thead><tbody><tr><td><p>CloudHub doesn’t support egress firewall rules. It allows all outbound traffic by default.</p></td></tr><tr><td><p>CloudHub 2.0 creates two default outbound rules automatically. You can configure additional rules and application-level egress rules for granular control. The maximum number of outbound firewall rules is 300.</p></td></tr><tr><td><div><div><p>CloudHub 2.0 adds two egress rules by default. You can delete these rules if you want to block all outbound traffic for security reasons:</p></div><div><ul><li><p>TCP: All ports (to anywhere)</p></li><li><p>HTTPS: 443 (to anywhere)</p></li></ul></div></div></td></tr></tbody></table>

<table><colgroup><col></colgroup><thead><tr><th>CloudHub 2.0 Application-Level Egress Rules</th></tr></thead><tbody><tr><td><p>CloudHub 2.0 supports egress firewall rules at the application level. Application-level egress rules are independent of private-space-level firewall rules. See <a href="https://docs.mulesoft.com/cloudhub-2/ps-config-app-level-egress">Configuring Application-Level Egress Rules</a>.</p></td></tr><tr><td><p>Turn on application-level egress rules in Runtime Manager.</p></td></tr><tr><td><p>In CloudHub 2.0, egress traffic passes through both application-level control (enforced first) and private-space-level control (enforced after application-level control).</p></td></tr><tr><td><p>Apply application-level egress rules when you deploy your application. See <a href="https://docs.mulesoft.com/cloudhub-2/ps-config-app-level-egress#apply-application-level-egress-rules-when-deploying-your-applications">Apply Application-Level Egress Rules</a>.</p></td></tr><tr><td><div><div><p>You can configure application-level egress connections, such as:</p></div><div><ul><li><p>Anypoint MQ</p></li><li><p>Object Store v2</p></li><li><p>API Manager</p></li></ul></div></div></td></tr></tbody></table>

Static IP Addresses

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>CloudHub supports static IP addresses at the application level.</p></td><td><p>CloudHub 2.0 supports static IP addresses at the private space level.</p></td></tr><tr><td><p>If you turn on <strong>Static IPs</strong> for an application, CloudHub provides outbound static IPs.</p></td><td><p>CloudHub 2.0 provides inbound and outbound static IPs at the private space level.</p></td></tr><tr><td><p>Applications deployed to the same VPC don’t automatically share static IPs. If you turn on <strong>Static IPs</strong> for an application, it receives its own set of outbound static IPs. Inbound static IPs are available only through a DLB, and all applications behind the same DLB share them.</p></td><td><p>Applications deployed to the same private space use the same set of inbound and outbound static IPs. To have unique static IPs per application, use a different private space.</p></td></tr></tbody></table>

Load Balancing

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><div><div><p>CloudHub provides two types of load balancing:</p></div><div><ul><li><p>Shared Load Balancer (SLB): CloudHub provides it by default for all apps.</p></li><li><p>Dedicated Load Balancer (DLB): You create it within the VPC.</p></li></ul></div></div></td><td><p>CloudHub 2.0 automatically provides a fully managed ingress load balancer for each private space with a simplified architecture that removes the need to select or create load balancers.</p></td></tr><tr><td><p>CloudHub load balancers provide round-robin load distribution across workers.</p></td><td><p>CloudHub 2.0 provides a fully managed ingress load balancer for each private space that automatically balances inbound traffic across multiple application replicas. The ingress load balancer auto-scales to accommodate traffic. You can configure this load balancer to meet your specific requirements.</p></td></tr><tr><td><p>CloudHub doesn’t support load balancer logs for the DLB. The SLB has no log access.</p></td><td><p>Download ingress traffic logs from Runtime Manager for full visibility into ingress traffic and troubleshooting.</p></td></tr><tr><td><p>You can assign up to four load balancer units (up to eight workers total) to a Dedicated Load Balancer (DLB) for high availability and load distribution. The Shared Load Balancer (SLB) provides fully managed high availability with no customer configuration required.</p></td><td><p>CloudHub 2.0 automatically distributes application replicas across two or more availability zones (AZs) for built-in high availability and fault tolerance. If you use the <a href="https://docs.mulesoft.com/cloudhub/vpc-upgrade">VPC upgrade tool</a>, the private space inherits the same number of AZs as the original CloudHub VPC.</p></td></tr><tr><td><div><div><p>URL decoding is enabled by default at the ingress layer for both SLB and DLB:</p></div><div><ul><li><p>SLB: URL decoding is always enabled.</p></li><li><p>DLB: URL decoding is enabled by default, but you can disable it by enabling the <strong>Keep URL encoding</strong> option.</p></li></ul></div></div></td><td><p>URL encoding is enabled by default at the ingress layer for both Shared Space (SS) and Private Space (PS). CloudHub 2.0 does not support URL decoding at the ingress layer. URLs remain encoded as received from the client.</p></td></tr></tbody></table>

Domains and TLS Context

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>SSL termination happens at the DLB layer.</p></td><td><p>SSL termination happens at the ingress load balancer layer.</p></td></tr><tr><td><p>The communication between the DLB and the Mule application is internal to the VPC.</p></td><td><p>Applications inside a private space communicate using the ingress load balancer via the internal endpoint. This depends on the application protocol.</p></td></tr><tr><td><div><div><p>Supported protocols:</p></div><div><ul><li><p><a href="https://help.salesforce.com/s/articleView?id=004205269&amp;type=1">TLS 1.1</a> (for existing DLBs until January 31, 2026)</p></li><li><p>TLS 1.2</p></li><li><p><a href="https://help.salesforce.com/s/articleView?id=001116412&amp;type=1">TLS 1.3</a></p></li></ul></div></div></td><td><div><div><p>Supported protocols:</p></div><div><ul><li><p>TLS 1.2</p></li><li><p>TLS 1.3</p></li></ul></div></div></td></tr><tr><td></td><td><p>An application can have multiple endpoints, depending on ‌the domain and TLS context configuration.</p></td></tr></tbody></table>

Mutual TLS

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>CloudHub doesn’t provide native mutual TLS (mTLS) capability. The Dedicated Load Balancer (DLB) handles mTLS at the infrastructure level, performing client certificate validation and forwarding certificate information to applications via HTTP headers.</p></td><td><p>CloudHub 2.0 provides native mTLS with TLS contexts and truststores. Configure mTLS at the private space level with centralized management. CloudHub 2.0 also supports forward SSL, which forwards client certificate information to applications via HTTP headers.</p></td></tr><tr><td><p>CloudHub supports limited Certificate Authority (CA) certificates through the DLB. It accepts certificate files in PEM format only.</p></td><td><p>CloudHub 2.0 provides dynamic certificate management, application-level <a href="https://docs.mulesoft.com/cloudhub-2/ps-config-domains#truststore">truststore</a> access, and in-place updates without redeployment. Upload truststore files in PEM and JKS formats.</p></td></tr></tbody></table>

URL Rewriting

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>Implement URL rewriting at the DLB level using mapping rules. Configure a DLB to use this feature.</p></td><td><p>Implement URL rewrite at the application level using domains and endpoints for a more flexible, per-app configuration.</p></td></tr></tbody></table>

Internal Application Communication

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>The internal worker hostname <code>mule-worker-internal-&lt;app&gt;.&lt;region&gt;.cloudhub.io</code> resolves to the Mule worker’s internal IP address for VPC-internal communication.</p></td><td><div><div><p>Use one of these three options:</p></div><div><ul><li><p>Internal endpoint: <code>internal-&lt;app&gt;-&lt;uniq-id&gt;.&lt;space-id&gt;.&lt;region&gt;.cloudhub.io.</code></p></li><li><p>Custom internal endpoint: CNAME pointing to the internal endpoint. You can configure custom TLS contexts for internal endpoints that are only accessible via the private network.</p></li><li><p>Kubernetes service address: Direct pod-to-pod communication. This works only for applications in the same namespace (environment).</p></li></ul></div></div></td></tr></tbody></table>

### Application Differences

Persistent VM Queues Vs. Anypoint MQ

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>CloudHub persistent queues store VM queue messages externally to the application. Use this feature mainly with VM components. Turn on CloudHub persistent queues on a per-application basis.</p></td><td><p><a href="https://docs.mulesoft.com/mq/">Anypoint MQ</a> provides persistent message storage in cloud infrastructure, eliminating VM-dependent queue management. Anypoint MQ provides asynchronous message processing, event-driven architectures, and cross-application communication. Configure Anypoint MQ on a per-application basis with automatic scaling and high availability.</p></td></tr></tbody></table>

Logging

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>During deployment, CloudHub automatically replaces the application archive’s <code>log4j2.xml</code> file with a predefined template. CloudHub uses the original <code>log4j2.xml</code> file only when you disable CloudHub logs.</p></td><td><p>CloudHub 2.0 merges the <code>log4j2.xml</code> configuration file from the application archive with predefined appenders. These appenders send logs directly to Runtime Manager and Anypoint Monitoring, preserving custom appenders while enabling platform integration.</p></td></tr><tr><td><p>Download the application and runtime logs separately.</p></td><td><p>CloudHub 2.0 merges application and runtime logs into a single log stream. To find runtime logs, download the application log and check for runtime-related messages.</p></td></tr><tr><td><p>CloudHub stores logs in the region where it was first deployed. If you move the app to another region, the logs remain stored in the initial deployment region. To reset this log retention configuration, delete and re-create the app.</p></td><td><p>CloudHub 2.0 stores logs in the region where the application is currently deployed. You can’t move the app to a different region once deployed. To reset this log retention configuration, delete and re-create the app.</p></td></tr><tr><td><p>CloudHub has limited control over log forwarding.</p></td><td><div><div><p>If you deselect <strong>Forward application logs to Anypoint Platform</strong> within the app configuration in Runtime Manager:</p></div><div><ul><li><p>CloudHub 2.0 doesn’t forward application logs to Runtime Manager or Anypoint Monitoring.</p></li><li><p>The custom log appenders configured in your application continue to function normally (excluding file-based appenders).</p></li></ul></div><div><p>This provides more granular control over platform log forwarding.</p></div></div></td></tr><tr><td><p>For more information, see <a href="https://help.salesforce.com/s/articleView?id=001117963&amp;type=1">CloudHub 1.0 Logging FAQ</a></p></td><td><p>For more information, see <a href="https://help.salesforce.com/s/articleView?id=001119527&amp;type=1">CloudHub 2.0 Logging FAQ</a></p></td></tr></tbody></table>

Known Issue: Scheduler Concurrent Execution

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>For affected applications, CloudHub prevents overlapping executions of the same Scheduler even when the Scheduler source’s <code>disallowConcurrentExecution</code> setting is <code>false</code> or omitted.</p></td><td><p>CloudHub 2.0 honors the <code>disallowConcurrentExecution</code> setting. If the setting is <code>false</code> or omitted, another execution can start before the previous execution finishes.</p></td></tr></tbody></table>

This issue applies only when you migrate an application from CloudHub to CloudHub 2.0. Review each
Scheduler that has a small interval, such as less than one second, and can run longer than its
configured interval, when `disallowConcurrentExecution` is `false` or omitted. CloudHub 2.0 can
start overlapping executions that consume the application thread pool shared by all flows. Excessive
queued executions can delay or prevent other flows from running.

To prevent overlapping executions after migration, explicitly set
`disallowConcurrentExecution="true"`. If a trigger becomes due while the previous execution is still
running, CloudHub 2.0 skips that trigger and tries again at the next configured interval.

When an affected Scheduler has a very short interval, skipped triggers can generate excessive
INFO-level log messages. To suppress INFO-level messages from
`org.mule.runtime.core.internal.source.scheduler.DefaultSchedulerMessageSource`, including the
repeated `Execution skipped` message, set its log level to **WARNING** in the application’s
**Monitoring** tab. Applying the log-level change restarts the application. For instructions, see
[Configure Log Levels and Categories](https://docs.mulesoft.com/cloudhub-2/ch2-manage-app-logs#configure-log-levels-and-categories).

For more information about the Scheduler source setting, see
[Scheduler](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#props_scheduler).

Deployment Configuration

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>Use maven and <code>pom.xml</code> configuration to deploy applications to CloudHub. See <a href="https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub">Deploy Applications to CloudHub Using the Mule Maven Plugin</a>.</p></td><td><div><div><p>App deployment with maven and <code>pom.xml</code> configuration takes two steps:</p></div><div><ol><li><p>Publish the artifact to Anypoint Exchange (<code>mvn clean deploy</code>).</p></li><li><p>Deploy the artifact to CloudHub 2.0 (<code>mvn clean deploy</code>, <code>-DmuleDeploy</code>).</p></li></ol></div><div><p>For more information, see <a href="https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub-2">Deploy Applications to CloudHub 2.0 Using the Mule Maven Plugin</a>.</p></div></div></td></tr><tr><td><p>The maximum size of a Mule application (ZIP or JAR) file is 200 MB.</p></td><td><p>The maximum size of a Mule application JAR file is 350 MB.</p></td></tr><tr><td><p>Names are unique per control plane.</p></td><td><div><div><p>Names are unique per private space. CloudHub 2.0 adds a six-character unique ID to the application name that you specify in the public endpoint URL: <code>Myapp-uniq-id.shard.region.cloudhub.io</code></p></div><div><ul><li><p><code>uniq-id</code>: is a six-digit value appended to the app name to ensure uniqueness.</p></li><li><p><code>shard</code>: is a six-digit value associated with the space (private or shared) the app is deployed to.</p></li></ul></div></div></td></tr><tr><td><p>The DLB supports a maximum HTTP POST (payload) size of 200 MB.</p></td><td><p>The maximum HTTP request size is 1 GB.</p></td></tr></tbody></table>

vCore Sizes

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>See <a href="https://docs.mulesoft.com/cloudhub/cloudhub-architecture#cloudhub-workers">CloudHub Workers</a>.</p></td><td><p>See <a href="https://docs.mulesoft.com/cloudhub-2/ch2-architecture#cloudhub-2-replicas">CloudHub 2.0 Replicas</a>.</p></td></tr></tbody></table>

CloudHub 2.0 provides a more granular resource capacity for applications. You can assign specific
vCore increments (including 0.5, 1.5, 2.5, 3, 3.5, and 4). This granularity helps match processing
needs precisely and avoids forcing a jump from 0.2 to 1 vCores. Replicas with fewer than 1.0 vCores
offer limited CPU and I/O suitable for smaller workloads, while those with one or more vCores
provide performance consistency.

Worker Vs. Replica

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>A worker in CloudHub is a dedicated Amazon Elastic Compute Cloud (EC2) virtual machine instance that runs your Mule application. It functions as a full, independent virtual server with its own operating system, memory, CPU resources, and isolated runtime environment.</p></td><td><p>A replica in CloudHub 2.0 is a dedicated, containerized instance of Mule runtime engine that runs your integration application. Each replica provides complete isolation between applications with its own isolated environment, allocated memory (heap and total), CPU resources (vCores), and storage capacity.</p></td></tr><tr><td><p>If you select <strong>Automatically restart application when not responding</strong>, CloudHub monitors the worker and automatically restarts the application if necessary.</p></td><td><p>CloudHub 2.0 provides self-healing capabilities that automatically recover applications from both Mule process failures and underlying infrastructure failures. If either the Mule process or the infrastructure fails, CloudHub 2.0 automatically restarts the application on healthy infrastructure without your intervention. Application crash recovery is enabled by default.</p></td></tr><tr><td><p><span><img src="https://docs.mulesoft.com/cloudhub/_images/worker-logical-rep.png" alt="Diagram showing the logic of a worker" width="500" height="300"></span></p></td><td><p><span><img src="https://docs.mulesoft.com/cloudhub/_images/replica-logical-rep.png" alt="Diagram showing the logic of a replica" width="500" height="300"></span></p></td></tr></tbody></table>

High Availability with Clustering

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>CloudHub doesn’t support Mule clustering. You can run multiple workers for scale and High Availability (HA), but they’re independent runtimes without cluster semantics. There’s no distributed in-memory state or cluster-aware components.</p></td><td><p>CloudHub 2.0 supports Mule clustering. Multiple replicas of the same app form a managed cluster, enabling cluster-aware runtime behavior. This includes shared memory and distributed locking across runtime replicas, with a single primary replica running the application logic and secondary replica(s) available for high-availability if the primary goes down.</p></td></tr><tr><td><p>CloudHub scales applications by deploying multiple workers (up to eight) for each application. The SLB automatically distributes traffic across these workers. For applications that need shared state, store that state externally (for example, in a database or Object Store). Workers can’t share in-memory state.</p></td><td><p>CloudHub 2.0 scales applications by deploying multiple replicas (up to sixteen) for each application. The platform’s cluster mode coordinates behavior across these replicas automatically. For applications with stateful requirements, use Mule’s native clustered features (such as clustered object stores and clustered caches) to maintain state across replicas.</p></td></tr><tr><td><p>CloudHub achieves HA with two or more workers. It supports availability across AZs, and the platform handles failover.</p></td><td><p>CloudHub 2.0 provides fully managed HA. The platform automatically spreads replicas across two or more AZs, with round-robin HTTP load balancing and cluster-aware recovery. If you use the <a href="https://docs.mulesoft.com/cloudhub/vpc-upgrade">VPC upgrade tool</a>, the private space inherits the same number of AZs as the original CloudHub VPC.</p></td></tr><tr><td><p>CloudHub monitors workers and automatically performs restarts. Blue-green deployment at the DLB or SLB layer provides seamless cutover, but this process lacks cluster draining and coordination within the runtime.</p></td><td><p>CloudHub 2.0 provides orchestrated restarts and rolling updates across replicas. Cluster-aware coordination minimizes impact during upgrades and failures.</p></td></tr><tr><td><p>You manage worker counts and rely on external stores for shared state.</p></td><td><p>CloudHub 2.0 provides fully managed clustering. Select replica counts, and the platform handles cluster formation, health, placement, and recovery.</p></td></tr></tbody></table>

### Runtime Manager Differences

Alerts

<table><colgroup><col> <col></colgroup><thead><tr><th>CloudHub</th><th>CloudHub 2.0</th></tr></thead><tbody><tr><td><p>CloudHub triggers custom alerts when your application sends notifications to Runtime Manager using Anypoint Connector for CloudHub (CloudHub Connector). For more information, see <a href="https://docs.mulesoft.com/cloudhub/custom-application-alerts">Custom Application Alerts</a>.</p></td><td><p>CloudHub 2.0 enables application deployment success and failure alerts. For custom alerting, CloudHub 2.0 leverages Anypoint Monitoring Alerts For more information, see <a href="https://docs.mulesoft.com/cloudhub-2/ch2-config-app-alerts">Configuring Application Alerts</a>.</p></td></tr></tbody></table>

## Migrate Your CloudHub Applications to CloudHub 2.0

Migrate your CloudHub applications to CloudHub 2.0 by gathering reusable artifacts, creating private
spaces, and updating application configurations. Collect CIDR blocks, VPN connections, SSL
certificates, and firewall rules from your existing CloudHub environment. Update Mule runtime
versions to a supported runtime version. If you are using persistent queues and CloudHub connectors,
modify application code to remove them. Deploy applications using the two-step process through
Anypoint Exchange and configure egress firewall rules for Mule services access.

### Before You Begin

Gather the required information to set up a private space and use your CloudHub reusable artifacts
to configure the CloudHub 2.0 environment:

- CIDR block information

  If you require both CloudHub and CloudHub 2.0 to exist at the same time on the same network, use a
  new CIDR block for CloudHub 2.0.

- VPN connection information

- SSL certificates

- DNS server information

- Ingress firewall rules

- Mule application code

For more information, see
[Information Required to Set Up a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#setup-info-private-space).

### Create Your Private Space

- If you’re using DLB, configure custom TLS certificates in your private space.

- Create and configure your CloudHub 2.0 private space using one of these methods:

  - [CloudHub 2.0 API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/)

  - Anypoint Runtime Manager

    See [Create a Private Space via Runtime Manager](https://docs.mulesoft.com/cloudhub-2/ps-create-configure).

### Update the Mule Runtime Version

CloudHub 2.0 supports Mule runtime versions 4.3.x and later. Upgrade to a supported Mule runtime
version.

### Update the Mule Application Code

- Update the application’s `pom.xml` with CloudHub 2.0 deployment configuration. See
  [Deploy to CloudHub 2.0](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub-2).

- Update the application’s `log4j2.xml` with log forwarding options if needed. See
  [Integrate with Your Logging System Using Log4j](https://docs.mulesoft.com/cloudhub-2/ch2-integrate-log-system).

- Review Scheduler configurations for the
  [known Scheduler concurrent-execution issue](#scheduler-concurrent-execution).

- Remove persistent queues and implement AnypointMQ.

- Remove CloudHub Connector and replace with custom logic.

### Deploy your Application

- If you’reusing DLB, configure application mapping rules via path and path rewrite configurations
  for endpoints in the application deployment.

- Publish your application to [Anypoint Exchange](https://docs.mulesoft.com/exchange/).

- Deploy your application to your CloudHub 2.0 private space. See
  [Deploy to a Private Space](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space).

- Configure required egress firewall rules to access other Mule services, such as API Manager,
  ObjectStore, and Anypoint MQ. See
  [Configure an Application-Level Egress](https://docs.mulesoft.com/cloudhub-2/ps-config-app-level-egress#apply-application-level-egress-rules-when-deploying-your-applications).

- Update CI/CD scripts to support the two-step deployment process.

### Review CloudHub 2.0 Limitations

Before finalizing the migration, review the [CloudHub 2.0 Limitations](https://docs.mulesoft.com/cloudhub-2/ch2-limits).

## See Also

- [CloudHub 2.0 Overview](https://docs.mulesoft.com/cloudhub-2/)

- [CloudHub 2.0 for CloudHub 1.0 Users](https://docs.mulesoft.com/cloudhub-2/ch2-comparison)

- [Features of CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-features)

- [Limits in CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-limits)

- [CloudHub VPC to CloudHub 2.0 Private Space Upgrade](https://docs.mulesoft.com/cloudhub/vpc-upgrade)

- [CloudHub to CloudHub 2.0 Application Migration](https://docs.mulesoft.com/cloudhub/app-migration)

- [CloudHub to CloudHub 2.0 Migration Completion](https://docs.mulesoft.com/cloudhub/ch-ch2-migration-completion)

- [CloudHub 2.0 Architecture](https://docs.mulesoft.com/cloudhub-2/ch2-architecture)

- [CloudHub 2.0 Networking Architecture](https://docs.mulesoft.com/cloudhub-2/ch2-networking-guide)

<!-- document id=9973d185eacb581ca5c59fa692a11ed498c2e70cea44da68027f6156a2143643 url=/mulesoft/current/en-us/cloudhub/vpc-upgrade.md -->

---
product: CloudHub
---

# CloudHub VPC to CloudHub 2.0 Private Space Upgrade

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To migrate your workloads from CloudHub to CloudHub 2.0, you must set up your CloudHub 2.0
infrastructure and network connections. One approach is to create new CloudHub 2.0 private spaces
with configurations that differ from your existing CloudHub setup.

To retain your infrastructure configuration, use the in-product VPC upgrade tool to easily migrate
your CloudHub dedicated Virtual Private Cloud (VPC) to a CloudHub 2.0 private space.

When your new private space is ready, you can gradually migrate your applications from the CloudHub
VPC to the CloudHub 2.0 private space. After moving all your applications, you can decommission your
old VPC.

Using the in-product VPC upgrade tool saves you time because you don’t need to acquire new CIDR
blocks, set up new network connections, and configure the private space from the ground up.

The tool provisions the infrastructure for a CloudHub 2.0 private space by cloning the existing
configurations of your eligible CloudHub dedicated VPC, using the same CIDR block.

If your VPC has existing Transit Gateways (TGW) or Virtual Private Networks (VPN) connections, they
transfer seamlessly to the new CloudHub 2.0 private space. This migration ensures that any new
applications deployed to the new private space can communicate effectively.

The upgrade tool doesn’t migrate or delete VPC peering connections. If a VPC with peering completes
the upgrade, those connections remain on the CloudHub VPC. CloudHub apps can keep using them. Apps
in the new CloudHub 2.0 private space can’t use those peering connections.

The default CloudHub certificates are configured as part of the private space’s default
certificates. The DLB custom domains of the migrated VPC are created as part of the private space’s
custom TLS certificates.

The VPC upgrade tool migrates the DLB certificates to the new private space on a best-effort basis
only. If the migration excludes certificates or your apps require specific TLS configurations,
manually add TLS contexts to the private space. In the new private space, use the **Domains & TLS**
tab to ceate DLB certificates.

> [!IMPORTANT] The VPC upgrade tool reuses the same underlying CloudHub VPC, so the new CloudHub 2.0
> private space inherits the same number of availability zones (AZs) as the original VPC. The
> upgrade process does not add or change availability zones. For example, if your CloudHub VPC has
> only two AZs, the upgraded CloudHub 2.0 private space also has two AZs.

> [!NOTE] During the VPC upgrade process, you use doubled entitlements for your VPC and network
> connections. Work with your account representative to remain compliant with entitlements and
> finish the upgrade on time.

## Understand Eligibility

Due to their architectural differences and distinct interfaces, CloudHub 2.0 supports some features
differently than CloudHub. Follow this eligibility checklist to confirm which VPCs are eligible for
the upgrade:

Availability of IPs

Your VPC must have at least 25% free space, and 100 or more available IP addresses per subnet to be
eligible for the upgrade.

Legacy VPNs

VPCs with legacy VPNs configured aren’t eligible for the upgrade.

Direct Connect or VPC Peering

If your VPC has Direct Connect or VPC Peering configured, migrate to Transit Gateway or VPN before
upgrading.

TLS 1.1 ciphers

These ciphers can’t be carried over from CloudHub to CloudHub 2.0:

- ECDHE-ECDSA-AES128-SHA1

- ECDHE-ECDSA-AES256-SHA1

- ECDHE-RSA-AES128-SHA1

- ECDHE-RSA-AES256-SHA1

Limitation for Restricting Outbound Egress Traffic

CloudHub VPC doesn’t restrict outbound egress traffic, so removing the default firewall rule that
allows this traffic can cause failures in your migrated private space.

Non-HTTP/S TCP Traffic

HTTP and HTTPS traffic can be sent to applications in the migrated Private Space. TCP traffic is not
supported.

## Understand Environment Association

During the upgrade process from CloudHub VPC to CloudHub 2.0 Private Space, the environments
associated with your VPC stay in sync with the environments associated with the upgraded CloudHub
2.0 Private Space to avoid configuration drift.

Environment association works differently in [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ps-config-env) and
[CloudHub 1.0](https://docs.mulesoft.com/cloudhub/vpc-tutorial#update-an-existing-anypoint-vpc). In CloudHub 2.0, an environment can be
associated with multiple private spaces, whereas, in CloudHub, one environment can only be
associated with one VPC in a given region.

Additionally, doing bulk environment association for an upgraded private space can result in all
environments in the same region to get associated with the underlying VPC. If those environments
were previously associated with other CloudHub 1.0 VPCs, they get disassociated.

> [!WARNING] The upgrade tooling doesn’t support the upgrade of a default VPC. To proceed with the
> upgrade, disable the default VPC configuration.

## Upgrade your VPC via Anypoint Platform

1.  From **Anypoint Platform**, select **Runtime Manager** > **Upgrade**.

    Alternatively, from **Runtime Manager**, open the VPC upgrade entry point when it appears in the
    console, then click **Continue to Upgrade** to start upgrading your VPCs.

2.  Click **Upgrade Now** in the **Upgrade Status** column for the VPC to upgrade.

    The **Upgrade to CloudHub 2.0** review page displays the configurations currently available in
    your VPC, as well as the configurations created during the upgrade.

    ![VPC upgrade review page showing available configurations.](/mulesoft/current/en-us/cloudhub/_images/upgrade-ch2-review-conf.png)

3.  Click **Next** to continue.

4.  Provide a name for the new private space.

    Optionally, you can specify [reserved CIDRs](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#cidr-block) to
    connect to your new private space.

5.  Click **Create** to create the new private space.

    The **Upgrade to CloudHub 2.0** review page shows the progress of the VPC upgrade process, which
    takes about 15 to 30 minutes.

> [!NOTE] If you create a VPN to provision your CloudHub VPC, wait until the newly created VPN
> status shows as available before migrating your VPC to a CloudHub 2.0 private space.

As soon as the upgrade process starts, the upgraded VPC is locked for any further updates.

You can cancel the upgrade process to revert to your VPC at any time by clicking **Cancel Upgrade**.
In that case, the system deletes the newly created private space, and your VPC is unlocked.

After you provision the private space, the **Cancel Upgrade** button no longer shows. However, you
can still roll back the upgrade by deleting the private space.

## Next Steps After VPC Upgrade

Following the VPC upgrade, the CloudHub 2.0 private space is fully provisioned, and you can deploy
applications to it.

> [!IMPORTANT] Access new apps in the private space via the private space’s public ingress. CloudHub
> DLB and SLBs can’t route traffic to these apps.

You have two options for migrating your applications:

Self-Service

Create new versions in the CloudHub 2.0 private space. Then, delete the corresponding application in
the CloudHub VPC.

Runtime Manager Tool

Migrate your applications using the application migration tool. See
[CloudHub to CloudHub 2.0 Application Migration](https://docs.mulesoft.com/cloudhub/app-migration).

After you migrate all the applications in a VPC, delete the VPC and any associated DLBs to release
your CloudHub entitlements. This action doesn’t affect your CloudHub 2.0 private space.

For the final steps after VPC upgrade and CloudHub application migration, see
[CloudHub to CloudHub 2.0 Migration Completion](https://docs.mulesoft.com/cloudhub/ch-ch2-migration-completion).

> [!NOTE] When deploying a new CloudHub 2.0 application during migration, don’t configure it to use
> the inherited CloudHub default domain (the shared `*.cloudhub.io` endpoint in the format
> `<app_name>.<region>.cloudhub.io`). This domain is automatically carried over to the CloudHub 2.0
> private space, but it’s globally shared and can’t be managed by you. Route traffic through your
> vanity domain or `anypointdns.net` endpoint instead. Using the default domain interferes with how
> traffic switching determines the traffic source (SLB versus DLB) and can cause traffic outages.

During the migration, you can continue to deploy and manage applications in your VPC to maintain
business continuity. To prevent configuration drift, after the upgrade, your CloudHub dedicated VPC
is locked for any changes to the infrastructure, including environment or business group
associations, network connections, and internal DNS. Make any required changes to the newly created
private space. The upgrade process applies any CloudHub 2.0 configuration changes to the CloudHub
VPC.

If your CloudHub VPC doesn’t have any network connections, and you create new ones in your new
CloudHub 2.0 private space after the upgrade, these new connections aren’t reflected in your
CloudHub VPC.

The firewall rules configured in your VPC are copied to the private space. After that, you can make
additional changes to the firewall rules in the VPC and the private space. To avoid configuration
drift, apply any firewall rule changes in both places throughout the migration.

> [!WARNING] VPC firewall rules that have ports other than `80`, `443`, and `30500` to `32500` drop
> during the migration.

### Enable CloudHub 2.0 Apps to Communicate with CloudHub Apps via DLB

During a partial migration, a CloudHub 2.0 app may need to communicate with a CloudHub app through
the CloudHub Dedicated Load Balancer (DLB). Because CloudHub 2.0 uses a separate infrastructure CIDR
pool, the DLB doesn’t allow this traffic by default.

To allow a CloudHub 2.0 app to reach a CloudHub app via the DLB, add the following CloudHub 2.0
infrastructure CIDR ranges to the DLB allowlist:

- `100.64.0.0/16`

- `100.66.0.0/16`

- `100.67.0.0/16`

- `100.68.0.0/16`

For more information about CloudHub 2.0 infrastructure CIDR ranges, see
[Infrastructure CIDR Pool](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#infra-cidr-pool).

## See Also

- [CloudHub to CloudHub 2.0 Application Migration](https://docs.mulesoft.com/cloudhub/app-migration)

- [CloudHub to CloudHub 2.0 Migration Completion](https://docs.mulesoft.com/cloudhub/ch-ch2-migration-completion)

- [CloudHub 2.0 Overview](https://docs.mulesoft.com/cloudhub-2/)

- [Features of CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-features)

- [CloudHub 2.0 for CloudHub 1.0 Users](https://docs.mulesoft.com/cloudhub-2/ch2-comparison)

- [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about)

- [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space)

<!-- document id=ab343344a222f9269336a0db73376c7990a2a3e5e70689f48b04be8b89306d03 url=/mulesoft/current/en-us/cloudhub/lb-ssl-endpoints.md -->

---
product: CloudHub
---

# Configure SSL Endpoints and Certificates

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

A dedicated load balancer must have at least one certificate associated with it. To configure an SSL
endpoint for your load balancer to serve to clients, provide a certificate and private key pair for
your load balancer.

A load balancer can have multiple and independent SSL endpoints, each identified by its server
certificate common name.

## Requirements

To associate an SSL endpoint, you must provide:

- An unencrypted, PEM-encoded (Privacy-Enhanced Mail) certificate file.

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

  The private key file must be _passphraseless_.

## Create a Certificate File and Private Key with the openssl Command

You can create both an unencrypted, PEM-encoded certificate file and a private key using `openssl`.

For example, to create a self-signed certificate and corresponding private key:

1.  Enter:

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

2.  When prompted, enter the certificate information.

    This command creates two `.pem` files:

    example-com-crt.pem example-com-private.pem

    You upload these `.pem` files in Runtime Manager or pass them on the command line when you add
    an SSL endpoint to the load balancer.

Alternatively, you can pass a certificate information configuration file to the `openssl` command
using the `-config` option.

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

\[ 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 = example.com

\[ req\_ext \] subjectAltName = @alt\_names \[alt\_names\] DNS.1 = app1.example.com DNS.2 =
app2.example.com

Run the following command:

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

### Create a Wildcard Certificate

You might want to create a wildcard certificate to support subdomain requests, for example, to
support `example.com` and include `app1.example.com` and `app2.example.com`, as well as any future
subdomain names.

To create a wildcard certificate that maps any subdomain name to `example.com`:

1.  Create a file that includes this configuration:

    \[ req \] default\_bits = 2048 distinguished\_name = req\_distinguished\_name prompt = no \[
    req\_distinguished\_name \] countryName = US stateOrProvinceName = California localityName = San
    Francisco organizationName = MuleSoft commonName = \*.example.com

2.  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

3.  Decrypt the private key using `openssl`:

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

## Configure Certificates for Production

Typically, in a production environment, your certificate is signed by a valid Certificate Authority
(CA). Each SSL endpoint can have multiple CA certificates and CRLs (Certificate Revocation Lists).
You must 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.

## See Also

- [Add Certificates](https://docs.mulesoft.com/cloudhub/lb-cert-upload)

- [Certificate Validation](https://docs.mulesoft.com/cloudhub/lb-cert-validation)

- [Allowlists](https://docs.mulesoft.com/cloudhub/lb-allowlists)

- [Mapping Rules](https://docs.mulesoft.com/cloudhub/lb-mapping-rules)

<!-- document id=fb4cf1d6c9ccc5791cd9324675eebdda4b2325ed4f163e68eed1e9551f10c8ad url=/mulesoft/current/en-us/cloudhub/lb-create-arm.md -->

---
product: CloudHub
---

# Create a Load Balancer with Runtime Manager

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can use Runtime Manager to create a dedicated load balancer (DLB) in your CloudHub environment.

## Prerequisites

Before creating a load balancer, perform the following:

- Ensure that your profile is authorized to perform this action by adding the **CloudHub Network
  Administrator** permission to the profile of the organization where you are creating the load
  balancer.

  Similarly, the administrator role of the same organization also provides the authorization
  required.

- Create an Anypoint Virtual Private Cloud (Anypoint VPC) in the organization where you want to
  create a load balancer.

- Create at least one certificate and private key for your certificate.

## Create a Load Balancer

1.  From Anypoint Platform, click **Runtime Manager**.

2.  Click **Load Balancers** > **Create Load Balancer**.

3.  Enter a name for your load balancer.

    The CloudHub DLB name must be unique across all DLBs defined in Anypoint Platform (by all
    MuleSoft customers). For this reason, you might want to append your organization name to your
    DLB name.

    > [!IMPORTANT] You cannot change the name of a DLB after you create it. To change the name,
    > delete and re-create it using the new name.

    Each dedicated load balancer exposes an external domain `_lb-name_.lb.anypointdns.net` name
    where `_lb-name_` is the name you provide.

    The CloudHub DLB name cannot start with `internal-`.

4.  Select a target Anypoint VPC from the drop-down list.

5.  Specify the amount of time the DLB waits for a response from the Mule application in the
    **Timeout in Seconds** field.

    The default value is 300 seconds.

6.  Add any allowlisted classless inter-domain routing (CIDR) as required.

    The IP addresses you specify here are the only IP addresses that can access the load balancer.
    The default value is `0.0.0.0/0`.

7.  Select the inbound HTTP mode for the load balancer.

    This property specifies the behavior of the load balancer when receiving an HTTP request. Valid
    values are:

    - **Off**

      Causes the load balancer to silently drop the request.

    - **On**

      Accepts the inbound request on the default SSL endpoint using the HTTP protocol.

    - **Redirect**

      Redirects the request to the same URL using the HTTPS protocol.

8.  Specify options:

    - **Enable Static IPs** specifies to use static IPs, which persist when the DLB restarts.

      For more information about static IP addresses, see
      [Static IP Addresses](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer#static-ip-addresses).

    - **Keep URL encoding** specifies that the DLB passes only the `%20` and `%23` characters as is.

      If you deselect this option, the DLB decodes the encoded part of the request URI before
      passing it to the CloudHub worker.

    - **Transport Downstream Protocols** specifies the list of enabled TLS protocols for connections
      from the client to the DLB.

      Use the dropdown to add or remove protocols.

    - **Transport Upstream Protocols** specifies the list of enabled TLS protocols for connections
      from the DLB to the Mule application.

      Use the dropdown to add or remove protocols.

    - **Forward Client Certificate** specifies that the DLB forwards the client certificate to the
      CloudHub worker.

9.  Add a certificate.

    1.  Click **Add certificate**:

    2.  On the **Create Load Balancer | Add certificate** page, select **Choose File** to upload
        both public key and private key files.

    3.  If you want to add a trusted CA certificate, click **Choose File** to upload the file.

        The trusted CA certificate is used to verify client certificates.

    4.  If you want to add URL mapping rules, click the **\>** icon to display the options:

        If you add more than one URL mapping rule, order the rules in the list according to the
        priority in which they should be applied.

        Click **Add New Rule**, and then specify the input path, target app, output path, and
        protocol.

    5.  Click **Save Certificate**.

10. Click **Create Load Balancer**.

## See Also

- [Access Management](https://docs.mulesoft.com/access-management/)

- [Dedicated Load Balancers](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer)

- [Add Certificates to a Dedicated Load Balancer](https://docs.mulesoft.com/cloudhub/lb-cert-upload)

- [Certificate Validation in Dedicated Load Balancers](https://docs.mulesoft.com/cloudhub/lb-cert-validation)

- [Allowlists](https://docs.mulesoft.com/cloudhub/lb-allowlists)

- [Mapping Rules](https://docs.mulesoft.com/cloudhub/lb-mapping-rules)

<!-- document id=fb472ff1a30dacbe8e2c64006ad35c9eb309d837b026e9353f1d7c4c11e1861d url=/mulesoft/current/en-us/cloudhub/lb-create-cli.md -->

---
product: CloudHub
---

# Create a Load Balancer with the Anypoint Platform CLI

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can create a dedicated load balancer (DLB) using the Anypoint Platform CLI.

## Prerequisites

Before you create a load balancer:

- Ensure that you are an administrator in the organization where you are creating the DLB.

- Create an Anypoint Virtual Private Cloud (Anypoint VPC) instance in the organization where you
  want to create a DLB.

- Create at least one certificate and private key for your certificate.

## Create a Load Balancer Using the CLI

Use this command to create a DLB from the CLI:

```linenums
cloudhub load-balancer create myVPC myLB_name certificateName privateKey
```

This command specifies the Anypoint VPC instance _myVPC_ in which to create the DLB and the
_certificateName_ and _privateKey_ that the DLB uses.

> [!IMPORTANT] You cannot change the name of a DLB after you create it. To change the name, delete
> and re-create it using the new name.

The CloudHub DLB name cannot start with `internal-`.

## See Also

- [cloudhub load-balancer create](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-create)

- [cloudhub load-balancer ssl-endpoint add](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-ssl-endpoint-add)

- [cloudhub load-balancer ssl-endpoint set-default](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-ssl-endpoint-set-default)

- [Add Certificates to a Dedicated Load Balancer](https://docs.mulesoft.com/cloudhub/lb-cert-upload)

- [Access Management](https://docs.mulesoft.com/access-management/)

<!-- document id=665e00a8f0c4e602940ba94b110b8b90b0418a2985be1380cd9c18bd3b42de1c url=/mulesoft/current/en-us/cloudhub/lb-create-api.md -->

---
product: CloudHub
---

# Create a Load Balancer with the CloudHub API

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can create a dedicated load balancer (DLB) using the CloudHub API.

## Prerequisites

To create a load balancer using the CloudHub API, ensure that you perform the following:

- Ensure that you are an administrator in the organization where you are creating the load balancer.

- Create an Anypoint Virtual Private Cloud (Anypoint VPC) in the organization where you want to
  create a load balancer.

- Create at least one certificate and private key for your certificate.

## Create a Load Balancer

To create a load balancer using the CloudHub API, use the following endpoints:

- `anypoint.mulesoft.com/cloudhub/api/organizations/_orgid_/loadbalancers`

- `anypoint.mulesoft.com/cloudhub/api/organizations/_orgid_/vpcs`

> [!IMPORTANT] You cannot change the name of a DLB after you create it. To change the name, delete
> and re-create it using the new name.

The CloudHub DLB name cannot start with `internal-`. Starting the DLB name with `internal-` results
in error message: `LB name=internal-dlb-name cannot start with -internal`.

## See Also

- [CloudHub API Create New Load Balancer](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/1.0.13/console/method/%233964/)

- [Access Management](https://docs.mulesoft.com/access-management/)

- [Add Certificates to a Dedicated Load Balancer](https://docs.mulesoft.com/cloudhub/lb-cert-upload)

- [Certificate Validation in Dedicated Load Balancers](https://docs.mulesoft.com/cloudhub/lb-cert-validation)

<!-- document id=b65b070a294a40f8165cd0381a3029c08d28d6b872fd5a3f5010ab35d5a5662c url=/mulesoft/current/en-us/cloudhub/create-vpc-cli.md -->

---
product: CloudHub
---

# Create a VPC with the Anypoint Platform CLI

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This section shows you how to create and configure an Anypoint Virtual Private Cloud (Anypoint VPC)
using the Anypoint Platform CLI.

Log in to your organization and use the `vpc create` command to create the Anypoint VPC:

cloudhub vpc create **(1)** vpc-tutorial **(2)** us-east-1 **(3)** 10.111.0.0/24 **(4)** --default

In this example:

- The Anypoint VPC is called `vpc-tutorial`.

- The Anypoint VPC is bound to the `us-east-1` region.

  > [!NOTE] All Anypoint VPCs need to be associated to a CloudHub region.

- The Anypoint VPC size is `10.111.0.0/24`. In CIDR notation, this grants 256 IP addresses from
  10.111.0.0 to 10.111.0.255.

  - It is not possible to resize an Anypoint VPC once created.

  - Understanding how to size your Anypoint VPC is crucial at this point. If you are not sure how to
    configure this, make sure to follow our [VPC sizing](https://docs.mulesoft.com/cloudhub/virtual-private-cloud#size-your-vpc) guide.

  - The CIDR blocks chosen for the Anypoint VPC should ideally come from a private IP space, and
    should not overlap with any other Anypoint VPC’s CIDR Blocks or any CIDR Blocks in use in your
    corporate network.

- The Anypoint VPC is set as default. This means that all environments in this region that are not
  associated to an Anypoint VPC will be, by default, associated to this Anypoint VPC.

> [!CAUTION] In this example, we are not passing:
>
> - Environment information:  
>   Not setting a specific environment makes that every application deployed to US-EAST is
>   associated to this Anypoint VPC disregarding the environment to which it is being deployed.
>
> - Business group information:  
>   By doing so, we are associating this Anypoint VPC to the main organization.

When the operation succeeds, Anypoint Platform CLI displays the details of the newly created
Anypoint VPC.

```text
┌──────────────────────────────┬───────────────────┐
│ Name                         │ vpc-tutorial      │
├──────────────────────────────┼───────────────────┤
│ Region                       │ us-east-1         │
├──────────────────────────────┼───────────────────┤
│ CIDR Block                   │ 10.111.0.0/24     │
├──────────────────────────────┼───────────────────┤
│ Inherited                    │ No                │
├──────────────────────────────┼───────────────────┤
│ Organization default         │ Yes               │
├──────────────────────────────┼───────────────────┤
│ Special domains              │                   │
├──────────────────────────────┼───────────────────┤
│ DNS Servers                  │                   │
├──────────────────────────────┼───────────────────┤
│ Firewall rules               │                   │
├──────────────────────────────┼───────────────────┤
│ Environments                 │                   │
├──────────────────────────────┼───────────────────┤
│ Business groups              │                   │
├──────────────────────────────┼───────────────────┤
│ Load balancers               │                   │
└──────────────────────────────┴───────────────────┘
```

## Create Firewall Rules

When the Anypoint VPC is created, four firewall rules are set by default. You can review them using
the [vpc firewall-rules describe](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-vpc-firewall-rules-describe) command:

cloudhub vpc firewall-rules describe vpc-tutorial

This command returns:

```text
┌───────┬────────────────────┬──────────┬────────────┬──────────┐
│ Index │ CIDR Block         │ Protocol │ From port  │ To port  │
├───────┼────────────────────┼──────────┼────────────┼──────────┤
│ 0     │ 10.111.0.0/24      │ TCP      │ 8091       │ 8092     │
├───────┼────────────────────┼──────────┼────────────┼──────────┤
│ 1     │ 0.0.0.0/0          │ TCP      │ 8081       │ 8082     │
└───────┴────────────────────┴──────────┴────────────┴──────────┘
```

> [!TIP] Rule `0` allows inbound connections from your local Anypoint VPC from ports 8091 and 8092,
> while rule `1` allows traffic from any host to reach your workers through ports 8081 and 8082.

You can use the [`vpc firewall-rules remove`](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-vpc-firewall-rules-remove)
command to remove any of the default rules or you can add new ones using the
[`vpc firewall-rules add`](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-vpc-firewall-rules-add) command.

Assume you want to enable TCP traffic through port 8090 inside your Anypoint VPC. You need to run
the following:

cloudhub vpc firewall-rules add **(1)** vpc-tutorial **(2)** 10.111.0.0/24 **(3)** tcp **(4)** 8090

1.  Set `vpc-tutorial` as the target Anypoint VPC for this new firewall rule.

2.  Set the IP range to allow only hosts from inside your Anypoint VPC by setting `10.111.0.0/24`.  
    In CIDR notation, this allows the range `10.111.0.0` to `10.111.0.255`.

3.  Set the allowlisted protocol to `tcp`

4.  Allow the port number `8090`

When you create a new firewall rule, the Anypoint Platform CLI shows you a success message:

VPC firewall modified successfully

## Update an Existing Anypoint VPC

Although it is not possible to update certain values from your Anypoint VPC through the Anypoint
Platform CLI, you can use the
[CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)
to programmatically manage and update your Anypoint VPC:

1.  Log into the CloudHub services passing your credentials through the
    `https://anypoint.mulesoft.com/accounts/login` endpoint.

2.  Use the `organizations/{orgid}/vpcs/{vpcId}` endpoint to update your Anypoint VPC.

> [!NOTE] You can use the
> [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)
> to understand how to interact with the API’s resources.

For example, to update the environments of your Anypoint VPC you need to send a `PUT` request to the
`anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/vpcs/{vpcId}` endpoint with a JSON
payload:

> [!TIP] You can query your `{orgid}` using the
> [account business-group describe](https://docs.mulesoft.com/anypoint-cli/latest/anypoint-platform-cli-commands#account-business-group-list)
> command.
>
> Your `{vpcId}` value is listed by running a
> [cloudhub vpc describe-json](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-vpc-describe-json) command.

```json
{
  "associatedEnvironments": ["<EnvironmentId>"]
}
```

> [!NOTE] `<EnvironmentId>` needs to be replaced by the Id of the environment to which you want to
> associate this Anypoint VPC.  
> You can get the Ids for your environments running a
> [account environment list](https://docs.mulesoft.com/anypoint-cli/latest/anypoint-platform-cli-commands#account-environment-list)
> command.

## See Also

- [CloudHub Load Balancers](https://docs.mulesoft.com/cloudhub/dedicated-load-balancer-tutorial)

- [Anypoint Platform CLI](https://docs.mulesoft.com/anypoint-cli/latest/)

<!-- document id=1924e054b64b2789cd1ba931d3ee0ce5ba23ede347b340eff285da73b2a9182f url=/mulesoft/current/en-us/cloudhub/vpn-create-arm.md -->

---
product: CloudHub
---

# Create an Anypoint VPN Connection

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can create an Anypoint VPN connection using Runtime Manager.

## Prerequisites

Before you can create an Anypoint VPN:

- You must create an Anypoint Virtual Private Cloud (Anypoint VPC).

  See [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud) for more information.

  One Anypoint VPC can accommodate up to 10 Anypoint VPNs.

- You must have either the CloudHub Network Administrator or the CloudHub Network Viewer user
  permission to access the VPN page.

- Your default environment (defined in your profile) must have Read Application permissions.

  ![vpn permissions](/mulesoft/current/en-us/cloudhub/_images/vpn-permissions.png)

  See
  [Grant Permissions and Roles to Users](https://docs.mulesoft.com/access-management/users#grant-permissions-and-roles-to-users).

The VPNs page is visible to Anypoint organizations that have VPN entitlements.

### Checklist for Creating an Anypoint VPN

When you create or configure an Anypoint VPN, you must provide the following information:

Remote IP address

The public IP address of your VPN endpoint. This must be a single, static IP address.

Static Routes (CIDR)

The subnets in your network to make accessible through the VPN. This information is required only if
you are using static routing.

Remote and Local ASN

The Autonomous System Number specifies the collection of routing prefixes. You must configure both a
remote and local ASN. This is required only if you are using dynamic routing.

Pre-shared Key (PSK)

The shared secret for the VPN tunnels. These values are auto-generated if you select **Automatic
Tunnel Configuration**.

Point-to-Point CIDR

Private IP range for the VPN tunnel interfaces. These values are auto-generated if you select
**Automatic Tunnel Configuration**.

## Create an Anypoint VPN

To create an Anypoint VPN:

1.  Sign into Anypoint Platform and select **Runtime Manager**.

2.  Select the environment where you want to create an Anypoint VPN.

3.  From the menu on the left, click **VPNs**, and then click **Create VPN**.

4.  Enter or select the following information for your Anypoint VPN:

    **Name**

    Enter a name for your Anypoint VPN.

    **VPC**

    From the list, select the Virtual Private Cloud for the Anypoint VPN connection.

    **Remote IP Address**

    Enter the public IP address of your VPN endpoint.

5.  Select the routing type to use.

    You can select either **BGP** (dynamic) or **Static**. Choose the Border Gateway Protocol (BGP)
    type if your device supports it.

    **To use dynamic routing**:

    1.  Select **BGP**.

    2.  Define the remote ASN.

        Enter the ASN corresponding to your backend. You can use an existing ASN assigned to your
        network or a private ASN (64512–65534) that is not already assigned to your network. The
        default value is `65001`.

    3.  Define the local ASN.

        Assign an ASN for the MuleSoft side. Use a private ASN (64512–65534) that is not already
        assigned to your network. The default value is `64512`.

    **To use static routing**:

    1.  Select **Static**.

    2.  In the **CIDR** field, enter a subnet to make accessible through the VPN, for example,
        `10.0.0.0/8`.

    3.  If you want to add additional subnets, click **Add New Rule**, and repeat the previous step.

        A maximum of 95 route table entries is allowed per VPC, regardless of the number of VPN
        connections. To avoid exceeding the limit, consolidate networks to the fewest number
        possible.

6.  Select the **Tunnel Configuration** type.

    You can select either **Automatic** or **Custom**. In most scenarios, **Automatic** is
    sufficient. The steps differ depending on the selected tunnel type.

    **To use Automatic tunnel configuration**:

    1.  Select **Automatic**.

        No other inputs are required. This option automatically configures the tunnel settings for
        your Anypoint VPN.

        The tunnel settings are visible after VPN creation.

    **To use Custom tunnel configuration**:

    1.  Select **Custom**.

    2.  In the **PSK** field for each tunnel, enter a value between 8-64 characters that does not
        begin with zero (0).

        Use only alphanumeric characters, periods (.), and underscores (\_).

    3.  In the **Point-to-Point CIDR** field for each tunnel, enter the IP address range for the
        internal address of the VPN tunnel.

        You can specify a size /30 CIDR block from the `169.254.0.0/16` range. The CIDR block must
        be unique across all VPN connections.

        You cannot use the following CIDR blocks:

        169.254.0.0/30 169.254.1.0/30 169.254.2.0/30 169.254.3.0/30 169.254.4.0/30 169.254.5.0/30
        169.254.169.252/30

    > [!NOTE] You cannot modify tunnel settings after you create the Anypoint VPN connection. To
    > change the settings for an existing connection, delete the Anypoint VPN connection and create
    > a new one.

7.  Click **Create VPN**.

    Initially, the status of the VPN is `PENDING`. This is the expected status while the
    infrastructure is created. After the status changes to `AVAILABLE`, continue with the next
    steps.

    For more information see [VPN and Tunnel Status](#vpn-and-tunnel-status).

8.  Download the configuration file from your Anypoint VPN:

    1.  In Runtime Manager, click the name of the Anypoint VPN that you just created.

    2.  Click **Get VPN Config**.

    3.  In the **Download VPN Config** window, select a Vendor, Platform, and Software version that
        corresponds to your VPN endpoint device.

        If your device type is not listed, select **generic**.

    4.  Click **View Config** and then click the **Copy** button in the top right corner.

    5.  Paste the configuration to a text file.

        All configuration files represent the minimum requirement of IKEv1, AES128, SHA1, and DH
        Group 2. You can modify the configuration for your VPN endpoint to take advantage of the
        other supported IPsec settings. See [IPsec settings](https://docs.mulesoft.com/cloudhub/vpn-about#ipsec-settings).

9.  Configure your VPN endpoint:

    1.  Share the VPN configuration file (from Step 8) with your VPN endpoint administrator.

    2.  Based on the configuration of your VPN endpoint, you might need to perform additional
        configuration steps.

        See [VPN requirements](https://docs.mulesoft.com/cloudhub/vpn-about#vpn_requirements) for more information.

        Refer to the documentation for your specific VPN endpoint to ensure that the components of
        your network are configured correctly.

        Configure both tunnels on your VPN endpoint to avoid unexpected behavior.

## VPN and Tunnel Status

The new VPN connection you created appears in the list of VPNs. Initially, the **Status** column
displays `PENDING` and both VPN tunnels display `DOWN` while the infrastructure gets created.

Depending on your configuration, tunnels might report a status of `DOWN` during normal operations.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Status</th><th>Tunnel 1/2</th><th>Description</th></tr></thead><tbody><tr><td><p><code>Pending</code></p></td><td><p><code>DOWN\DOWN</code></p></td><td><p>The VPN connection is recently created, and actions are pending in the background. You might see this status for 10-15 minutes after creating a VPN.</p></td></tr><tr><td><p><code>Available</code></p></td><td><p><code>DOWN\DOWN</code></p></td><td><p>The VPN connection is created, but the remote side is not configured or is not sending traffic.</p></td></tr><tr><td><p><code>Available</code></p></td><td><p><code>Up\Up</code> or <code>Up\Down</code></p></td><td><p>The VPN connection is created, and the remote side established the connection successfully. Tunnels operate in active/active or active/passive mode, depending on the routing configuration and your VPN device type.</p></td></tr><tr><td><p><code>Failed</code></p></td><td><p><code>DOWN\DOWN</code></p></td><td><p>The VPN connection is not created. Delete the VPN and try again. If this failure recurs, contact MuleSoft Support.</p></td></tr></tbody></table>

## See Also

- [Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-about)

- [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [Anypoint VPN Knowledge Articles](https://help.salesforce.com/s/articleView?id=001117281&type=1)

<!-- document id=8f39ea27d3040df69b473bfdd34c57e374351c6729f02e3dec2f37ac3af2747b url=/mulesoft/current/en-us/cloudhub/vpc-tutorial.md -->

---
product: CloudHub
---

# Create and Update a VPC with Runtime Manager

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Before you can create an Anypoint VPC, your organization must:

- Purchase an Anypoint VPC offering

- Have the necessary permissions on your account to create and administrate a Anypoint VPC

## Create the Anypoint VPC

1.  Sign into your Anypoint Platform account as a user with the **Organization Administrators**
    role.

2.  Under **Management Center**, click **Runtime Manager**.

3.  In the left navigation, click **VPCs**.

4.  Click **Create VPC**, and enter the following information to define and configure the Anypoint
    VPC:

    - **Name**: The name to identify your Anypoint VPC.  
      The name must:

      - Be unique within the organization

      - Between 3 - 42 characters long

      - Contain only lowercase letters, numbers, and dashes

        > [!IMPORTANT] You cannot change the name of a VPC after you create it. To change the name,
        > delete and recreate the VPC.

    - **Region**: The region to which the Anypoint VPC is bound.

      > [!NOTE] All Anypoint VPCs must be associated with a CloudHub region.

    - **CIDR Block**: The size of the Anypoint VPC in Classless Inter-Domain Routing (**CIDR**)
      notation.  
      For example, if you set it to 10.111.0.0/24, the Anypoint VPC is granted 256 IP addresses from
      10.111.0.0 to 10.111.0.255.  
      Ideally, the CIDR Blocks you choose for the Anypoint VPC come from a private IP space, and
      should not overlap with any other Anypoint VPC’s CIDR Blocks, or any CIDR Blocks in use in
      your corporate network.

      > [!CAUTION] This setting is configurable only during this initial creation of an Anypoint
      > VPC. Once the Anypoint VPC instance is created, you cannot resize it or edit your selected
      > CIDR block.  
      > Make sure you thoroughly understand how to properly size the Anypoint VPC for your needs
      > before configuring this parameter. If you are not sure of how to configure this setting,
      > follow the [Anypoint VPC sizing](https://docs.mulesoft.com/cloudhub/vpc-provisioning-concept#faq-how-to-size-my-vpc) guide.

    - **Environments**: Optionally, select an environment to which to bind Anypoint VPC.  
      If you don’t select an environment, all applications deployed to the selected region are
      associated with this Anypoint VPC.

      Don’t associate Anypoint VPC with a design environment. You can deploy apps to the design
      environment only from Design Center, not from Runtime Manager.

      > [!IMPORTANT] There is a cache timeframe between services that prevents rate limiting errors
      > with different time configuration across Anypoint control planes. If you create an
      > environment in Access Management and attempt to immediately use it to create or edit a VPC
      > in Runtime Manager, you might experience a delay to see the newly created environment in the
      > VPCs **Environments** dropdown.

> [!NOTE] If a new or updated VPC (VPC A) is associated with an environment already linked to
> another VPC (VPC B) in the same region, VPC B loses the environment, and it is automatically
> attached to VPC A. As a result, any applications in that environment are deployed to VPC A when
> the VPC is updated or restarted.

- **Set as default VPC**: Select this option to set the Anypoint VPC as the default for the region
  you set.  
  This means that all environments in this region not associated with an Anypoint VPC will be, by
  default, associated with this Anypoint VPC.

- **Business Groups**: Optionally, bind the Anypoint VPC with a business group.  
  If you don’t select a business group, the Anypoint VPC is associated with the main organization.
  You can change this later in the Anypoint VPC management settings.

  ![create vpc](/mulesoft/current/en-us/cloudhub/_images/create-vpc.png)

  1.  Click **Firewall Rules** to expand the fields and
      [configure firewall rules](https://docs.mulesoft.com/cloudhub/vpc-firewall-rules-concept).  
      By default, all inbound traffic is blocked, and you need to configure firewall rules to allow
      traffic to your worker. You can configure these rules at a later time.  
      The UI is pre-filled with suggestions of the most commonly used firewall rules.  
      The example below shows a firewall rule with type `http.private.port` from `Anywhere`. The
      port range is set to `8091` automatically.

      ![vpc and load balancer creation 97c25](/mulesoft/current/en-us/cloudhub/_images/vpc-and-load-balancer-creation-97c25.png)

      This means that only connections through port `8091` are allowed inside the Anypoint VPC and
      that your worker will listen to all interfaces coming through port `8091`.  
      Setting this firewall rule allows a
      [dedicated load balancer](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer) to communicate to your workers
      using its default configurations.

      > [!NOTE] Additionally, to properly receive requests from the load balancer, all applications
      > deployed to the Anypoint VPC must be listening on port `8091`.

  2.  Optionally, you can click the **Internal DNS** option to
      [set up internal DNS servers](https://docs.mulesoft.com/cloudhub/resolve-private-domains-vpc-task) to resolve your private host
      names.

      ![vpc tutorial 31341](/mulesoft/current/en-us/cloudhub/_images/vpc-tutorial-31341.png)

      You can do this when you initially create the Anypoint VPC, or you can configure the internal
      DNS later.

  3.  Click **Create VPC**.

## Connect to your Anypoint VPC

Configuration steps differ based on the
[VPC connectivity methods](https://docs.mulesoft.com/cloudhub/virtual-private-cloud#vpc-connectivity-methods-concept) chosen. Follow
the instructions in
[Request Anypoint VPC Connectivity to Your Network](https://docs.mulesoft.com/cloudhub/to-request-vpc-connectivity).

## Update an Existing Anypoint VPC

![vpc tutorial c5a66](/mulesoft/current/en-us/cloudhub/_images/vpc-tutorial-c5a66.png)

1.  Find your Anypoint VPC in the list of existing Anypoint VPCs in the UI, and select it.

2.  You can update:

    1.  **Environments**  
        You can select one or more specific environment from the drop down menu.

        ![vpc tutorial 6dea0](/mulesoft/current/en-us/cloudhub/_images/vpc-tutorial-6dea0.png)

    2.  **Business Groups**  
        You can select one or more business groups from the drop down menu.

        ![vpc tutorial 981cc](/mulesoft/current/en-us/cloudhub/_images/vpc-tutorial-981cc.png)

    3.  **Firewall Rules**  
        You can edit existing [firewall rules](https://docs.mulesoft.com/cloudhub/vpc-firewall-rules-concept), or add new ones.

        ![vpc tutorial fa890](/mulesoft/current/en-us/cloudhub/_images/vpc-tutorial-fa890.png)

    4.  **Internal DNS**  
        You can edit existing [internal DNS configurations](https://docs.mulesoft.com/cloudhub/resolve-private-domains-vpc-task), or
        add new ones.

        ![vpc tutorial 0b7b2](/mulesoft/current/en-us/cloudhub/_images/vpc-tutorial-0b7b2.png)

        Set your public DNS IP address and press `enter`, or click the blue check mark.

        ![vpc tutorial df177](/mulesoft/current/en-us/cloudhub/_images/vpc-tutorial-df177.png)

        Add the private domains that need to be resolved using your DNS server and press `enter`, or
        click the blue check mark.

3.  When you finish making your changes, click **Apply Changes**.

## See Also

- [VPC Firewall Rules](https://docs.mulesoft.com/cloudhub/vpc-firewall-rules-concept)

- [CloudHub Load Balancers](https://docs.mulesoft.com/cloudhub/dedicated-load-balancer-tutorial)

- [FAQ: Where to Place an Anypoint VPC inside My Organization](https://docs.mulesoft.com/cloudhub/vpc-provisioning-concept#faq-where-to-place-an-anypoint-vpc-inside-my-organization)

- [Configure Private Domains](https://docs.mulesoft.com/cloudhub/resolve-private-domains-vpc-task)

<!-- document id=62a7765a8986aecd480952ddf8d970f9384803ab201e2e03d27815cd80e9c871 url=/mulesoft/current/en-us/cloudhub/custom-application-alerts.md -->

---
product: CloudHub
---

# Custom Application Alerts and Notifications

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

CloudHub enables you to display notifications from your app in the Runtime Manager console. You can
configure CloudHub to email these notifications as _custom alerts_ to specific people so that they
can fix the underlying problems.

> [!NOTE] Custom alerts and notifications are available only for apps deployed to CloudHub workers.
> They are not available for apps deployed to on-premises servers. See
> [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies) for more information about CloudHub
> features.

## Prerequisites

- Deploy your application to CloudHub.

  See [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- For Anypoint Studio 6.x and earlier, enable Maven support for your Mule project.

  All projects in Studio 7.x and later support Maven by default.

## Custom Application Alerts

Alerts enable you to send emails based on your application’s notifications. You can create standard
alerts in Runtime Manager for servers and applications deployed to either CloudHub or on-premises
servers. See [Alerts](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager).

You can also create _custom alerts_ for applications deployed to CloudHub.

To create custom application alerts:

1.  Add Anypoint Connector for CloudHub (CloudHub Connector) to flows in your Mule app in Anypoint
    Studio and configure the notification.

    CloudHub Connector is available for Mule 4 applications.

2.  Deploy the app to CloudHub.

3.  Configure the custom application alerts in Runtime Manager.

### Configure the Notification in CloudHub Connector

In Studio, add and configure CloudHub Connector in your Mule project:

1.  In the **Mule Palette** view, click **CloudHub** and then drag the **Create Notification**
    operation to the application flow for which you want to trigger an alert in the canvas.

2.  In the canvas, click **Create Notification**.

3.  In the **Create Notification** properties window, click the green plus icon (**+**) to the right
    of the **Connector configuration** field.

4.  In the **Global Element Properties** window, configure authentication to Anypoint Platform and
    click **OK**:

    ![Username field in the Global Element Properties window](/mulesoft/current/en-us/cloudhub/_images/alerts-custom-ch-connector.png)

    Figure 1. The arrow shows the **Username** field in the **Global Element Properties** window.

    The connector can use basic authentication or inherited token authentication.

5.  In the **Create Notification** properties window, enter the CloudHub app name in the **Domain**
    field and the notification in the **Message** field:

    ![Message field in the Create Notification properties window](/mulesoft/current/en-us/cloudhub/_images/alerts-custom-ch-connector-notification.png)

    Figure 2. The arrow shows the **Message** field in the **Create Notification** properties
    window.

    For more information about creating a notification with CloudHub Connector, see
    [Creating a Notification](https://docs.mulesoft.com/cloudhub-connector/latest/#creating-notifications).

6.  Deploy the app to CloudHub.

### Create a Custom Alert

In Runtime Manager, bind the custom notification to an alert:

1.  Click **Alerts** in the menu on the left.

2.  Click the blue plus icon (**+**) to create a new alert.

3.  In the **Create an Alert** page, configure your custom alert and click **Submit**:

    ![Applications field in the Create an Alert window](/mulesoft/current/en-us/cloudhub/_images/alerts-custom-rtm-create.png)

    Figure 3. The arrow shows the **Applications** field in the **Create an Alert** window.

    Name

    Enter a meaningful name for the custom alert.

    Severity level

    Select the severity level to apply to the alert:

    - **Critical**

    - **Warning**

    - **Info**

    Source

    Select **Applications** for the alert source.

    Application type

    Select **CloudHub Applications**.

    Applications

    Select the application that contains the flow that you configured to trigger a custom alert.

    Condition

    Select **Custom application notification**.

    - Select the priority from the **Priority** menu, or leave the priority as **Any** to send
      notifications regardless of priority.

    - In **Contains**, enter the string to use to trigger a notification.

      This string must match a string in the **Message** field that you configured in CloudHub
      Connector.

    Subject

    Enter the subject line to include in the notification email.

    Message

    Enter the custom message to include in the notification.

    Recipients

    Enter the email addresses for notification recipients.

    You can use variables in the alert **Subject** and **Message** fields. For information about
    using variables in alerts, see
    [Alert Variables](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager#alert-variables).

When you trigger the alert, the specified recipients receive an email with the custom message you
added to the app.

## Notifications

_Notifications_ give you visibility into business-related events inside your application. For
example, you can create notifications that appear when:

- Your application is unable to connect to a remote service.

- An error that requires human intervention occurs, such as a problem with data mapping.

- You want to create a summary of what happened in your application, such as the number of orders
  processed.

> [!NOTE] CloudHub stores up to a maximum of 1000 notifications per application. If the number of
> notifications exceeds the maximum, CloudHub deletes the oldest notification. Each notification can
> contain up to 10,000 characters.

### Trigger a Notification

To trigger a notification for an app deployed to CloudHub:

1.  Open the application URL and path, for example:

    `http://myApp.us-w1.cloudhub.io/store`

    The page displays an error message and sends a new notification to the Runtime Manager console.

2.  In the Runtime Manager **Applications** page, click the red bell icon in the upper-right to
    display the notification.

    ![Error in the notifications dropdown](/mulesoft/current/en-us/cloudhub/_images/alerts-custom-rtm-notification-error.png)

    Figure 4. The arrow shows the error in the notifications dropdown.

If the notification is sent after an exception, it includes `exception.message` and
`exception.stacktrace` as custom properties of the notification, accessible from the Runtime Manager
console.

### Send an Error Notification

You can use the CloudHub Connector inside an `<error-handler>` component to send notifications when
errors happen.

For example, use the `<on-error-propagate>` component to send the error message and stop processing
the flow:

```xml
<flow name="myTestFlow" >
...
    <error-handler >
        <on-error-propagate enableNotifications="true" logException="true" doc:name="On Error Propagate" type="ANY">
            <cloudhub:create-notification doc:name="Create Notification" config-ref="CloudHub_Config" domain="bad-app-name" priority="WARN">
                <cloudhub:message ><![CDATA[#[error.description]]]></cloudhub:message>
            </cloudhub:create-notification>
        </on-error-propagate>
    </error-handler>
...
</flow>
```

For information about the On-Error components, see
[Using On-Error Components to Handle Messaging Errors](https://docs.mulesoft.com/mule-runtime/latest/error-handling#on_error_continue).

## See Also

- [Alerts](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager)

- [Add the Connector to Your Mule Project](https://docs.mulesoft.com/connectors/introduction/intro-config-use-studio#install)

- [CloudHub Connector](https://www.mulesoft.com/exchange/com.mulesoft.connectors/mule-cloudhub-connector/)
  on Exchange

- [Create the CloudHub Configuration](https://docs.mulesoft.com/cloudhub-connector/latest/#create-the-cloudhub-configuration)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [Introduction to Mule 4: Error Handlers](https://docs.mulesoft.com/mule-runtime/latest/mule-error-concept)

<!-- document id=832b7ee2405bc3c39c25b52dd2093854623fae5dd553aeb934428e6fff6c6e5d url=/mulesoft/current/en-us/cloudhub/lb-allowlists.md -->

---
product: CloudHub
---

# Dedicated Load Balancer Allowlists

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

If you want to allow IP addresses access to your dedicated load balancer (DLB), you must add those
IP addresses, in CIDR notation, to the allowlist of the DLB.

> [!NOTE] The allowlist works for inbound connections at the load-balancer level only, not at the CN
> certificate level.

You can either add the allowed IP addresses when you create the DLB or add them to an existing DLB
using either Runtime Manager or the command-line interface.

## DLB Allowlist Entry Limits

The maximum number of IP address entries that you can add to the DLB allowlist depends on the
inbound HTTP mode setting in the DLB configuration, which specifies the behavior of the DLB when
receiving an HTTP request.

<table><colgroup><col> <col></colgroup><thead><tr><th>Inbound HTTP Mode</th><th>Maximum Allowlist Entries</th></tr></thead><tbody><tr><td><p><strong>Off</strong></p></td><td><div><div><p>240</p></div></div></td></tr><tr><td><p><strong>On</strong></p></td><td><div><div><p>120</p></div></div></td></tr><tr><td><p><strong>Redirect</strong></p></td><td><div><div><p>120</p></div></div></td></tr></tbody></table>

> [!NOTE] If the number of entries in the DLB allowlist exceeds 120, you can’t set HTTP mode to
> **On**.

## Add an IP Address to the Allowlist of an Existing DLB

To add an IP address to the allowlist of a DLB using Runtime Manager:

1.  From Anypoint Platform, click **Runtime Manager**.

2.  Click **Load Balancers** and then click the load balancer name.

3.  In the **Allowlisted CIDRs** tab, click **Add New CIDR**:

    ![\*Add New CIDR\* option in the load balancer settings page](/mulesoft/current/en-us/cloudhub/_images/lb-allowlist-update.png)

    Figure 1. The arrow shows the **Add New CIDR** option in the **Allowlisted CIDRs** tab.

4.  Enter the IP address in valid CIDR format (for example, `10.2.0.0/16`).

5.  Click **Add To List**.

6.  If you want to delete a CIDR, hover over the **…​** icon to display the trash can icon.

7.  Click **Apply Changes**.

To add a range of IP addresses to the allowlist for a DLB using the CLI:

cloudhub load-balancer allowlist add myLB\_name myCIDRblock

The IP addresses must be in valid CIDR format (for example, `10.2.0.0/16`).

If you want to remove IP addresses from the allowlist:

cloudhub load-balancer allowlist remove myLB\_name myCIDRblock

## See Also

- [cloudhub load-balancer allowlist add](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-allowlist-add)

- [cloudhub load-balancer allowlist remove](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-allowlist-remove)

- [IPv4 CIDR blocks](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#IPv4_CIDR_blocks)

- [Create a Load Balancer with Runtime Manager](https://docs.mulesoft.com/cloudhub/)

- [Create a Load Balancer with the Anypoint Platform CLI](https://docs.mulesoft.com/cloudhub/lb-create-cli)

- [Internal Worker DNS vs Internal DLB DNS in CloudHub](https://help.salesforce.com/s/articleView?id=001116315&type=1)

<!-- document id=33639ca5ecb1d6bdafc9526af78aabf3f00e40c3af8afe0bc9a3d501c101db06 url=/mulesoft/current/en-us/cloudhub/lb-architecture.md -->

---
product: CloudHub
---

# Dedicated Load Balancer Architecture

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

A CloudHub dedicated load balancer (DLB) enables you to route external HTTP and HTTPS traffic to
multiple Mule applications deployed into CloudHub workers inside a Virtual Private Cloud (VPC). Each
CloudHub DLB is assigned to an Anypoint VPC, and that Anypoint VPC runs within a particular service
region. The DLB routes both external and VPC-internal traffic to CloudHub workers deployed into that
Anypoint VPC.

The public CloudHub load balancer already redirects these requests, where `_myApp_` is the name of
the Mule application deployment to CloudHub:

- HTTP requests to `http://myApp.cloudhub.io` redirects to `mule-worker-myApp.cloudhub.io:8081`

- HTTPS traffic to `https://myApp.cloudhub.io:443` redirects to
  `https://mule-worker-myApp.cloudhub.io:8082`

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 [`cloudhub load-balancer mappings add`](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-mappings-add)
command.

## Routing External Requests to the Dedicated Load Balancer

A CloudHub dedicated load balancer provides an alternative domain name to route HTTP requests to
Mule applications listening on port 8091 and HTTPS requests to Mule applications listening on
port 8092. You can also use mapping rules to rename requests to the CloudHub DLB to a different Mule
application domain name.

The CloudHub DLB exposes an external domain name that resolves to two public IP addresses which are
accessible from outside your CloudHub Anypoint VPC network. `[lb-name]` is the name you gave the
load balancer when you created it:

- `[lb-name].lb.anypointdns.net`

- `[lb-name].lb-prod-eu-rt.anypointdns.net` (EU control plane)

- `[lb-name].lb-gprod-rt.anypointdns.net` (Government Cloud control plane)

## Renaming External Mule Application URLs Through a Dedicated Load Balancer

You can create a mapping rule to rename the Mule application, so it can be accessed through a
different domain name.

For example, suppose you deploy a Mule application named myApp-myCompany-prod.cloudhub.io. CloudHub
domain names must be globally unique among every other MuleSoft customer and Mule application. A DLB
helps you hide this naming complexity within your corporate DNS domain name.

You can set a CNAME record in your corporate DNS nameserver to mask the `lb-name.lb.anypointdns.net`
domain to your company’s "vanity" domain.

For example, suppose your company owns the DNS domain `example.com`. You can create a CNAME record
to route requests to `myapp.example.com` to a Cloudhub application named `myapp` using the
`{subdomain}` pattern. This hides the complexity of the CloudHub domain name in the `cloudhub.io`
domain.

## Routing Internal Requests to the Dedicated Load Balancer

The CloudHub dedicated load balancer has an internal domain name that is used by applications and
clients within the Anypoint VPC.

The internal domain uses the following naming convention (`[lb-name]` is the name you gave the load
balancer when you created it):

internal-\[lb-name\].lb.anypointdns.net

Each DLB has DNS A records `[lb-name].lb.anypointdns.net` that resolve to the public IP addresses of
the instances. The number of public IP addresses correlates to the number of workers. Through your
DNS provider, you can add a CNAME record pointing to this A record and use your domain names to
access it.

If you want your load balancer to manage all connections to your application but do not want your
default domain name for your application publicly exposed, then each application must listen on HTTP
port 8091 or 8092. Alternatively, you can create a custom mapping policy to redirect outside
requests from your load balancer to your specific application.

The following graphic shows how a load balancer interacts between a VPC and Anypoint Platform.

![Load Balancer](/mulesoft/current/en-us/cloudhub/_images/pxty-lb.png)

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, you must set `upstreamProtocol` to HTTPS when creating the mapping list using the
`load-balancer mappings add` command.

The internal HTTP mode lets you configure how HTTP requests are managed. They are either silently
ignored, mapped HTTPS on the default SSL endpoint, or the URL is mapped straight through to the
corresponding HTTPS URL.

## DLB URL Encoding

You can configure the DLB to pass request URIs unchanged or decoded:

- If you select **Keep URL encoding**, the DLB passes only the %20 and %23 characters as is.

- If you deselect **Keep URL encoding**, the DLB decodes the encoded part of the request URI before
  passing it to the CloudHub worker.

## URL Path Normalization

CloudHub dedicated load balancers treat consecutive path separators as a single separator. For
example, when a request includes `orders//details` in the path, the DLB normalizes it to
`orders/details` before forwarding it to the Mule worker.

This behavior aligns with URL handling best practices and is standard across most web systems. If
your application requires preserving consecutive path separators (for example, APIs with optional
URI parameters), send requests directly to the Mule worker using the
`mule-worker-_myApp_._region_.cloudhub.io` hostname.

## See Also

- [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [CloudHub](https://docs.mulesoft.com/cloudhub/)

- [Mapping Rules](https://docs.mulesoft.com/cloudhub/lb-mapping-rules)

<!-- document id=2c6065b74d8a976f3ee94fc91344cf0fe8be0e4f2e3c2bc23d6fd4cb897749c9 url=/mulesoft/current/en-us/cloudhub/lb-mapping-rules.md -->

---
product: CloudHub
---

# Dedicated Load Balancer Mapping Rules

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The CloudHub dedicated load balancer (DLB) routes requests from clients to Mule apps deployed within
the VPC. _Mapping rules_ enable you to forward requests received by the DLB (using the HTTP Host
header to identify the matching rule) to a different Mule application name and domain.

You can either define mapping rules when you create the DLB, or you can define and add them to an
existing DLB using Runtime Manager, the command-line interface (CLI), or the CloudHub API.

When you create a simple matching rule, one input address matches the defined output: the endpoint
of an application. Instead of using literal matchings, you can use a pattern to match a variable,
such as input text to an endpoint.

The order of the rules determines their priority. The first rule in the list that matches is
applied.

> [!NOTE] If you don’t define any mapping rules, the DLB creates and uses a default mapping rule.
> You can change the default mapping rule later.

## Create Mapping Rules

Mapping rules are attributes of the load balancer’s SSL endpoint, which is identified by the
certificate Common Name (CN).

The certificate is associated when you create mapping rules:

- Runtime Manager

  You define mapping rules within a certificate definition.

- CLI or CloudHub API

  You must specify a certificate CN.

  If you omit the certificate name, the mappings are added to the default endpoint.

### Create Mapping Rules in Runtime Manager

To create mapping rules in an SSL endpoint for a DLB in Runtime Manager:

1.  From Anypoint Platform, select **Runtime Manager**.

2.  Select **Load Balancers** in the left menu.

3.  Click a load balancer name, and then click a certificate name.

4.  In the **URL Mapping Rules** section, click **Add New Rule**:

    ![the \*Add New Rule\* icon and the fields required to create a mapping rule](/mulesoft/current/en-us/cloudhub/_images/cloudhub-dlb-mapping-rules.png)

    Figure 1. The screenshot shows (**1**) the **Add New Rule** icon and (**2**) the fields required
    to create a mapping rule.

5.  Complete the fields:

    - **Input Path** (`inputUri`)

      The URI that the client requests: for example, `/{app}/`

      The input URI is appended to the host header of the load balancer.

    - **Target App** (`appName`)

      The name of the CloudHub application that processes the request: for example, `{app}-example`

    - **Output Path** (`appURI`)

      The URI string to pass to the app: for example, `/`

      The output path cannot contain patterns.

    - **Protocol** (`upstreamProtocol`)

      The protocol on which the application listens:

      - `http` (port 8091)

      - `https` (port 8092)

      - `ws` WebSockets (port 8091)

      - `wss` WebSockets over SSL/TLS (8092)

      By default, the load balancer listens to external requests on HTTPS and communicates
      internally with your worker over HTTP. If you configured your Mule application within the VPC
      to listen on HTTPS, set **Protocol** to `https` when you create the mapping rule list.

The DLB uses the values in the fields and the client request to generate the path that is sent to
the target app.

For example, if the client request is `<domain.com>/hello/world/` and the mapping rules fields are
set to the following:

- **Input Path**: `/hello/`

- **Target App**: `myApp1`

- **Output Path**: `/test/`

The DLB uses the value of the output path (`/test/`), removes the section that matches the input
path from the client request (`/hello/`), and appends the rest (`/world/`) to the client request.
The DLB then sends the resulting path (`/test/world/`) to the target app (`myApp1`).

You can use either patterns or literal strings to define the input path. For the output path, you
can use only literal strings.

### Create a Mapping Rule Using the CLI

To create a mapping rule in a DLB using the CLI:

```text
cloudhub load-balancer mappings add [options] <name> <index> <inputUri> <appName> <appUri> [certificateName]
```

See [cloudhub load-balancer mappings add](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-mappings-add).

### Create a Mapping Rule Using the CloudHub API

To create a mapping rule in a DLB using the CloudHub API:

```text
anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers/{loadbalancerId}
```

See
[CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/minor/1.0/pages/home/).

## Use Patterns in Mapping Rules

A _pattern_ is a string that defines a template for matching an input text. The value in curly
brackets (`{ }`) is treated as a variable:

- Variable **names** can contain only lowercase letters (`a-z`) and no other characters.

- Variable **values** can contain the characters `a-z0-1.&?-_`, but can’t contain slash characters
  (`/`).

> [!IMPORTANT] DLBs don’t support patterns in the **Output Path** (`appURI`).

### URL Mapping

You can pass the app name as the **Input Path** and map it directly to the app name in CloudHub:

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Rule #</th><th><strong>Input Path</strong></th><th><strong>Target App</strong></th><th><strong>Output Path</strong></th><th><strong>Protocol</strong></th></tr></thead><tbody><tr><td><div><div><p>1</p></div></div></td><td><div><div><p>/{app}/</p></div></div></td><td><div><div><p>{app}</p></div></div></td><td><div><div><p>/</p></div></div></td><td><div><div><p>http</p></div></div></td></tr></tbody></table>

This rule maps requests to `lb-demo.lb.anypointdns.net/{app}`, redirecting them to
`{app}.cloudhub.io`. The `{app}` pattern matches any application name that you pass in the inbound
request.

### Host Mapping

If your SSL endpoint sets a
[wildcard certificate](https://en.wikipedia.org/wiki/Wildcard_certificate) (such as
`*.example.com`), you can use the `subdomain` variable to map any subdomain:

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Rule #</th><th><strong>Input Path</strong></th><th><strong>Target App</strong></th><th><strong>Output Path</strong></th><th><strong>Protocol</strong></th></tr></thead><tbody><tr><td><div><div><p>1</p></div></div></td><td><div><div><p>/</p></div></div></td><td><div><div><p>{subdomain}</p></div></div></td><td><div><div><p>/</p></div></div></td><td><div><div><p>https</p></div></div></td></tr></tbody></table>

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

- Passing `api.example.com` redirects to `api.cloudhub.io`.

- Passing `application.example.com` maps to `application.cloudhub.io`.

You can also use the `subdomain` variable with the
[Subject Alternative Names](https://en.wikipedia.org/wiki/Subject_Alternative_Name) (SANs) of your
SSL endpoints.

Instead of using a wildcard certificate, which permits any subdomain application name to pass
through the DLB, you can specify which subdomain names to allow. To do this, you must configure
those SANs for a certificate’s common name. You can use the `subdomain` variable to map the
subdomain portion of your domain name to your application.

This example includes:

- Two deployed applications:

  - `dev-app`

  - `qa-app`

- An SSL endpoint with these SANs configured:

  - `dev.example.com`

  - `qa.example.com`

- Mapping rule:

  <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Rule #</th><th><strong>Input Path</strong></th><th><strong>Target App</strong></th><th><strong>Output Path</strong></th><th><strong>Protocol</strong></th></tr></thead><tbody><tr><td><div><div><p>1</p></div></div></td><td><div><div><p>/</p></div></div></td><td><div><div><p>{subdomain}-app</p></div></div></td><td><div><div><p>/</p></div></div></td><td><div><div><p>https</p></div></div></td></tr></tbody></table>

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

- `dev.example.com` redirects to `dev-app.cloudhub.io`.

- `qa.example.com` redirects to `qa-app.cloudhub.io`.

## Use a Literal 1:1 Mapping

Instead of using a pattern, you can map literal app names. In this case, the rules must match the
applications exactly.

This rule maps the default load balancer `lb-demo.lb.anypointdns.net` directly to the
`myApp.cloudhub.io` app in CloudHub:

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Rule #</th><th><strong>Input Path</strong></th><th><strong>Target App</strong></th><th><strong>Output Path</strong></th><th><strong>Protocol</strong></th></tr></thead><tbody><tr><td><div><div><p>1</p></div></div></td><td><div><div><p>/</p></div></div></td><td><div><div><p>myApp</p></div></div></td><td><div><div><p>/</p></div></div></td><td><div><div><p>http</p></div></div></td></tr></tbody></table>

This rule matches the `dev-misc-myhellotest-v1-myapp` app if the input URI is
`/misc/myhellotest/v1/ping` but not `/misc/myhellootest/v1/ping`:

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Rule #</th><th><strong>Input Path</strong></th><th><strong>Target App</strong></th><th><strong>Output Path</strong></th><th><strong>Protocol</strong></th></tr></thead><tbody><tr><td><div><div><p>1</p></div></div></td><td><div><div><p>/{layera}/{domaina}/v{versiona}/</p></div></div></td><td><div><div><p>dev-{layera}-{domaina}-{versiona}-myapp</p></div></div></td><td><div><div><p>/api/</p></div></div></td><td><div><div><p>http</p></div></div></td></tr></tbody></table>

You can also use literal 1:1 mappings for multiple applications by changing the **Input Path** to be
static instead of a defined pattern:

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Rule #</th><th><strong>Input Path</strong></th><th><strong>Target App</strong></th><th><strong>Output Path</strong></th><th><strong>Protocol</strong></th></tr></thead><tbody><tr><td><div><div><p>1</p></div></div></td><td><div><div><p>/v1/applicationX</p></div></div></td><td><div><div><p>application-x</p></div></div></td><td><div><div><p>/api/</p></div></div></td><td><div><div><p>http</p></div></div></td></tr><tr><td><div><div><p>2</p></div></div></td><td><div><div><p>/v1/applicationY</p></div></div></td><td><div><div><p>application-y</p></div></div></td><td><div><div><p>/api/</p></div></div></td><td><div><div><p>http</p></div></div></td></tr><tr><td><div><div><p>3</p></div></div></td><td><div><div><p>/v2/applicationx</p></div></div></td><td><div><div><p>application-x-v2</p></div></div></td><td><div><div><p>/api/</p></div></div></td><td><div><div><p>http</p></div></div></td></tr></tbody></table>

## Mapping Rule Priority

Every rule must have a priority defined. The first rule in the list has a higher priority than rules
lower in the list.

The DLB always uses the first rule that matches, regardless of whether a more exact match appears
later in the list. When creating rules, pay attention to the order for each rule to avoid multiple
rules overriding each other.

In the following example, the `/api/v1/secondapp` URL maps to the `default-app` app:

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Priority</th><th>Input Path</th><th>Target App</th><th>Output Path</th><th>Protocol</th></tr></thead><tbody><tr><td><div><div><p>1</p></div></div></td><td><div><div><p>/api/v1/</p></div></div></td><td><div><div><p>default-app</p></div></div></td><td><div><div><p>/api/v1/</p></div></div></td><td><div><div><p>http</p></div></div></td></tr><tr><td><div><div><p>2</p></div></div></td><td><div><div><p>/api/v1/secondapp/</p></div></div></td><td><div><div><p>second-app</p></div></div></td><td><div><div><p>/api/v1</p></div></div></td><td><div><div><p>http</p></div></div></td></tr></tbody></table>

For the rule to match only `second-app`, the rule priority must be:

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Priority</th><th>Input Path</th><th>Target App</th><th>Output Path</th><th>Protocol</th></tr></thead><tbody><tr><td><div><div><p>1</p></div></div></td><td><div><div><p>/api/v1/secondapp/</p></div></div></td><td><div><div><p>second-app</p></div></div></td><td><div><div><p>/api/v1</p></div></div></td><td><div><div><p>http</p></div></div></td></tr><tr><td><div><div><p>2</p></div></div></td><td><div><div><p>/api/v1/</p></div></div></td><td><div><div><p>default-app</p></div></div></td><td><div><div><p>/api/v1/</p></div></div></td><td><div><div><p>http</p></div></div></td></tr></tbody></table>

### Change the Priority of Mapping Rules in Runtime Manager

To change the priority of mapping rules in Runtime Manager:

1.  From Anypoint Platform, select **Runtime Manager**.

2.  Select **Load Balancers** in the left menu.

3.  Click a load balancer name, and then click a certificate name.

4.  In the **URL Mapping Rules** section, hover over the rule to display the handle:

    ![Handle to use to reorder a mapping rule](/mulesoft/current/en-us/cloudhub/_images/cloudhub-dlb-mapping-rules-reorder.png)

    Figure 2. The arrow shows the handle to use to reorder a mapping rule.

5.  Click and drag the handle to move the rule up or down in the list.

6.  Click **Done Editing**.

### Change the Priority of Mapping Rules Using the CLI

To specify the mapping rule priority when creating a mapping rule with the CLI, use the `index`
value. The rule at index `0` has the highest priority. The higher the index assigned, the lower the
priority.

See [cloudhub load-balancer mappings add](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-mappings-add).

### Change the Priority of Mapping Rules Using the CloudHub API

When using the API to create a mapping rule, you cannot specify a priority order. The new rule is
appended to the list. You can update the order of the rules later by sending a `PATCH` request to
the load balancer endpoint:

```text
anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers/{loadbalancerId}
```

To determine the load balancer ID, perform a GET request to your endpoint:

```text
/organizations/{orgid}/loadbalancers
```

## See Also

- [CloudHub Dedicated Load Balancer](https://docs.mulesoft.com/cloudhub/cloudhub-cli)

- [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/minor/1.0/pages/home/)

- [Add Certificates](https://docs.mulesoft.com/cloudhub/lb-cert-upload)

- [Allowlists](https://docs.mulesoft.com/cloudhub/lb-allowlists)

<!-- document id=73085f0d6b75ae58e7168a09a320eee90f3e8eb1c69d8631e1164ce76e02bd77 url=/mulesoft/current/en-us/cloudhub/lb-reserved-headers.md -->

---
product: CloudHub
---

# Dedicated Load Balancer Reserved Headers

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

HTTP requests and HTTP responses use header fields to send information about the HTTP messages.

A load balancer adds HTTP headers to provide backend servers with crucial information about the
original client connection. This information supports routing and security.

The CloudHub Dedicated Load Balancer (DLB) reserves and injects specific HTTP headers into incoming
requests. You can’t overwrite these headers.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Header Name</th><th>Description</th><th>Value</th></tr></thead><tbody><tr><td><p><code>Strict-Transport-Security</code></p></td><td><p>Enables HTTP Strict Transport Security (HSTS) to force HTTPS connections and prevent protocol downgrade attacks.</p></td><td><p><code>max-age=31536000; includeSubdomains;</code></p></td></tr><tr><td><p><code>X-Content-Type-Options</code></p></td><td><p>Prevents MIME type sniffing attacks by instructing browsers to not override the declared content type.</p></td><td><p><code>nosniff</code></p></td></tr><tr><td><p><code>X-Frame-Options</code></p></td><td><p>Prevents browsers from loading your web page in iframes to protect against click-jacking.</p></td><td><p><code>SAMEORIGIN</code></p></td></tr><tr><td><p><code>X-XSS-Protection</code></p></td><td><p>Enables basic cross-site scripting (XSS) protection in browsers that support it.</p></td><td><p><code>1; mode=block</code></p></td></tr><tr><td><p><code>x-ch1-path</code></p></td><td><p>Preserves the original request path before the system applies the DLB mapping rules. It’s injected in the DLB request to the upstream server.</p></td><td><p>Original request path. For example, <code>/v1/orders</code>.</p></td></tr></tbody></table>

## Header Injection Rules

Security Headers

- The DLB enforces the security headers, and you can’t override them.

- The DLB injects the `X-Content-Type-Options`, `X-Frame-Options`, and `X-XSS-Protection` headers in
  the DLB response to callers for responses with these status codes: `200`, `201`, `204`, `206`,
  `301`, `302`, `303`, `304`, `307`, and `308`. These are the status codes for which the underlying
  NGINX `add_header` directive applies by default. Responses with other status codes, such as
  `202 Accepted`, don’t include these headers.

- The DLB always injects the `Strict-Transport-Security` regardless of the response code.

x-ch1-path Header

- The DLB injects the x-ch1-path header in the request sent to the upstream server, not in the
  response.

## Header Details

Strict-Transport-Security

- The `Strict-Transport-Security` header forces browsers to use HTTPS for all future requests to the
  domain.

- The `max-age` value represents the duration in seconds that the browser remembers and enforces the
  HSTS policy after receiving the header.

- The `includeSubdomains` directive extends the HTTPS enforcement policy beyond just the main domain
  to cover all subdomains.

- The `always` parameter includes the `Strict-Transport-Security` in every HTTP response, regardless
  of the response status code.

X-Content-Type-Options

- The `X-Content-Type-Options` header prevents browsers from MIME-sniffing a response away from the
  declared content-type.

- The `nosniff` directive instructs browsers to trust the content-type header declared by the server
  and never attempt to guess or "sniff" the actual content type by examining the content itself.

X-Frame-Options

- The `X-Frame-Options` header controls whether a browser can to load your web page inside a
  `<frame>` or `<iframe>` element on another website.

- The `SAMEORIGIN` value allows your page to load in an iframe only if both pages share the same
  origin.

X-XSS-Protection

- The `X-XSS-Protection` header enables and configures the browser’s built-in Cross-Site Scripting
  (XSS) filter. \*< The `1; mode=block` value enables the XSS filtering and blocks the page if it
  detects an XSS attack.

x-ch1-path

- The `x-ch1-path` header preserves the original request path before the system applies the DLB
  mapping rules.

- The value is the original request path as received by the DLB. For example, `/v1/orders`.

- This header allows Mule applications to access the original request path for logging, analytics,
  or business logic.

## Additional DLB Headers

The DLB also forwards several headers to upstream applications for authentication and routing
purposes:

- `X-SSL-Client-Verify`: Client certificate verification status

- `X-SSL-Client-DN`: Client certificate distinguished name

- `X-SSL-Issuer`: Client certificate issuer

- `X-SSL-Client-Serial`: Client certificate serial number

- `X-Real-IP`: Original client IP address

- `X-Forwarded-For`: Forwarded client IP addresses

- `X-Forwarded-Proto-Real`: Original protocol (HTTP/HTTPS)

## See Also

- [Dedicated Load Balancer Mapping Rules](https://docs.mulesoft.com/cloudhub/lb-mapping-rules)

- [Certificate Validation in Dedicated Load Balancers](https://docs.mulesoft.com/cloudhub/lb-cert-validation)

<!-- document id=fa8664fafe1879e17ed1b41ae9719717c13f91f4c019d4f22f4817e732eee743 url=/mulesoft/current/en-us/cloudhub/lb-updates.md -->

---
product: CloudHub
---

# Dedicated Load Balancer Updates

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The CloudHub dedicated load-balancer service provides quarterly updates that include the latest OS
and security patches. If necessary, additional patches provide updates more often. These updates
don’t include feature changes.

Because these updates contain required security patches, you can’t roll back these updates once
applied.

When updates are available, an **Update** button appears on the load balancers page:

![LoadBalancerUpdatePage](/mulesoft/current/en-us/cloudhub/_images/lb-update-page.png)

The **Update** button also appears on the details page for the individual load balancer:

![LoadBalancerUpdateDetails Page](/mulesoft/current/en-us/cloudhub/_images/lb-update-details.png)

## Update the Dedicated Load Balancer

The **Update** button indicates a load balancer requires an update. You can schedule the update to
occur at your convenience. Before updating the Production DLBs, update the Sandbox DLB and run
required tests.

To update a load balancer:

1.  From Anypoint Platform, click **Runtime Manager**.

2.  Click **Load Balancers**.

3.  Click the **Update** button.

4.  At the **Update load balancer** prompt, click **Update**.

    Click the **View release notes** link for details on the update.

    > [!IMPORTANT] When you update a DLB with static IP addresses, the update might require
    > additional static IPs. If you’re prompted to add these new IP addresses to your allowlist, do
    > so before you click **Update**.

The update results in a rolling restart with no downtime. Some in-flight requests might experience a
brief interruption during the restart. No transactions are dropped or lost provided that transaction
times are shorter than 600 seconds or the configured Mule Application Response Timeout, whichever is
smaller.

If you experience a sustained outage after updating, contact MuleSoft Support.

## See Also

- [Static IP Addresses](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer#static-ip-addresses)

- [DLB Monthly Scheduled Update FAQ](https://help.salesforce.com/s/articleView?id=001117562&type=1)

<!-- document id=b9fe801e5a7fe35302636970c982c11aeaa2550ebcb742463af278382af2866c url=/mulesoft/current/en-us/cloudhub/cloudhub-dedicated-load-balancer.md -->

---
product: CloudHub
---

# Dedicated Load Balancers

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

CloudHub dedicated load balancers (DLBs) are an optional component of Anypoint Platform that enable
you to route external HTTP and HTTPS traffic to multiple Mule applications deployed to CloudHub
workers in a Virtual Private Cloud (VPC).

Dedicated load balancers enable you to:

- Handle load balancing among the different CloudHub workers that run your application.

  If the target CloudHub application has multiple workers and they don’t respond within the defined
  timeout, the DLB makes requests to the next worker sequentially. The
  [default timeout value](https://docs.mulesoft.com/cloudhub/lb-create-arm#create-a-load-balancer) is 300 seconds.

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

- Configure proxy rules that map your applications to custom domains.

  This enables you to host your applications under a single domain.

To use a dedicated load balancer in your environment, you must first create an Anypoint VPC. Because
you can associate multiple environments with the same Anypoint VPC, you can use the same dedicated
load balancer for your different environments.

You can view the load balancer and Anypoint VPC endpoints in your Anypoint Platform organization
from the API portal.

## Create and Configure a Dedicated Load Balancer

To create and configure a load balancer, you must be an administrator of the organization to which
the load balancer is associated.

DLB names must be unique across all DLBs defined in Anypoint Platform (by all MuleSoft customers).

There are three ways to create and configure a dedicated load balancer for your Anypoint VPC:

- [Runtime Manager](https://docs.mulesoft.com/cloudhub/lb-create-arm) from Anypoint Platform

- The [cloudhub load-balancer create](https://docs.mulesoft.com/cloudhub/cloudhub-cli#cloudhub-load-balancer-create) command from the
  Anypoint Platform CLI

- The [CloudHub REST API](https://docs.mulesoft.com/cloudhub/cloudhub-api) through these endpoints:

  - `anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers`

  - `anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/vpcs`

For a full description of `loadbalancers` and `vpcs` endpoints, see the
[CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/).

## Dedicated Load Balancer Licensing

Each DLB unit that you purchase is the equivalent of two workers handling load balancing between
CloudHub workers. You can assign up to four load balancer units to a DLB. A DLB with four load
balancer units assigned has eight workers.

## Static IP Addresses

If you enable static IP addresses for a DLB, the number of static IP addresses allocated to the DLB
is equal to double the number of workers. For example, if your DLB has four workers, the DLB has
eight associated static IP addresses.

Half the static IPs (equal to the number of worker instances) are in use at any given time. When you
restart or update the DLB, the DLB switches to use the group of unused static IP addresses and
transitions the first group of static IP addresses to the unused state.

### Considerations

- Because static IPs change when you restart or update your DLB, use the DLB’s DNS address rather
  than the IP addresses when calling the DLB from an external service. Ensure that the client
  includes the necessary retry mechanisms to account for the DNS switch.

- To avoid connection issues when the load balancer is restarting, adhere to the DNS TTL (30
  seconds), including connection keep alive. Connection keep alive time is set to 60 seconds by
  default. The connections are closed after the new workers are online and the TTL expires.

- Switching between the two groups of static IP addresses enables zero-downtime restarts and
  updates, ensuring that no transactions are dropped or lost as long as the transaction times are
  shorter than 600 seconds or the value of **Mule Application Response Timeout** (whichever is
  smaller).

- DLB uses DNS-based routing to distribute traffic across DLB workers and returns the IP address of
  all DLB workers to the calling client. A single DLB worker might receive all the client traffic
  within the TTL window regardless of the amount of transactions per second. To avoid this, ensure
  that you have granular load distribution between the DLB workers by alternating between the IP
  addresses returned in the DNS resolution.

- When the DLB is stopped during configuration change, the DNS are deleted. If, at restart, there is
  DNS lookup, the `NXDOMAIN` error is cached for 15 minutes. To avoid this negative cache, ensure
  that you stop all API calls.

- Proxy buffering is enabled by default in Anypoint Dedicated Load Balancers. This feature stores
  the response from a server in internal buffers as it comes in, and delays sending data to the
  client until the entire response is buffered. Proxy buffering helps optimizing performance with
  slow clients, as it allows the proxied server to return its response quickly and serve other
  requests. However, it is not ideal for small payload streaming, as the buffer bucket can take
  longer to fill in. To avoid performance problems in small payload streaming, disable proxy
  buffering by passing `no` in the `X-Accel-Buffering` response header field.

> [!NOTE] For DLBs created before October 2021, click **Update** to enable the feature. After
> clicking **Update**, the DLB uses the static IP model described earlier, and you cannot revert to
> the former model.

For information about updating DLBs, see [Dedicated Load Balancer Updates](https://docs.mulesoft.com/cloudhub/lb-updates).

## See Also

- [Configure SSL Endpoints and Certificates](https://docs.mulesoft.com/cloudhub/lb-ssl-endpoints)

- [Anypoint VPC](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [Mapping Rules](https://docs.mulesoft.com/cloudhub/lb-mapping-rules)

- [Allowlists](https://docs.mulesoft.com/cloudhub/lb-allowlists)

<!-- document id=a75b52fbdae6bbb4e426f726009c905aac181ae981ca07980fec00ce72acd100 url=/mulesoft/current/en-us/cloudhub/deploying-to-cloudhub.md -->

---
product: CloudHub
---

# Deploy to CloudHub

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can deploy Mule applications to CloudHub using:

- [Anypoint Runtime Manager](#deploy-an-application-from-runtime-manager)

- [Anypoint Studio](#deploy-an-application-from-studio)

- [Anypoint Code Builder](https://docs.mulesoft.com/anypoint-code-builder/int-deploy-mule-apps)

- [CloudHub CLI](#deploy-an-application-from-the-command-line)

- [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)

- [Mule Maven plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub)

You can also deploy an API proxy directly from API Manager to CloudHub. See
[Configure a Proxy and Deploy to CloudHub](https://docs.mulesoft.com/api-manager/latest/getting-started-proxy#configure_and_deploy_to_cloudhub).

To be notified by email when an error occurs during deployment, set up a **Deployment failed**
alert. See [Create an Alert](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager#create-an-alert).

## Deploy an Application from Runtime Manager

To deploy from Runtime Manager to CloudHub:

1.  Sign in to Anypoint Platform.

2.  Select **Runtime Manager**.

3.  In the **Applications** page, click **Deploy application**.

    You see the **Deploy Application** page:

    ![Application Name field](/mulesoft/current/en-us/cloudhub/_images/cloudhub-deploy-app.png)

4.  Provide a name for your application.

    See [Application Names](#application-names).

5.  In the **Deployment Target** menu, select **CloudHub**, if it is not already selected.

6.  Specify the application file:

    - Import a file from Exchange:

      1.  Click **Choose file** > **Import file from Exchange**.

      2.  Select **Application** for the type.

      3.  Enter the name of your application in the search box.

      4.  Select the application to deploy, select a version from the **Version** menu, and then
          click **Select**.

    - Upload an application archive (ZIP or JAR) file:

      1.  Select **Choose file** > **Upload file**.

      2.  Select the file to upload and then click **Open**.

          The application file size limit is 200 MB.

          > [!NOTE] The maximum CloudHub 1.0 application size is a hard limit of 200 MB (209,715,200
          > bytes). Deployments that exceed it fail with HTTP `400` and the error message
          > `Maximum length exceeded: 209715200 Bytes`. You can’t raise this limit. To reduce the
          > deployable archive, remove unused dependencies and externalize large resources. Mule
          > apps deploy as self-contained archives, so all dependencies count toward the limit.

    - Copy an application from a nonproduction environment.

      See
      [Copy an Application from Sandbox to Production](#copy-an-application-from-sandbox-to-production).

7.  Click tabs to configure application options.

    See [Configure Application Settings](#configure-application-settings).

8.  Click **Deploy Application**.

## Deploy an Application from Studio

You can deploy your applications directly from Studio to CloudHub. This option is helpful if you
want to test your application while developing it.

> [!NOTE] You can deploy an application from Studio to any environment except **Design**.

To deploy from Studio to CloudHub:

1.  Open your application in Studio.

2.  In **Package Explorer**, right-click the project folder and select **Anypoint Platform > Deploy
    to CloudHub**.

3.  If this is your first time deploying from Studio, provide your Anypoint Platform credentials at
    the prompt.

    Studio stores your credentials for future use. You can manage these credentials by selecting
    **Anypoint Studio > Preferences > Anypoint Studio > Authentication**.

    After you sign in, you see the **Deploying Application** page:

    ![Application Name field and the Deploy Application button](/mulesoft/current/en-us/cloudhub/_images/cloudhub-deploy-app-studio.png)

    Figure 1. The screenshot shows (**1**) the **Application Name** field, (**2**) the **Deploy
    Application** button on the **Deploying Application** page.

4.  Change the application name, if necessary.

5.  Click tabs to configure application options.

    See [Configure Application Settings](#configure-application-settings).

6.  Click **Deploy Application**.

## Deploy an Application from the Command Line

To deploy a Mule app from the CloudHub command-line interface (CLI):

1.  If you do not already have access to the Anypoint command-line tool, install it.

    See [Anypoint Platform CLI](https://docs.mulesoft.com/anypoint-cli/latest/).

2.  Log into your Anypoint Platform account from the command line:

    1.  Enter your username:

        `anypoint-cli --username="user"`

    2.  At the prompt, enter your password.

3.  Run the following command, replacing `myMuleApp` with the deployment name of your app and
    `/Users/exported-app-folder/my-mule-app.jar` with the path to the deployable archive (JAR or
    ZIP) file on your file system:

    runtime-mgr cloudhub-application deploy myMuleApp /Users/exported-app-folder/my-mule-app.zip

    The command-line utility displays a table of deployment information:

    Deploying myMuleApp ...
    ┌──────────────────────────────┬────────────────────────────────────────┐ │ Domain │
    mymuleapp.cloudhub.io │
    ├──────────────────────────────┼────────────────────────────────────────┤ │ Status │ UNDEPLOYED
    │ ├──────────────────────────────┼────────────────────────────────────────┤ │ Updated │ a few
    seconds ago │ ├──────────────────────────────┼────────────────────────────────────────┤ │
    Runtime │ 4.1.0 │ ├──────────────────────────────┼────────────────────────────────────────┤ │
    File name │ my-mule-app.zip │
    ├──────────────────────────────┼────────────────────────────────────────┤ │ Persistent queues │
    false │ ├──────────────────────────────┼────────────────────────────────────────┤ │ Persistent
    queues encrypted │ false │
    ├──────────────────────────────┼────────────────────────────────────────┤ │ Static IPs enabled │
    false │ ├──────────────────────────────┼────────────────────────────────────────┤ │ Monitoring │
    Enabled. Auto-restart if not responding│
    ├──────────────────────────────┼────────────────────────────────────────┤ │ Workers │ 1 vCore \*
    1 │

    After you deploy the app on CloudHub, you can view and manage it on Runtime Manager.

4.  If you want to stop the app from the command line, run the following command, replacing
    `app-name` with the deployment name of your app:

    `runtime-mgr cloudhub-application stop app-name`

To exit the command-line tool, press Ctrl+c twice.

For a complete list of the commands, see [Anypoint Platform CLI](https://docs.mulesoft.com/anypoint-cli/latest/).

## Copy an Application from Sandbox to Production

If you create and test an application in a sandbox environment, you can move it to the production
environment for deployment. To move applications between environments, you need the following
permissions:

- At the business group level:

  - Exchange Viewer

  - Read Runtime Fabrics

- In the target environment (where you are deploying the application):

  - Create Applications

  - Download Applications

  - Read Applications

- In the source environment (from where the application is fetched):

  - Download Applications

  - Read Applications

For information about configuring permissions, see [Teams](https://docs.mulesoft.com/access-management/teams).

To avoid name conflicts, rename the application before you deploy it to another environment.

Runtime Manager prevents you from duplicating applications in a single environment, so you cannot
move an application into the environment it’s already in. If you want to duplicate an application in
a single environment, rename the filename of one application before you deploy it.

To move an application from sandbox to production:

1.  Sign in to Anypoint Platform.

2.  Select **Runtime Manager** and switch to your production environment.

    See
    [Switch Environments Using Runtime Manager](https://docs.mulesoft.com/runtime-manager/runtime-manager-switch-env#switch-environments-using-runtime-manager).

3.  In the **Applications** page, click **Deploy application**.

    You see the **Deploy Application** page:

    ![Application Name field and Get from sandbox and Deploy Application buttons](/mulesoft/current/en-us/cloudhub/_images/cloudhub-deploy-app-sandbox.png)

4.  Provide a unique name for your application in production and click **Get from sandbox**.

    This button is unavailable if no nonproduction environment exists.

5.  Select your sandbox environment and then the application that you want to move to production.

    Only applications that are deployed to CloudHub appear in the list because you can move only
    apps that are currently deployed to CloudHub to other CloudHub workers. For example, you can’t
    move an app that is currently deployed on a local server to CloudHub.

6.  If you want to copy the environment variables and Mule version from the source application,
    select **Merge environment variables and mule version**.

    If your source application contains safely hidden application properties, you must redefine them
    in the **Properties** tab. For information about safely hidden application properties, see
    [Safely Hide Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties).

7.  Click **Apply**.

8.  Click tabs to configure application options.

    See [Configure Application Settings](#configure-application-settings).

9.  Click **Deploy Application**.

## Application Names

The application name can contain between 3 and 42 alphanumeric characters (a-z, A-Z, 0-9) and dashes
(-). They cannot contain spaces or other characters.

> [!IMPORTANT] You cannot change the name of an app after you deploy it. To change the name, you
> must delete and redeploy the app using the new name.

The application name identifies your application not only in Runtime Manager but also in the public
`cloudhub.io` domain. For example, an application named `myapplication` is accessible at
`http://myapplication.cloudhub.io`.

To avoid domain conflicts, the application name must be globally unique across CloudHub. For this
reason, create a naming convention to ensure unique application names. For example, you could
prepend your company name and department to all application names, such as
`mycompany-mydept-myapplication`. You can then add DNS records to hide the complex application name.
For example, you might route requests to `myapplication.mycompany.com` to
`mycompany-mydept-myapplication.cloudhub.io`.

Using the CloudHub dedicated load balancer, you can also implement mapping rules to set your
application’s public URL to any other path, as long as you own the domain. See
[Mapping Rules](https://docs.mulesoft.com/cloudhub/lb-mapping-rules).

## Configure Application Settings

You can configure the application deployment by clicking the tabs on the **Deploy Application**
page:

![Configuration tabs on the Deploy Application page](/mulesoft/current/en-us/cloudhub/_images/cloudhub-deploy-app-config-tabs.png)

Figure 2. The arrow shows the configuration tabs on the **Deploy Application** page.

- [Runtime](#runtime-tab-settings)

- [Autoscaling](#autoscaling-tab-settings)

- [Properties](#properties-tab-settings)

- [Insight](#insight-tab-settings)

- [Logging](#logging-tab-settings)

- [Static IPs](#static-ips-tab-settings)

### Runtime Tab Settings

The **Runtime** tab includes the following settings:

Release Channel

Starting with Mule 4.5, MuleSoft introduces two new release channels,
[Edge and Long-term Support (LTS)](https://docs.mulesoft.com/release-notes/mule-runtime/lts-edge-release-cadence).

For new applications, the Edge channel is selected by default in the **Release Channel** drop-down
menu.

For existing applications using a legacy version, the **Release Channel** drop-down list is selected
as `None` by default. Use the **Release Channel** drop-down list to select the desired release
channel.

For existing applications using an Edge version, the **Release Channel** drop-down list is selected
as `Edge`. The **Runtime Version** dropdown list indicates if there is an update available, as well
as the previous, latest and recommended version of the application. Use the **Release Channel**
drop-down list to change to a legacy version.

For existing applications using an Edge or an LTS version on extended support, a warning message
appears indicating the version’s EOL.

Runtime version

The runtime version must be the same Mule version used to develop your application.

After you deploy the app, CloudHub automatically alerts you when updates for the selected runtime
version are available. See
[CloudHub Runtime Continuous Updates](https://docs.mulesoft.com/cloudhub/cloudhub-app-runtime-version-updates).

> [!NOTE] After End of Extended Support for Mule runtime 4.3 and 4.4, Mule applications deployed to
> CloudHub or CloudHub 2.0 environments are stopped.

Java Version

Select the Java version for your application. For more information, visit
[Java Support](https://docs.mulesoft.com/general/java-support).

Worker size

See [Worker Size and vCores](#worker-size-and-vcores).

Workers

When you deploy an application with more than one worker, CloudHub automatically balances any
incoming traffic load across your allocated workers. See [Clustering](https://docs.mulesoft.com/cloudhub/cloudhub-fabric).

Region

If you have global deployment enabled on your account, you can change the deployment region.

When you change the region, the domain is automatically updated.

See [Regional Services](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide#regional-services).

Automatically restart application when not responding

CloudHub automatically restarts your application when the monitoring system discovers an issue.

See [Application Monitoring and Automatic Restarts](https://docs.mulesoft.com/cloudhub/worker-monitoring).

Persistent queues

You can use persistent queues on your application to store data in an input queue to disk.
Persistent queues protect against message loss and enable you to distribute workloads across a set
of workers.

See [Manage Queues](https://docs.mulesoft.com/cloudhub/managing-queues).

Before you can take advantage of persistent queueing, you must set up your application to use
queues.

See [Clustering](https://docs.mulesoft.com/cloudhub/cloudhub-fabric).

Encrypt persistent queues

If you enable persistent queues, you can optionally encrypt the data stored in the input queue on
disk.

Use Object Store v2

Object Store v2 is enabled by default in Mule 4.

See [Object Store V2](https://docs.mulesoft.com/object-store/).

Enable Monitoring and Visualizer

Use Anypoint Monitoring and Visualizer for Mule applications running on supported versions of Mule.

This feature is available only if your organization has the Anypoint Integration Advanced package or
a Titanium subscription to Anypoint Platform. For more information, see the
[Pricing and Packaging](https://docs.mulesoft.com/general/pricing) documentation.

See [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) and [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/).

### Autoscaling Tab Settings

Autoscaling enables you to define policies that respond to CPU or memory usage thresholds by scaling
up or down the processing resources used by an application.

This tab doesn’t appear by default. See [Autoscaling in CloudHub](https://docs.mulesoft.com/cloudhub/autoscaling-in-cloudhub) for
information.

> [!NOTE] Autoscaling isn’t available on CloudHub for Usage-based Pricing (UBP) organizations.

### Properties Tab Settings

On the **Properties** tab, you can specify properties (key-value pairs) that the application uses
during deployment and while running.

> [!NOTE] When you deploy an application from a nonproduction environment (**Get from sandbox**),
> the new application inherits any properties defined in the original application. You can update
> these properties as required on the **Properties** tab before deploying the application.

For more information about specifying properties, including hiding them in Runtime Manager, see
[Manage Properties for Applications on CloudHub](https://docs.mulesoft.com/cloudhub/cloudhub-manage-props) and
[Safely Hide Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties).

### Insight Tab Settings

You can enable the Insight analytics feature and specify metadata options on the **Insight** tab.
For information about using this tool, see [Insight](https://docs.mulesoft.com/runtime-manager/insight).

### Logging Tab Settings

CloudHub stores activity logs, which you can view or download from Runtime Manager. See
[View Log Data](https://docs.mulesoft.com/cloudhub/viewing-log-data).

You can configure the logging level (`DEBUG`, `WARN`, `ERROR`, or `INFO`) for the application on the
**Logging** tab.

Alternatively, you can configure logging by modifying the `level` value in the `log4j2.xml` file.
See
[Configuring Custom Logging Settings](https://docs.mulesoft.com/mule-runtime/latest/logging-in-mule#configuring-custom-logging-settings)
and [Apache Logging Services](https://logging.apache.org/log4j/2.x/manual/configuration.html).

### Static IPs Tab Settings

Use the **Static IPs** tab to allocate a static IP address to your application deployed in a
specific region.

You can also preconfigure static IP addresses for multiple regions for disaster recovery (DR)
scenarios. If an application has static IP addresses allocated in multiple regions, the static IP
address is assigned when the application is deployed to a new region.

If your application is already running, applying the static IP address change restarts it using the
newly applied static IP address.

By default, the number of static IP addresses allocated to your organization is equal to twice the
number of production vCores in your subscription and appears under the **Use Static IP** checkbox.

If you need to free some of your static IP allocations, you can release unused IP addresses from an
application. To increase your allocation of static IP addresses, contact your Customer Success
Manager. For more information about adding more static IPs, see
[How to Request Additional Static IPs for your Anypoint Organization](https://help.salesforce.com/s/articleView?id=001121221&type=1).

## Worker Size and vCores

On each application, workers are responsible for executing the application logic.

Worker sizes have different compute, memory, and storage capacities.

For information about worker size and vCores, see
[CloudHub Workers](https://docs.mulesoft.com/cloudhub/cloudhub-architecture#cloudhub-workers).

## Change Settings of a Deployed Application

You can change most application settings after deploying an application to CloudHub.

To edit the settings of a deployed application:

1.  On the **Applications** tab, select the application name.

2.  Click the **Settings** tab.

3.  Make your changes and click **Apply Changes**

CloudHub redeploys the application with zero downtime.

> [!NOTE] Cancelling a deployment and starting a new one for the same application before the
> cancellation is complete can lead to a one-to-three-minute downtime.

## Deployment Progress

When CloudHub uploads your application and begins deploying it, CloudHub switches its user interface
to the **Logs** view so that you can monitor deployment progress.

The application status changes to `Deploying` to indicate the deployment is in progress. When the
deployment is complete, the application status changes to `Started` and a message appears in the
status area and in the logs to indicate that the application is successfully deployed.

> [!NOTE] While you deploy an application on Mule runtime engine version 4.1.x and later, the
> [Gatekeeper](https://docs.mulesoft.com/mule-gateway/mule-gateway-gatekeeper#how-gatekeeper-works) mechanism works with
> [API Autodiscovery](https://docs.mulesoft.com/mule-gateway/mule-gateway-autodiscovery-overview) to help determine the
> readiness of a deployment. If Gatekeeper considers the application not ready within five minutes
> of deployment initiation, the application status is `Deploy failed`.

## Deployment Failure

If an error occurs and the application cannot be deployed, the application status changes to
`Deploy failed`. The **Logs** tab includes details on the application deployment errors.

## See Also

- [Manage CloudHub-Specific Settings](https://docs.mulesoft.com/cloudhub/managing-cloudhub-specific-settings)

- [Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)

- [Application Status States](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications#application_status_states)

- [Monitor Applications](https://docs.mulesoft.com/runtime-manager/monitoring)

- [Develop Applications for CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub)

- [Anypoint Platform Command-Line Interface](https://docs.mulesoft.com/anypoint-cli/latest/)

- [CloudHub REST API](https://docs.mulesoft.com/cloudhub/cloudhub-api)

<!-- document id=17983e4eddb13732270e76f76dd81048d3f07e726d0fea8a8b19765cc06edb9f url=/mulesoft/current/en-us/cloudhub/developing-applications-for-cloudhub.md -->

---
product: CloudHub
---

# Develop Applications for CloudHub

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

When developing applications for deployment to CloudHub, review the following considerations.

## Specify an HTTP/HTTPS Host

If you use Anypoint Connector for HTTP (HTTP Connector), define the host address in the CloudHub
configuration as `0.0.0.0`. CloudHub routes requests from your application domain URL to the
endpoint. If you deploy multiple workers, CloudHub load-balances incoming traffic automatically
across the workers for you. As your application scales, work loads automatically distribute between
your workers.

## Provide an External HTTP/HTTPS Port

If your application requires an externally accessible HTTP or HTTPS port to receive messages,
trigger events, or expose a web service or user interface, declare the HTTP Listener port using the
reserved property `${http.port}` or `${https.port}`. On CloudHub, port `${http.port}` or
`${https.port}` is assigned automatically by the platform services. Traffic on port 80 to your
application domain’s URL is routed to `${http.port}` and traffic on port 443 is route to
`${https.port}`.

To support routing to multiple CloudHub services over this port, you need to configure each with
unique paths on the URL that is exposed. For example:

```console
http://0.0.0.0:${http.port}/service/path/one
http://0.0.0.0:${http.port}/service/path/two
```

## Deployment Option Flexibility

To deploy the same Mule application to different deployment targets, such as an on-premises server
and CloudHub, see [Deploy Mule Applications](https://docs.mulesoft.com/mule-runtime/latest/deploying).

For the key differences between deployment environments, see
[Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies).

You can define properties and variables for each deployment outside of the application and then
reference them from your application. For example, you can define a local value for the variable
`http.port` or `https.port`. For information, see
[Configuring Properties](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties).

You can also set these property variables using Runtime Manager or the Anypoint Platform
command-line interface.

### Avoid HTTP Proxy Settings

In the CloudHub environment, Mule applications access a target HTTP server directly on the internet.
In local development environments, the internet is accessible only via an HTTP proxy server.

You can avoid adding proxy settings in the HTTP request configuration in a Mule application by using
JVM system properties so that when you deploy the application to CloudHub, you don’t need to change
the code.

To do this:

1.  For Mule 4 applications, enter timeout settings on the HTTP request configuration, for example:

    - **HTTP Request configuration** > **General** > **Connection idle timeout:** 30000

    - **HTTP Request configuration** > **Settings** > **Response timeout:** 30000

      Adjust the timeout values to any number greater than 0. A blank or 0 timeout value can cause a
      connection failure.

2.  Add the following to the local Mule runtime command line. In Anypoint Studio, change the **Run
    Configurations** and add the following parameters as one line:

```console
-Dhttp.nonProxyHosts="localhost"\-Dhttps.proxyHost={proxy server ip}\-Dhttps.proxyPort={proxy server port}\-Dhttp.proxyHost={proxy server ip}\-Dhttp.proxyPort={proxy server port}\-Djava.net.useSystemProxies=false\-Dcom.ning.http.client.AsyncHttpClientConfig.useProxySelector=false\-Dcom.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true
```

> [!NOTE] Replace `{proxy server ip}` and `{proxy server port}` with the actual HTTP proxy server IP
> address and port number.

## Configure Logging

The CloudHub logging service captures all log messages from your application. You can view logs in
the **Logging** tab in the Runtime Manager console. To expose additional information in your logs
for diagnostic or audit purposes, use the
[Logger component](https://docs.mulesoft.com/mule-runtime/latest/logger-component-reference).

> [!IMPORTANT] On CloudHub, after you delete an application, your log data is no longer accessible
> through the console. CloudHub archives old log data for a limited period of time before it is
> purged, so you can recover the data if needed. For more information, open a support case at
> [Salesforce Help](https://help.salesforce.com).

## Package Third-Party Libraries

CloudHub provides services in Anypoint Platform that support connecting over different protocols and
transforming many data formats. All the standard Mule libraries are included and available to your
application. If you need to include another third-party library, you can package that library in the
application JAR file. For information, see
[Introduction to Mule 4: Packaging Applications](https://docs.mulesoft.com/mule-runtime/latest/mule-app-dev).

## Access Resources Behind the Firewall

When developing an application that needs to access resources from inside your firewall, you can
configure Anypoint Virtual Private Cloud (Anypoint VPC) to host your CloudHub workers and configure
an IPSec tunnel to access your applications.

## Access Third-Party APIs and Services

MuleSoft provides connectors for many third-party applications, such as Salesforce, NetSuite, and
Twitter. For information about how to find and use connectors with your application, see the
[Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors).
In addition, you can create your own connectors using Anypoint Connector DevKit.

## Understand Local Storage Limitations

CloudHub worker local storage is ephemeral. Unlike local development environments, CloudHub clears
local data when an app restarts.

This limitation affects:

Persistent object stores

Configuring `persistent="true"` writes data to local disk. This works in Anypoint Studio and
standalone Mule runtimes, but data doesn’t persist across CloudHub restarts. Use
[Object Store v2](https://docs.mulesoft.com/object-store/) for persistent storage.

Local file operations

The File connector and other file-based operations write to the worker’s local disk. CloudHub
deletes these files when the app restarts.

Temporary files and caches

App-generated files, custom logs, and local cache data don’t persist.

To ensure data persistence in CloudHub:

- Use [Object Store v2](https://docs.mulesoft.com/object-store/) instead of persistent object stores for app state and
  synchronization data.

- Store files in external cloud storage services.

- Design stateless integrations by persisting data in external databases or messaging queues.

For more information about designing resilient applications, see
[CloudHub High Availability and Disaster Recovery](https://docs.mulesoft.com/cloudhub/cloudhub-hadr).

## Use Secure Properties

You can flag application properties as secure so that their values are not visible to users at
runtime or passed between the server and the console. For information, see
[Secure Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties).

## See Also

- [HTTP Connectors](https://docs.mulesoft.com/http-connector/1.10/)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [Anypoint Studio](https://docs.mulesoft.com/studio/)

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)

- [Anypoint Platform Command-Line Interface](https://docs.mulesoft.com/anypoint-cli/latest/)

- [View Log Data](https://docs.mulesoft.com/cloudhub/viewing-log-data)

- [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [Secure Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties)

<!-- document id=0212d134189acbc6396dae87347d5d89280e2e21a0e544191afea5473c040665 url=/mulesoft/current/en-us/cloudhub/lb-download-logs.md -->

---
product: CloudHub
---

# Download Dedicated Load Balancer Logs

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Download dedicated load balancer (DLB) logs using the CloudHub API. DLB log downloads run
asynchronously. After initiating a request, check its status and retrieve the download URL when
processing completes. Only one active download request per DLB is allowed at a time.

DLB log downloads require two APIs:

- Initiate Download

- Download Log Status

The download process runs as follows:

1.  Fetch the authorization token.

2.  Call the Initiate Download API.

3.  Periodically check the request status using the Download Log Status API.

4.  Retrieve the download URL when processing completes.

## Initiate Download API: Absolute Query Type

Use the absolute query type to request logs for a specific time range by specifying `startTime` and
`endTime`.

If `queryType` is `ABSOLUTE`, `startTime` and `endTime` must be specified in ISO 8601 UTC format
with microsecond precision (`YYYY-MM-DDTHH:mm:ss.SSSSSSZ`), for example,
`2025-12-25T10:00:00.000000Z`. The `Z` suffix is required to indicate UTC. Requests that don’t match
this format fail validation.

```bash
curl --location -X POST 'https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/logs/download' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer myAccessToken' \
--data '{
    "resourceType": "DLB_LOGS",
    "resourceName": "myDlbName",
    "queryType": "ABSOLUTE",
    "startTime": "2025-12-25T10:00:00.000000Z",
    "endTime": "2026-01-01T10:00:00.000000Z"
}'
```

### Sample Response

The API returns a response similar to this:

```json
{
  "executionName": "myDlbExecutionName",
  "startDate": "Fri Jan 02 17:38:09 UTC 2026",
  "status": "RUNNING",
  "message": "Log download request submitted successfully"
}
```

### Validations

These validations apply to the request:

- `resourceType` is a required parameter and must be `DLB_LOGS`.

- `resourceName` is a required parameter and must be a valid DLB name associated with the requesting
  organization.

- `queryType` is a required parameter and must be `RELATIVE` or `ABSOLUTE`. If `queryType` is
  `ABSOLUTE`, `startTime` and `endTime` are required parameters and must be in ISO 8601 UTC format
  with microsecond precision (`YYYY-MM-DDTHH:mm:ss.SSSSSSZ`).

- `validityMinutes` is an optional parameter. Default value is 60 minutes. Allowed range is 10 to
  1440 minutes.

- `maxRows` is an optional parameter. Default value is 10,000. Maximum value is 500,000.

## Initiate Download API: Relative Query Type

Use the relative query type to request logs for a preset time window (for example, the last 1, 3, 6,
or 24 hours) by specifying a `timeRange` value.

```bash
curl --location -X POST 'https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/logs/download' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer myAccessToken' \
--data '{
    "resourceType": "DLB_LOGS",
    "resourceName": "myDlbName",
    "queryType": "RELATIVE",
    "timeRange": "LAST_3_HOURS",
    "maxRows": 500000,
    "validityMinutes": 60
}'
```

### Validations

These validations apply to the request:

- `resourceType` is a required parameter and must be `DLB_LOGS`.

- `resourceName` is a required parameter and must be a valid DLB name associated with the requesting
  organization.

- `queryType` is a required parameter and must be `RELATIVE` or `ABSOLUTE`. If `queryType` is
  `RELATIVE`, `timeRange` is a required parameter and must be one of:

  - `LAST_1_HOUR`

  - `LAST_3_HOURS`

  - `LAST_6_HOURS`

  - `LAST_24_HOURS`

- `validityMinutes` is an optional parameter. Default value is 60 minutes. Allowed range is 10 to
  1440 minutes.

- `maxRows` is an optional parameter. Default value is 10,000. Maximum value is 500,000.

## Download Log Status API

Check the request status and retrieve the download URL when processing completes.

```bash
curl --location -X GET 'https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/logs/download/status?executionName=myDlbExecutionName' \
--header 'Authorization: Bearer myAccessToken'
```

### Validations

These validations apply to the request:

- `executionName` is a required query parameter. Use the value from the `executionName` field in the
  Initiate Download API response.

- The execution name must be valid; missing, invalid, or unknown values are rejected.

### Sample Response

While the logs are being processed, the API returns a response similar to this:

```json
{
  "message": "Log download request is being processed",
  "resourceName": "myDlbName"
}
```

### Successful Execution Response

When processing completes, the API returns a response similar to this, including the download URL:

```json
{
  "message": "DLB logs processed successfully",
  "downloadUrl": "myLogsDownloadUrl",
  "expiresIn": "60 minutes",
  "token": "myDownloadUrlToken",
  "resourceName": "myDlbName"
}
```

The `expiresIn` value defines the time window in which the download URL is valid. The `downloadUrl`
is time-sensitive, so download the logs (`.zip` file) within this window. After the validity period
ends, the URL expires and can’t be used; initiate a new download request to obtain a new URL.

The download file is provided in compressed (`.zip`) format and requires the `token` value from the
response to extract its contents. If you download the `.zip` file and retain the token before the
download URL expires, you can extract the file later. However, the token can’t be recovered after it
expires.

## Constraints

These constraints apply to DLB log downloads:

- Only one request per DLB can be executed at a time.

- If a request is in progress for a DLB and another request is made for the same DLB, the request
  fails with HTTP 429.

- Each request returns up to 10,000 most recent log rows. To retrieve more rows, specify the
  optional `maxRows` parameter in the request body (up to 500,000). To access older logs, make a
  request for a specific time range using the `ABSOLUTE` query type.

## See Also

- [Dedicated Load Balancers](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer)

<!-- document id=43a0e9f3dcc1125c2a9c448e62dbc50af2e24b45253991a8d2b1537329994e29 url=/mulesoft/current/en-us/cloudhub/ch-diagnostics-agent.md -->

---
product: CloudHub
---

# Generate Apps Diagnostics and Analyze with Einstein

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can generate diagnostics for your CloudHub apps and run an AI-powered analysis with Einstein.
Use one of these options:

- [Download diagnostics from Runtime Manager](#download-diagnostics)

- [Generate diagnostics with MuleSoft Diagnostics Agent](#run-the-mulesoft-diagnostics-agent)

## Understanding Diagnostics

Diagnostics display the Java thread dump of each CloudHub worker in each deployment. These indicate
the current state of the server, which is helpful for debugging and support. CloudHub diagnostics
include the Diagnostic Information Analysis File (DIAF).

The DIAF is a structured, standardized plain-text file. It centralizes diagnostic data and organizes
it for improved automated and manual analysis. The DIAF captures the state of events, operations,
and critical application data. See
[Mule Troubleshooting Plugin](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin).

DIAF is available for applications running on these Mule versions:

- 4.6.23 and later 4.6.x versions

- 4.9.10 and later 4.9.x versions

- 4.10.x and later

Without DIAF, CloudHub gives you a text file:
`_appName_-instance-_instanceId_-_workerNumber_-diag.txt`. When DIAF is included, you get a `.zip`
file instead. Open the file in a text editor or unzip the archive as needed.

## Download Diagnostics from Runtime Manager

To download diagnostics from Runtime Manager:

1.  In the **Deployments** section, select the date and worker for which you want to download
    diagnostics.

2.  Click the download icon for the worker.

3.  Select **Diagnostics**.

To download a diagnostics file directly, use this URL:

`api/v2/organizations/{{orgId}}/environments/{{envId}}/applications/{{appName}}/instances/{{instanceId}}/diagnostics`

### Analyze Diagnostics with Einstein

Before analyzing diagnostics with Einstein:

- Connect your MuleSoft organization to a Salesforce account.

- Enable Agentforce for your organization. See
  [Enable Agentforce for Your Anypoint Platform Organization](https://docs.mulesoft.com/access-management/enabling-generative-ai#enable-einstein-anypoint).

- Enable Einstein entitlement for your Anypoint Platform organization. See
  [Enable Einstein Entitlement and Routing in Anypoint Platform](https://help.salesforce.com/s/articleView?id=platform.mulesoft_enable_einstein_anypoint_platform.htm&type=5).

- Verify that you have either the Mule Developer Generative AI User or Organization Administrator
  role.

- Update your Mule runtime to 4.6.23 LTS, 4.9.10 LTS, 4.10 Edge, or later.

- Verify that your Mule application is running.

### Run Analyze with Einstein

To run and download the Einstein analysis:

1.  From Anypoint Platform, select **Runtime Manager** > **Applications**.

2.  Select the app name.

3.  In the navigation menu, select **Logs**.

4.  In the **Deployments** section, select the date and worker for which you want to run the
    analysis.

5.  Click the download icon for the worker and select **Analyze with Einstein**.

6.  After the process completes, click the download icon to download an `.html` file containing the
    analysis.

## Generate Diagnostics with MuleSoft Diagnostics Agent

On the Runtime Manager **Diagnostics** page, run the MuleSoft Diagnostics Agent to generate
diagnostics on demand for a chosen instance. Download the diagnostics for manual inspection, or
**Analyze with Einstein** (or both).

1.  From Anypoint Platform, select **Runtime Manager** > **Applications**.

2.  Select the app name.

3.  In the navigation menu, select **Diagnostics**.

4.  Select an active instance from the dropdown list.

5.  Click the **Analyze & Troubleshoot** dropdown. You have these options:

    - Select **Generate Mule Diagnostics** to generate and download the diagnostics for manual
      inspection.

      1.  Click **Download** to download the Mule diagnostics files.

    - Select **Analyze with Einstein** to generate the Mule diagnostics and run the analysis
      simultaneously.

      1.  Click **View Analysis** to open the analysis page.

### Generate Mule Diagnostics

When you choose **Generate Mule Diagnostics** and click **Download**, you get a `.zip` file. The
archive contains:

Mule Thread Dumps

A thread dump is a snapshot of all the threads in an instance that shows the current state of the
server.

Diagnostic Information Analysis File (DIAF)

The DIAF is a structured, standardized plain-text file. It centralizes diagnostic data and organizes
it for improved automated and manual analysis. The DIAF captures the state of events, operations,
and critical application data. See
[Mule Troubleshooting Plugin](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin).

> [!NOTE] The DIAF doesn’t replace application logs.

## Considerations and Limitations

The MuleSoft diagnostics agent uses Einstein generative AI. Limits for running analyses apply per
application and per organization:

- 10 analyses per application, per hour

- 50 analyses per organization, per hour

- 50 analyses per application, per day

- 200 analyses per organization, per day

CloudHub retains Mule diagnostics for 30 days or up to 150 MB.

## See Also

- [CloudHub API Reference](https://docs.mulesoft.com/cloudhub/cloudhub-api-reference#diagnostics)

- [Understanding Diagnostic Information Analysis File (DIAF)](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin#understanding-diagnostic-information-analysis-file-diaf)

- [View Log Data](https://docs.mulesoft.com/cloudhub/viewing-log-data)

- [Export Data to External Analytics Tools](https://docs.mulesoft.com/runtime-manager/sending-data-from-arm-to-external-analytics-software)

- [Monitor Applications and Servers](https://docs.mulesoft.com/runtime-manager/monitoring)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

<!-- document id=d45fd42183f78df1531788579921a8e7b6258f27fcdd9a924ece83af0b33131c url=/mulesoft/current/en-us/cloudhub/cloudhub-impaired-worker.md -->

---
product: CloudHub
---

# Impaired Worker Monitoring

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

CloudHub continuously verifies the health of the workers running Mule applications.

When a worker is impaired by hardware or software failures, including network unavailability, memory
issues, server hardware failures, or file corruption, CloudHub automatically attempts to restart the
app on a new worker.

Because CloudHub replaces impaired workers on a fixed schedule, which depends on the underlying
infrastructure, you might experience a delay between the time the new worker starts and when it
starts sharing the load. As long as the app is running on multiple workers, this delay shouldn’t
impact the application.

After the app is completely up and running, CloudHub switches the traffic to the new app instance
and deletes the old app instance, ensuring zero downtime.

If the application fails to start after five attempts, its status is **Failed** or **Unrecoverable
Runtime Error** and you must manually restart the application.

You see a notification indicating that the automatic restart occurred. The application log indicates
when an app is restarted automatically and any failures. For example:

```console
Your application was running on an impaired worker instance. To avoid any downtime, the platform has restarted the application.
```

> [!NOTE] The automatic worker-restart functionality is different from the automatic
> application-restart functionality, which is configurable using the **Automatically restart
> application when not responding** option on the **Settings** page for the app. CloudHub
> automatically attempts to restart impaired workers, regardless of the application-restart setting.

## Scheduled Maintenance Activities

CloudHub checks for these scheduled maintenance activities on the worker infrastructure that can
cause potential downtime for the running applications: reboot, stop, start, or replacement of the
instances. To ensure zero downtime, CloudHub schedules the app to restart automatically on a new
worker before the maintenance occurs.

You can restart your apps manually at your convenience or let CloudHub restart the app
automatically.

One month before the scheduled restart, the notification (bell) icon in the top right of both the
**Applications** page and the **Settings** page for the application turns red to indicate that you
have a new notification:

![Notification icon on the \*Settings\* page for the application](/mulesoft/current/en-us/cloudhub/_images/cloudhub-notification-icon.png)

Figure 1. The arrow shows the notification icon on the **Settings** page for the application.

Click the icon to display the notification, which includes the date that CloudHub will automatically
restart the worker.

CloudHub displays a reminder notification one week before automatic application restart.

## See Also

- [Notifications on Runtime Manager](https://docs.mulesoft.com/cloudhub/notifications-on-runtime-manager)

- [Application Monitoring and Automatic Restarts](https://docs.mulesoft.com/cloudhub/worker-monitoring)

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)

<!-- document id=2406adaf02955191d83da2ddd059c774ed22465f342d03b0d0be3231cb76ed9a url=/mulesoft/current/en-us/cloudhub/custom-log-appender.md -->

---
product: CloudHub
---

# Integrate with Your Logging System Using Log4j

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can disable CloudHub logs and integrate your CloudHub application with your logging system by
using the Log4j configuration. After you configure logs to flow to both your log system and
CloudHub, disable the default CloudHub application logs.

## Requirements and Restrictions

- This feature is available only on request.

  If you do not see the **Disable CloudHub logs** option in Runtime Manager, you can request it on
  [Salesforce Help](https://help.salesforce.com/).

- MuleSoft Support doesn’t provide assistance for implementing custom logging configurations or
  resolving issues caused by custom logging configurations.

- MuleSoft is not responsible for issues arising from misconfiguration of your Log4j appender,
  including these or other issues:

  - Lost logging data

  - Performance degradation

  - Running out of disk space

- Do not use synchronous log appenders.

  You can use only asynchronous log appenders.

- When you disable CloudHub logs:

  - Only the system logs are available in Runtime Manager.

    System logs provide the status of your worker deployment and whether your application started
    correctly, but do not provide application logs. For application worker logs, check the logging
    system for your application.

  - You cannot download application worker logs from the **Applications > Logs** page.

  - CloudHub warns you that logs are not available.

- You cannot forward system logs (`mule_ee.log`) to external logging solutions the same way as
  application logs.

## Create Your Log4j Configuration

For logs to both flow to your logging system and be viewable in CloudHub, configure the CloudHub
Log4j appender.

You can use any Log4j appender. For information about configuring `log4j2.xml`, see the
[Log4j Configuration Syntax](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax).

To enable the Log4j appender, update the `log4j2.xml` configuration file with your logger settings
and include the Log4j appenders `Log4J2CloudhubLogAppender` and `RollingFile`. In Anypoint Studio,
the `log4j2.xml` file is located in the `src/main/resources` directory.

The two example Log4j appenders in the `log4j2.xml` file are:

Log4J2CloudhubLogAppender

Sends log data to CloudHub.

RollingFile

Sends log data to the filesystem of the VM.

> [!WARNING] You must include the appenders in your custom configurations in the `log4j2.xml` file
> to enable MuleSoft Support team visibility into the logs.

```xml
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO" name="cloudhub" packages="com.mulesoft.ch.logging.appender">
    <Appenders>
        <RollingFile name="FILE"
                     fileName="/opt/mule/mule-CURRENT/logs/mule-${sys:domain}.log"
                     filePattern="/opt/mule/mule-CURRENT/logs/mule-${sys:domain}-%i.log">

            <PatternLayout pattern="[%d{MM-dd HH:mm:ss.SSS}] %-5p %c{1} [%t]: %m%n"/>
            <DefaultRolloverStrategy max="10"/>
            <Policies>
                <SizeBasedTriggeringPolicy size="10 MB" />
            </Policies>
        </RollingFile>
        <Log4J2CloudhubLogAppender name="CLOUDHUB"
                addressProvider="com.mulesoft.ch.logging.DefaultAggregatorAddressProvider"
                applicationContext="com.mulesoft.ch.logging.DefaultApplicationContext"
                appendRetryIntervalMs="${sys:logging.appendRetryInterval}"
                appendMaxAttempts="${sys:logging.appendMaxAttempts}"
                batchSendIntervalMs="${sys:logging.batchSendInterval}"
                batchMaxRecords="${sys:logging.batchMaxRecords}"
                memBufferMaxSize="${sys:logging.memBufferMaxSize}"
                journalMaxWriteBatchSize="${sys:logging.journalMaxBatchSize}"
                journalMaxFileSize="${sys:logging.journalMaxFileSize}"
                clientMaxPacketSize="${sys:logging.clientMaxPacketSize}"
                clientConnectTimeoutMs="${sys:logging.clientConnectTimeout}"
                clientSocketTimeoutMs="${sys:logging.clientSocketTimeout}"
                serverAddressPollIntervalMs="${sys:logging.serverAddressPollInterval}"
                serverHeartbeatSendIntervalMs="${sys:logging.serverHeartbeatSendIntervalMs}"
                statisticsPrintIntervalMs="${sys:logging.statisticsPrintIntervalMs}">

            <PatternLayout pattern="[%d{MM-dd HH:mm:ss}] %-5p %c{1} [%t]: %m%n"/>
        </Log4J2CloudhubLogAppender>
    </Appenders>
    <Loggers>
        <AsyncRoot level="INFO">
            <AppenderRef ref="FILE"/>
            <AppenderRef ref="CLOUDHUB"/>
        </AsyncRoot>
        <AsyncLogger name="com.gigaspaces" level="ERROR"/>
        <AsyncLogger name="com.j_spaces" level="ERROR"/>
        <AsyncLogger name="com.sun.jini" level="ERROR"/>
        <AsyncLogger name="net.jini" level="ERROR"/>
        <AsyncLogger name="org.apache" level="WARN"/>
        <AsyncLogger name="org.apache.cxf" level="WARN"/>
        <AsyncLogger name="org.springframework.beans.factory" level="WARN"/>
        <AsyncLogger name="org.mule" level="INFO"/>
        <AsyncLogger name="com.mulesoft" level="INFO"/>
        <AsyncLogger name="org.jetel" level="WARN"/>
        <AsyncLogger name="Tracking" level="WARN"/>
    </Loggers>
</Configuration>
```

> [!WARNING] If you need to use
> [scripts](https://logging.apache.org/log4j/2.x/manual/configuration.html#scripts) in your
> `log4j2.xml` custom configuration, make sure to enable the languages you use by setting the
> `log4j2.Script.enableLanguages` system property accordingly. You can enable multiple languages by
> providing a comma-separated list of values. For example,
> `log4j2.Script.enableLanguages=js,groovy`.

## Enable Custom Log4j Configurations in CloudHub

After you configure the Log4j appender, deploy the application to CloudHub and follow these steps to
disable CloudHub logs:

1.  From Anypoint Platform, select **Runtime Manager**.

2.  Click **Applications** in the left menu.

3.  Click the **Type** column to display the details pane for the application.

4.  Click **Manage Application**.

5.  In the **Settings** page, click **Disable CloudHub logs**:

    ![Disable CloudHub logs option in the Applications Settings page](/mulesoft/current/en-us/cloudhub/_images/cloudhub-disable-logs.png)

    Figure 1. The arrow shows the **Disable CloudHub logs** option in the **Settings** page.

6.  In the **Disabling CloudHub logs** confirmation window, select the checkboxes to verify that you
    want to disable CloudHub logs:

    ![Disabling CloudHub logs confirmation window](/mulesoft/current/en-us/cloudhub/_images/cloudhub-disable-logs-verify.png)

    Figure 2. The screen shows the **Disabling CloudHub logs** confirmation window.

7.  Click **Apply Changes**.

8.  Review your application settings to ensure they are correct.

9.  Click **Apply Changes** to restart your application.

After your application starts, logs start flowing to your custom Log4j appender and are viewable on
your target logging system.

## See Also

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

<!-- document id=c03afc5e7bbd8ea3e536ae2392f6bf52fab13bb69624478ff532888c6496289f url=/mulesoft/current/en-us/cloudhub/cloudhub-log-search-syntax.md -->

---
product: CloudHub
---

# Log Search Query Syntax

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

In addition to using the query builder and facet search user interface in Runtime Manager log
search, you can use the log search query language.

## Search Terms

Search terms consist of terms and operators. Search terms can be either single terms, such as
"hello" or phrases, such as "hello dolly".

You can combine multiple terms with boolean operators to form complex queries.

## Term Modifiers

You can modify query terms using the log search query language to provide a wide range of searching
options.

## Wildcard Searches

You can use single and multiple character wildcard searches within single terms.

To perform a single character wildcard search use the `?` symbol. The single character wildcard
search looks for terms that match the single character replaced by `?`. For example, to search for
"text" or "test" you can use the search:

`te?t`

To perform a multiple-character wildcard search, use the \* symbol. Multiple-character wildcard
searches look for zero or more characters. For example, to search for test, tests, or tester, use
the search:

`test*`

You can also use the wildcard searches in the middle of a term, for example: `te*t`.

## Boolean Operators

Boolean operators allow terms to be combined through logic operators. Log search query language
supports `AND`, `+`, `OR`, `NOT` and `-` as Boolean operators.

> [!NOTE] Boolean operators must be ALL CAPS.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Boolean Operator</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>AND</code></p></div></div></td><td><div><div><p>The <code>AND</code> operator matches documents where both terms exist anywhere in the text of a single document. This is equivalent to an intersection using sets.</p></div></div></td><td><div><div><p>To search for documents that contain "anypoint monitoring" use the query: <code>"anypoint monitoring" AND "results"</code></p></div></div></td></tr><tr><td><div><div><p><code>OR</code></p></div></div></td><td><div><div><p>The <code>OR</code> operator is used by default if there is no Boolean operator inserted between two terms. The <code>OR</code> operator links two terms and returns a matching document if either of the terms exists in a document. This is equivalent to a union using sets. The symbol <code>| |</code> can be used in place of the word <code>OR</code>.</p></div></div></td><td><div><div><p>To search for documents that contain either "monitoring anypoint" or just "monitoring" use the query:</p></div><div><p><code>"monitoring anypoint" monitoring</code></p></div><div><p>or</p></div><div><p><code>"monitoring anypoint" OR monitoring</code></p></div></div></td></tr><tr><td><div><div><p><code>NOT</code></p></div></div></td><td><div><div><p>The <code>NOT</code> operator excludes documents that contain the term after <code>NOT</code>. This is equivalent to a difference using sets. The symbol <code>!</code> can be used in place of the word <code>NOT</code>.</p></div></div></td><td><div><div><p>To search for documents that contain "anypoint monitoring" but not "functional", use the query: <code>"anypoint monitoring" NOT "functional"</code><br></p></div><div><div data-type="NOTE">The <code>NOT</code> operator can’t be used with just one term. For example, the following search returns no results:<br><code>NOT "functional"</code></div></div></div></td></tr><tr><td><div><div><p><code>+</code></p></div></div></td><td><div><div><p>Requires that the term after the <code>+</code> symbol exists somewhere in the field of a single document.</p></div></div></td><td><div><div><p>To search for documents that must contain "anypoint" and may contain "monitoring" use the query:</p></div><div><p><code>+anypoint monitoring</code></p></div></div></td></tr><tr><td><div><div><p><code>-</code></p></div></div></td><td><div><div><p>Excludes documents that contain the term after the <code>-</code> symbol.</p></div></div></td><td><div><div><p>To search for documents that contain "anypoint monitoring" but not "results" use the query:<br></p></div><div><p><code>"anypoint monitoring" -"results"</code></p></div></div></td></tr></tbody></table>

## Special Characters

You can escape special characters that are part of the query syntax. The current list of supported
special characters includes:

`+ - && || ! ( ) { } [ ] ^ " ~ * ? : \ < >`

To escape these characters, use the `\` before the character. For example, to search for (1+1):2 use
the query:

`\(1\+1\)\:2`

## Search Fields

Specify a field name or use the default when performing a search. The field name and default field
are specific to the search implementation.

Search any field by typing the field name, followed by a colon, and then the term you are looking
for. For example, to find logs with a message that contains "called the function Value Selector" in
the app "my-app", enter either of the following:

- `appId: "my-app" AND message: "called the function Value Selector"`

- `appId: "my-app" AND "called the function Value Selector"`

The default field, `message`, does not require a field indicator in the query.

<!-- document id=08a1911d8881547c69371dd960b0ba5027edf1e3b564ad2fe352775bf182b174 url=/mulesoft/current/en-us/cloudhub/maintenance-and-upgrade-policy.md -->

---
product: CloudHub
---

# Maintenance and Upgrade Policy

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

All maintenance to the Runtime Manager console, platform services, and worker cloud (see
[CloudHub Architecture](https://docs.mulesoft.com/cloudhub/cloudhub-architecture)) is performed during the maintenance windows
specified in the [Status](https://status.salesforce.com/products/Mulesoft) page, except for critical
security issues, which are fixed immediately.

MuleSoft policy is to perform all maintenance transparently and without any downtime to your
integrations running in the worker cloud wherever possible. In cases where downtime for the console,
platform services, or workers is unavoidable, MuleSoft communicates these maintenance windows at
least eight hours in advance and typically seven days in advance, with the exception of critical
security patches, which might be fixed immediately.

View the current status and detailed service history for the Runtime Manager console, CloudHub
platform services, and the CloudHub worker cloud:

- US: [status.mulesoft.com](https://status.salesforce.com/products/Mulesoft/)

- EU: [eu1-status.mulesoft.com](https://status.salesforce.com/products/Mulesoft)

- MuleSoft Government Cloud:
  [gov-status.mulesoft.com](https://status.salesforce.com/products/Mulesoft)

## See Also

- [Product Versioning and Back Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf)

<!-- document id=845342dfcf94856b882f6cf74ae127838a62ba001b1e0332f37bb192d1997567 url=/mulesoft/current/en-us/cloudhub/managing-application-data-with-object-stores.md -->

---
product: CloudHub
---

# Manage Application Data Storage with Object Stores

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

CloudHub includes application data storage for each application it manages. This data is accessible
through the Mule object store and Object Store v2 functionality.

Object stores can be used to store anything, but two of the main uses are:

- Storing synchronization state: Your application might need to keep track of the last synchronized
  record, so that the next time the application synchronizes, it can resume where it left off.

- OAuth tokens: OAuth-enabled connectors can store tokens inside an object store with a few lines of
  configuration code.

Your application can also store custom integration data as well, within the limits outlined below.

> [!NOTE]
>
> - Object stores are handled in the way described in this document only for applications deployed
>   to CloudHub workers. For applications that you deploy via the Runtime Manager to local servers,
>   you must handle the storage of data in your own repository. See
>   [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies) for more details.
>
> - All data in Object Store v1 is handled by servers in the **US-East zone**, regardless of what
>   zone your application is deployed to. This may impact performance.
>
> - [Object Store v2](https://docs.mulesoft.com/object-store/osv2-faq) expands the number of cloud object store regions and
>   object store capabilities.

> [!IMPORTANT] CloudHub clears local disk storage when an app restarts or redeploys. Because Object
> Store v1 writes to local disk, data isn’t preserved, even if you configure `persistent="true"`.
>
> In Anypoint Studio and standalone Mule runtimes, the local file system persists, so object stores
> retain data across restarts. CloudHub workers use volatile disk storage.
>
> To persist data across restarts, use [Object Store v2](https://docs.mulesoft.com/object-store/) to store data externally.

## Store and Retrieve Data

To work with application data inside a Mule flow, use the Object Store connector. The connector
provides operations to store, retrieve, list, and remove data from a Runtime Manager Object Store.
The Object Store connector works with both Object Store v1 and Object Store v2.

### Retrieve OAuth Data

For information on how to retrieve OAuth tokens, see [OAuth Module](https://docs.mulesoft.com/oauth-module/latest/).

## View Application Data

To view application data in the object store, click your application name in Runtime Manager and
then click **Manage Application** > **Object Store**:

![Object Store in the left navigation pane](/mulesoft/current/en-us/cloudhub/_images/cloudhub-object-store-rtm.png)

Figure 1. The arrow shows **Object Store** in the left navigation pane.

If the application uses Object Store v1, the label is **Application Data**.

> [!TIP] To make properties secure so that they’re not visible using the Runtime Manager UI or
> anywhere else, see [Safely Hide Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties).

## Semantics and Storage Limits

Object Store v1 provides read-after-write consistency and the last write wins for updates.

Object Store v1 has a:

- Maximum of 100,000 keys per application

- 768 byte key size

- 1 MB value size

- 1 GB of data per application

Object Store v2:

- Unlimited number of keys per application

- Values can be up to 10 MB

- Trial level 10 TPS, premium level 100 TPS

- Keys persist for up to 30 days

- Available in [all commercially available CloudHub regions](https://docs.mulesoft.com/object-store/osv2-faq).

## Advanced Information

Internally, Mule has several different types of object stores. Runtime Manager provides Object Store
v2. These object stores are for runtime information about your application, such as those use cases
mentioned above. You can find this object store internally in the Mule Registry under the
'\_defaultUserObjectStore\` if you want to access it directly. The Object Store module and
connectors use this store to store all their data by default.

### See also

- [Object Store v1](https://docs.mulesoft.com/mule-runtime/latest/mule-object-stores)

- [Object Store v2](https://docs.mulesoft.com/object-store/)

- [Tutorial: Object Store v2](https://docs.mulesoft.com/object-store/osv2-tutorial)

- [Object Store Connector for Mule 4 in Anypoint Exchange](https://www.mulesoft.com/exchange/org.mule.connectors/mule-objectstore-connector/)

<!-- document id=e96917ceab403c5c94c56ed424d37278bbc0db16ed651c735b940ed274fe27e1 url=/mulesoft/current/en-us/cloudhub/managing-applications-on-cloudhub.md -->

---
product: CloudHub
---

# Manage Applications on CloudHub

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

After you deploy an application to [CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub), you can use the Runtime
Manager to manage your application at runtime.

Depending on if your application is deployed to [CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub) or to
[your own servers](https://docs.mulesoft.com/runtime-manager/deploying-to-your-own-servers), there is a different set of
possible actions you can perform.

> [!NOTE] This document refers to applications that are deployed through the Runtime Manager console
> to [CloudHub](https://docs.mulesoft.com/cloudhub/). To view the basic management tools that are common to all types of deployments,
> see [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications). See
> [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies) to understand the different
> deployment scenarios that the platform offers.

With applications deployed to [CloudHub](https://docs.mulesoft.com/cloudhub/) you can handle the following features:

- [Queues](https://docs.mulesoft.com/cloudhub/managing-queues)

- [Schedules](https://docs.mulesoft.com/cloudhub/managing-schedules)

- [Secure Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties)

- [Object Stores](https://docs.mulesoft.com/cloudhub/managing-application-data-with-object-stores)

- [Custom Application Alerts](https://docs.mulesoft.com/cloudhub/custom-application-alerts)

## Applications Dashboard

If you select any of the applications on the **Applications** tab, a panel opens on the right, where
you can read additional information about the application and access its settings.

![dashboard](/mulesoft/current/en-us/cloudhub/_images/dashboard-ch.png)

What this dashboard displays depends on if your application is deployed on [CloudHub](https://docs.mulesoft.com/cloudhub/) or on
[Mule](https://docs.mulesoft.com/runtime-manager/managing-applications-on-your-own-servers).

Applications deployed to CloudHub display the status, the time of the last modification, and the
deployed application ZIP file, which you can change from this menu through the **Choose File**
button.

They also display additional info about the CloudHub worker they run on, namely the Mule version,
worker size, worker amount and region. You will also see buttons that allow you to view logs and
insights, and enter the **Manage Application** menu.

## Access App Settings

1.  Sign in to the [Anypoint Platform](https://anypoint.mulesoft.com) and view the **Applications**
    tab of the Runtime Manager.

2.  Select one of your CloudHub running applications to open a panel on the right side.

3.  In the panel on the right, click the **Manage Application** button to open up the application’s
    settings.

![manage app](/mulesoft/current/en-us/cloudhub/_images/cloudhub-manage-application.png)

In this menu you will be able to change most of the settings you can configure when deploying. For
applications on CloudHub, you will also be able to access Log data, Insights, Alerts, queues, set up
and manage schedules and application data. You can also see the **Alerts History** tab, which
displays a record of the triggered alerts on the app. See
[Alerts on Runtime Manager](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager) for more on this.

> [!IMPORTANT] You cannot change the name of an app after you deploy it. To change the name, you
> must delete and redeploy the app using the new name.

## Monitor Applications

If your application is deployed to CloudHub, a rich set of tools exists for monitoring events that
may occur on your application and the performance of the virtual servers it’s running on. See
[Monitoring Applications](https://docs.mulesoft.com/runtime-manager/monitoring) for more details.

## Redeploy to a Different Region

If you have global deployment enabled on your account, you can select a different region for your
CloudHub deployments. . On the settings page, pick the **Runtime** section, and then select the
desired region from the drop-down menu. . After you select the region, click the **Apply changes**
button, which restarts your application in the new region.

![SetRegion](/mulesoft/current/en-us/cloudhub/_images/setregion.png)

Administrators can [set the default region](https://docs.mulesoft.com/cloudhub/managing-cloudhub-specific-settings) on the
**Organization** tab in Account Settings, but that configuration can be overridden when the
application is deployed, if necessary.

> [!NOTE] Domains for applications deployed to Europe automatically update to
> `http://myapplicationdomain.eu.cloudhub.io`.

## Scale Your Application

You can dynamically scale your applications by selecting options from the **Worker size** drop-down
menu, and clicking the **Apply Changes** button. Your application uses the worker size and number of
workers that you specify. For more information about deploying to multiple workers, see
[CloudHub Workers](https://docs.mulesoft.com/cloudhub/cloudhub-architecture#cloudhub-workers).

![WorkerSize](/mulesoft/current/en-us/cloudhub/_images/workersize.png)

> [!IMPORTANT] By default, all applications are limited to no more than four workers of any size.
> Free and professional accounts are limited to a single worker per app. If you need more workers or
> more total vCore capacity, update your subscription. If you need more than four workers for a
> single domain, [Salesforce Help](https://help.salesforce.com) directly.

## Download a Copy of Your Deployed Application

The most recently deployed application archive is always available for download from the console. To
download the application archive, click the link in **Application File** on the application
**Settings** page.

![DownloadAppFile](/mulesoft/current/en-us/cloudhub/_images/downloadappfile.png)

> [!NOTE] If you can see the application name, but the name is not a live link, your administrator
> has disabled application downloads for users with developer and support account types. Contact
> your administrator if you need a copy of the application.

## Update Your Application

If you made changes to your applications and want to upload a new version:

1.  Click **Choose file** on the Deployment screen for that application. The new filename appears in
    italicized text.

2.  Click **Apply changes** to use the new file for deployment.

    Within a few seconds, your application successfully redeploys. While redeploying, the
    application status indicator changes to blue, and then turns green after the deployment
    completes.

3.  You can click **Logs** to see a live redeployment of your application.

After successfully starting a new worker with the application’s latest version, CloudHub overwrites
the previous version and you can no longer download the previous archive or revert back to the
previous version of application.

### Update the Mule Version for an Application

If your application is running on an older version of Mule, you can upgrade your application to use
the latest Mule version. To update, click **Runtime version**, select the version labeled **New**,
and then click **Apply Changes**.

![New label for updating runtime version for an app](/mulesoft/current/en-us/cloudhub/_images/apps-update-runtime-version.png)

Figure 1. The arrow shows the **New** label for the **Runtime version** on the application
**Settings** page.

To update multiple apps at the same time, use the
[CloudHub API Bulk Action](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/1.0.13/console/method/%231545/)
operation.

> [!NOTE] After End of Extended Support for Mule runtime 4.3 and 4.4, Mule applications deployed to
> CloudHub or CloudHub 2.0 environments are stopped.

### Zero Downtime Updates with CloudHub

CloudHub supports updating your application so users of your HTTP APIs experience zero downtime.
During your application update, CloudHub keeps both the old version and the new version of your
application running. Your domain points to the old version of your application until the new version
is fully started. This allows you to keep servicing requests from your old application while the new
version of your application is starting.

<table><colgroup><col> <col></colgroup><thead><tr><th>Icon</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><span><img src="https://docs.mulesoft.com/cloudhub/_images/image2014-10-24-16-3a43-3a57.png" alt="image2014-10-24+16:43:57"></span></p></div></div></td><td><div><div><p>The application update is deploying.</p></div></div></td></tr><tr><td><div><div><p><span><img src="https://docs.mulesoft.com/cloudhub/_images/image2014-10-24-16-3a44-3a47.png" alt="image2014-10-24+16:44:47"></span></p></div></div></td><td><div><div><p>The updated version of the application didn’t start correctly. Mule shuts down the new version and leaves the old application running.</p></div></div></td></tr></tbody></table>

> [!IMPORTANT] If an application uses static IPs, updates might cause up to one minute of downtime
> while CloudHub reassigns the static IP address from the previous version of the application to the
> new version. Ensure that the client includes the necessary retry mechanisms to account for the
> downtime.

> [!NOTE] Cancelling a deployment and starting a new one for the same application before the
> cancellation is complete can lead to a one-to-three-minute downtime.

## Static IPs

CloudHub supports allocating a static IP for applications so that they can be allowlisted for other
services. To enable a static IP for your application, go to the **Static IPs** tab on your
application settings page, then enable the **Use Static IP** checkbox. A static IP is allocated to
your application and displayed in the table below; it will be used by the application when it
restarts. If your application is not running, you can pre-allocate a static IP before starting the
application. For details, see
[Static IPs Tab Settings](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub#static-ips-tab-settings).

> [!IMPORTANT] If your application is deleted, the static IP will be lost and you must request a new
> one.

## Create HTTP Services for Your Application

To make HTTP-based services available under your domain, use the `${http.port}` variable in your
configuration. For example:

```xml
<http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="${http.port}" .../>
```

CloudHub specifies this port for you and automatically load-balances your domain across the number
of workers that you specified.

## See Also

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [CloudHub](https://docs.mulesoft.com/cloudhub/)

- [Develop Applications for CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

- [Monitor Applications](https://docs.mulesoft.com/runtime-manager/monitoring)

- [Clustering](https://docs.mulesoft.com/cloudhub/cloudhub-fabric)

- [Manage Queues](https://docs.mulesoft.com/cloudhub/managing-queues)

- [Manage Schedules](https://docs.mulesoft.com/cloudhub/managing-schedules)

- [Manage Application Data with Object Stores](https://docs.mulesoft.com/cloudhub/managing-application-data-with-object-stores)

- [Anypoint Platform CLI](https://docs.mulesoft.com/anypoint-cli/latest/)

- [Safely Hide Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties)

<!-- document id=f298b67b33b4d9ac7cb1549f3f2ba082d818f17c6bba0dd80f3cecd4c9184d2a url=/mulesoft/current/en-us/cloudhub/managing-cloudhub-specific-settings.md -->

---
product: CloudHub
---

# Manage CloudHub-Specific Settings

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This document describes Anypoint Platform settings relevant to applications deployed to CloudHub.

Manage these settings from the [**Access Management**](https://docs.mulesoft.com/access-management/) in your Anypoint
Platform.

> [!NOTE] Your account must have the role **Cloudhub administrator** or **Organization
> Administrator** to edit access management settings.

## Manage Regions

If Global Deployment is enabled on your account, you can also set the default region. The region
auto-populates in the deployment screen settings for all applications deployed by users in your
organization, and it can be adjusted at the application level if necessary for individual
deployments.

Access this menu by clicking the gear icon next to your user name at the top of the screen and then
picking the **CloudHub** link, under **Settings** in the left menu.

![GearGeneral](/mulesoft/current/en-us/cloudhub/_images/geargeneral.png)

> [!NOTE] If you don’t currently have Global Deployment enabled on your account but would like it,
> please contact your MuleSoft account manager.

See [Regional Services](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide#regional-services) for a list of available
regions.

## CloudHub Subscription

When you first sign up for CloudHub, you’re automatically added to the Free plan (subscription
level). To upgrade to a paid plan, please contact your MuleSoft account manager.

To see your subscription level and usage, click the gear icon at the top of the screen and click
**Subscription**:

![Subscription](/mulesoft/current/en-us/cloudhub/_images/subscription.png)

The following **Subscription** example shows the use of 13.1 of possible 20 vCores in the Production
environment and 2 of 20 vCores in use in the Sandbox environment:

![SubscriptionLevel](/mulesoft/current/en-us/cloudhub/_images/subscriptionlevel.png)

> [!IMPORTANT] The number of workers is not the same as the number of applications. For more
> information about worker sizing, see [High Availability](https://docs.mulesoft.com/cloudhub/cloudhub-fabric) and
> [CloudHub Workers](https://docs.mulesoft.com/cloudhub/cloudhub-architecture#cloudhub-workers).

Only running applications count for vCores processing usage. `Stopped` applications do not consume
vCore availability.

## Changing Your Plan

To change your plan, you can contact your account representative or your Customer Success Manager.

## See Also

- [Environments](https://docs.mulesoft.com/access-management/environments)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [CloudHub Plans and Pricing](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/mulesoft-cloud-offerings-SLA-forSalesforce-uMSA.pdf)

<!-- document id=37a0bc8aaa4821001b1cbc70998a7b1fee044fd4327cbbacaa7f6eb0080c3d9e url=/mulesoft/current/en-us/cloudhub/cloudhub-manage-props.md -->

---
product: CloudHub
---

# Manage Properties for Applications on CloudHub

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

In a CloudHub deployment, you can add properties to an application by using either Anypoint Runtime
Manager or a properties file.

If you set properties both in the properties file in your application and in Runtime Manager, the
values set in Runtime Manager always override the values in the properties file when your
application deploys.

## Add Application Properties in Runtime Manager

The easiest way to load properties to applications deployed to CloudHub is to use the **Properties**
tab in Anypoint Runtime Manager.

To add properties:

1.  From Anypoint Platform, select **Runtime Manager**.

2.  Click the **Applications** tab.

3.  Click the **Status** column to display the details pane.

4.  Click **Manage Application**.

5.  On the **Settings** page, click the **Properties** tab:

    ![\*Properties\* tab](/mulesoft/current/en-us/cloudhub/_images/cloudhub-app-props.png)

    Figure 1. The screenshot shows (**1**) the **Properties** tab, (**2**) the **List** button,
    (**3**) the key and value fields, and (**4**) the **X** icon on the application **Settings**
    page.

6.  Click **List**.

    Alternatively, you can enter the key-value pair in the **Text** field in this format:
    `key=value`.

7.  Enter the property name in the key field.

8.  Enter the property value in the value field.

    If the save password feature of Chrome is enabled and includes a username for
    `anypoint.mulesoft.com` that matches the contents of the key field, Chrome overwrites the value
    field with the stored password associated with that username. To work around this limitation,
    use Chrome in incognito mode or use another browser.

9.  If you want to change a key or value, edit the text in the field.

10. If you want to delete a property, click **X**.

11. Click **Apply Changes**.

12. Select **Restart** from the menu in the top right to restart the application.

### Example: Using Properties to Set Environment Variables

You can specify Java system environment variables, which function the same as adding environment
variables when you deploy to an on-premises server.

You can also configure environment variables for your application. Properties enable you to
externalize settings that change depending on the environment you’re deploying to. For example, if
you use a Mule application locally, you might configure your database host to be `0.0.0.0`. If you
deploy the same app to CloudHub, you might configure the database host to be an Amazon RDS server.

To create or set an environment variable using an application property:

1.  From Anypoint Platform, select **Runtime Manager**.

2.  Click the **Applications** tab.

3.  Click the **Status** column to display the details pane.

4.  Click **Manage Application**.

5.  On the **Settings** page, click the **Properties** tab:

6.  Define the variable by entering it in the **Text** view, in `key=value` format:

    ![\*Properties\* tab on the \*Settings\* page](/mulesoft/current/en-us/cloudhub/_images/rtm-env-variables.png)

    Figure 2. The arrow shows the variable on the **Properties** tab of the application **Settings**
    page.

    > [!NOTE] In the **Text** view, use the backslash character (`\`) as an escape character. For
    > example, to use `:` in a key or value, use `\:` in the syntax. To use `\` in a key or value,
    > use `\\` in the syntax. **List** view syntax requires no escape character.

7.  Use the environment variable in your Mule app configuration.

## Add Application Properties Using a Properties File

You can add properties to an app by including property placeholder YAML file in the deployable
application archive file. See
[Configuring Properties](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties).

CloudHub then loads these properties into the application when the application starts.

Although this method is not the best practice on CloudHub (because CloudHub **Properties** tab
values override any with the same name in the file), you can work around this by changing options in
the Mule app.

To prevent CloudHub properties from overriding properties bundled with the deployable archive,
change options in the `property-placeholder` element in the Mule application. For more information
about nondefault property placeholder options, see the
[Spring documentation on Property Placeholder options](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/support/PropertySourcesPlaceholderConfigurer.html).

## CloudHub Reserved Properties

CloudHub reserves a set of properties and prevents apps from overwriting the values of those
properties. If an application attempts to assign a value to a reserved property, CloudHub doesn’t
use the assigned value. Instead, it returns the value as set internally, without throwing an error
or exception, and adds a warning message to the log.

Applications can reference reserved properties, for example, to retrieve the application name or
deployment region. Use the `${csorganization.id}` and `${environment.id}` properties to retrieve
those values if your app makes Anypoint Platform API calls. Use `${worker.id}` to identify each
worker in a multiworker application.

> [!IMPORTANT] Do not use the `${spring.profiles.active}` and `${logging.*}` properties.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Property</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>${java.vendor}</code></p></div></div></td><td><div><div><p>Vendor providing the JVM</p></div></div></td><td><div><div><p>Oracle Corporation</p></div></div></td></tr><tr><td><div><div><p><code>${java.runtime.name}</code></p></div></div></td><td><div><div><p>JVM name</p></div></div></td><td><div><div><p>Java™ SE Runtime Environment</p></div></div></td></tr><tr><td><div><div><p><code>${java.version}</code></p></div></div></td><td><div><div><p>JVM version, excluding the dot (point) release.</p></div><div><p>If a CloudHub runtime release upgrades the JDK, this value changes.</p></div></div></td><td><div><div><p>1.8.0_141</p></div></div></td></tr><tr><td><div><div><p><code>${csorganization.id}</code></p></div></div></td><td><div><div><p>Main or business group ID</p></div></div></td><td><div><div><p>09396371-2cd4-412e-8d08-4356dd3e7bfc</p></div></div></td></tr><tr><td><div><div><p><code>${environment.id}</code></p></div></div></td><td><div><div><p>Environment ID</p></div></div></td><td><div><div><p>52a69d49e4b0e3c7324ae5b6</p></div></div></td></tr><tr><td><div><div><p><code>${environment.type}</code></p></div></div></td><td><div><div><p>Environment type</p></div></div></td><td><div><div><p>production</p></div></div></td></tr><tr><td><div><div><p><code>${worker.id}</code></p></div></div></td><td><div><div><p>Worker ID (for multiworker apps)</p></div></div></td><td><div><div><p>0</p></div></div></td></tr><tr><td><div><div><p><code>${domain}</code></p></div></div></td><td><div><div><p>App name</p></div></div></td><td><div><div><p><code>ch-https-41-demo</code></p></div></div></td></tr><tr><td><div><div><p><code>${fullDomain}</code></p></div></div></td><td><div><div><p>Full domain name of app</p></div></div></td><td><div><div><p><code>ch-https-41-demo.au-s1.cloudhub.io</code></p></div></div></td></tr><tr><td><div><div><p><code>${application.aws.region}</code></p></div></div></td><td><div><div><p>App deployment region</p></div></div></td><td><div><div><p><code>ap-southeast-2</code></p></div></div></td></tr><tr><td><div><div><p><code>${http.port}</code></p></div></div></td><td><div><div><p>HTTP port</p></div></div></td><td><div><div><p>8081</p></div></div></td></tr><tr><td><div><div><p><code>${https.port}</code></p></div></div></td><td><div><div><p>HTTPS port</p></div></div></td><td><div><div><p>8082</p></div></div></td></tr><tr><td><div><div><p><code>${http.private.port}</code></p></div></div></td><td><div><div><p>HTTP private port</p></div></div></td><td><div><div><p>8091</p></div></div></td></tr><tr><td><div><div><p><code>${https.private.port}</code></p></div></div></td><td><div><div><p>HTTPS private port</p></div></div></td><td><div><div><p>8092</p></div></div></td></tr><tr><td><div><div><p><code>${mule.home}</code></p></div></div></td><td><div><div><p>Absolute path to Mule installation</p></div></div></td><td><div><div><p><code>/opt/mule/mule-4.1.1</code></p></div></div></td></tr><tr><td><div><div><p><code>${spring.profiles.active}</code></p></div></div></td><td><div><div><p>Used internally, <strong>do not use</strong></p></div></div></td><td><div><div><p><code>***</code></p></div></div></td></tr><tr><td><div><div><p><code>${logging.*}</code></p></div></div></td><td><div><div><p>Used internally, <strong>do not use</strong></p></div></div></td><td><div><div><p><code>***</code></p></div></div></td></tr><tr><td><div><div><p><code>${host}</code></p></div></div></td><td><div><div><p>Used internally for the local IP address of a worker</p></div></div></td><td><div><div><p><code>10.40.122.33</code></p></div></div></td></tr><tr><td><div><div><p><code>${anypoint.url}</code></p></div></div></td><td><div><div><p>Used internally as the base Anypoint Platform URL</p></div></div></td><td><div><div><p>US: <code>https://anypoint.mulesoft.com</code></p></div><div><p>MuleSoft Government Cloud: <code>https://gov.anypoint.mulesoft.com</code></p></div></div></td></tr></tbody></table>

> [!NOTE] For proprietary reasons, MuleSoft doesn’t make public all internal, reserved properties.
> CloudHub runtime release updates might change the reserved properties.

### Non-reserved Pre-populated Properties

Mule runtime pre-populates the values for the following two properties. However, you have the option
to overwrite these pre-filled values.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Property</th><th>Description</th><th>Example</th></tr></thead><tbody><tr><td><div><div><p><code>${app.name}</code></p></div></div></td><td><div><div><p>The name of the application <code>.jar</code> file.</p></div></div></td><td><div><div><p>myApplication</p></div></div></td></tr><tr><td><div><div><p><code>${app.home}</code></p></div></div></td><td><div><div><p>The root directory of the application during run time.</p></div></div></td><td><div><div><p>/opt/mule/mule-4.3.0/apps/myApplication</p></div></div></td></tr></tbody></table>

### Example: Retrieve the Values of Reserved Properties

```xml
<set-payload value="java.vendor=${java.vendor}, java.runtime.name=${java.runtime.name}, java.version=${java.version}, application.aws.region=${application.aws.region},
      http.port=${http.port}, http.ports=${http.port}, mule.home=${mule.home}, csorganization.id=${csorganization.id}, environment.id=${environment.id},
      environment.type=${environment.type}, worker.id=${worker.id}, domain=${domain}, fullDomain=${fullDomain}" doc:name="Set Payload"/>
<logger message="#[payload]" level="INFO" doc:name="Logger"/>
```

Example output:

```console
16:33:08.572     07/02/2020     Worker-0     [cloudhub-reserved-properties].HTTP_Listener_Configuration.worker.01     INFO
   java.vendor=Oracle Corporation, java.runtime.name=Java(TM) SE Runtime Environment, java.version=1.8.0_141, application.aws.region=ap-southeast-2,
   http.port=8081, http.ports=8081, mule.home=/opt/mule/mule-4.3.0, csorganization.id=09396371-2cd4-412e-8d08-4356dd3e7bfc, environment.id=52a69d49e4b0e3c7324ae5b6,
   environment.type=production, worker.id=0, domain=cloudhub-reserved-properties, fullDomain=cloudhub-reserved-properties.au-s1.cloudhub.io
```

## See Also

- [Configuring Properties](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [Develop Applications for CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub)

- [Safely Hide Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties)

<!-- document id=0185be08ffc750094825c4e52a405fab933701b6ea27a79042cacfae675257d5 url=/mulesoft/current/en-us/cloudhub/managing-queues.md -->

---
product: CloudHub
---

# Manage Queues

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can view and control any Virtual Machine (VM) or Staged Event-Driven Architecture
([SEDA](https://en.wikipedia.org/wiki/Staged_event-driven_architecture)) queues within the flows of
your deployed applications from the **Queues** tab in Runtime Manager.

Queues are available only for applications deployed to CloudHub workers. They are not available for
applications that you deploy with the Runtime Manager to local servers. See
[Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies) for more details.

![QueuesTab](/mulesoft/current/en-us/cloudhub/_images/queuestab.png)

CloudHub automatically detects the queues from within your flow and lists them on the **Queues**
tab.

Without making any changes in the underlying application, you can:

- See the number of queued and in-flight messages on each queue.

- View a snapshot of the queue throughput for the past 24 hours.

- Clear all pending messages on a queue.

You can also enable data-at-rest encryption for your persistent queues to ensure that any shared
application data written to a persistent queue is encrypted.

## Use Cases

The **Queues** tab is useful for the following use cases:

- You want runtime visibility into the queues in your application.

- You are testing your application to observe whether messages are traveling through your queues as
  expected.

- Your application is stuck processing a message and you want to flush the messages from only that
  queue to resolve the issue.

## Enable Queues

To enable queues:

1.  Deploy an application to CloudHub that includes one or more queues.

    See [VM Connector](https://docs.mulesoft.com/vm-connector/latest/).

2.  In Runtime Manager, click the application and click **Manage Application**.

3.  Click the checkbox for **Persistent queues**.

4.  If you are enabling this setting when deploying an application, click **Deploy Application**.  
    If you are updating an existing application, click **Apply Changes**.

    ![PersistentQueuesSetOnDeploy](/mulesoft/current/en-us/cloudhub/_images/persistentqueuessetondeploy.png)

When you enable persistent queues, CloudHub replaces the default Mule runtime queue manager with a
persistent one. This manager persists all queues, regardless of in-app configuration. Affected queue
types:

- VM connector queues, whether configured as persistent or not in the application

- Internal Batch component queues

- Internal SEDA queues

## View Queues

After you enable persistent queues, click **Queues** in the left navigation menu. CloudHub lists the
queues in your application in the order they appear in your application:

![CHQConsole](/mulesoft/current/en-us/cloudhub/_images/chqconsole.png)

The name of each queue is determined by the `path` attribute of the associated VM endpoint, or, in
the case of a SEDA queue, from the flow name.

- The **Queued** column shows the number of messages currently waiting on each of the queues in your
  application.

- The **In-Flight** column indicates the number of messages being processed in the flow after that
  queue.

  The in-flight messages are still on the queue until processing is complete, then they are deleted
  from the queue.

- The **Processed Messages** column shows a thumbnail graph depicting the number of messages
  processed through each queue over the past 24 hours.

The **Queued** and **In-Flight** columns update every five seconds, and the **Processed Messages**
graph updates every five minutes.

## Clear Queues

To clear one or more queues, click the checkboxes for the queues to clear, then click **Clear**.

![CHQClearQ](/mulesoft/current/en-us/cloudhub/_images/chqclearq.png)

Runtime Manager presents a warning message that confirms which queues to clear and the duration this
process takes to occur. Click **Clear Queues** to proceed.

![CHQClear](/mulesoft/current/en-us/cloudhub/_images/chqclear.png)

After you confirm, the queues that you selected display a "Clearing queue in progress" message until
the clearing process is complete:

![CHQClearInProgress](/mulesoft/current/en-us/cloudhub/_images/chqclearinprogress.png)

Clearing a queue flushes all messages waiting in the queue and all in-flight messages. After the
queue is cleared, the queue immediately begins accepting messages again.

## Encrypt Data at Rest in Persistent Queues

You can enable data-at-rest encryption for all your persistent queues. By enabling this feature, you
ensure that any shared application data written to a persistent queue is encrypted, allowing you to
meet your security and compliance needs.

![enable+encripting](/mulesoft/current/en-us/cloudhub/_images/enable-encripting.png)

> [!IMPORTANT] If you enable encryption and then disable it, any messages that were previously
> encrypted become unreadable.

## Batch Component and Persistent Queues

If your Mule application is using a Batch component and persistent queues, you might see batch
records being processed multiple times. All batch records are stored in Amazon SQS and the
visibility of the message is set to 70 seconds by default. If your batch process takes longer than
70 seconds, batch processes might see the same message again and process it multiple times.

To avoid this issue, set the `persistent.queue.min.timeout` system parameter to a larger value in
the **Properties** tab of the application **Settings** page. For example, if your batch process
takes 30 minutes to complete, set the value to `persistent.queue.min.timeout=2700000` milliseconds
(45 Minutes). The maximum value is 43000000 milliseconds (12 hours).

## Limitations

When enabling persistent queues in your application, be aware of the following:

- Persistent queues do not guarantee one-time-only message delivery. Duplicate messages might be
  sent. If one-time-only message delivery is critical for your use case, do not enable persistent
  queues.

- If you clear a queue using the **Queues** tab, any new messages sent to the queue during the queue
  clearing process might be lost.

- Enabling persistent queues has a performance implication. Putting a small message (50kb or less)
  on a queue can take 10-20 milliseconds (ms). Taking the same message off a queue can take
  70-100ms.

## See Also

- [Persistent Queues](https://docs.mulesoft.com/cloudhub/cloudhub-fabric#persistent-queues)

- [Reliability Patterns](https://docs.mulesoft.com/mule-runtime/latest/reliability-patterns)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [Anypoint Studio](https://docs.mulesoft.com/studio/)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)

- [Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)

- [CloudHub](https://docs.mulesoft.com/cloudhub/)

- [Develop Applications for CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub)

- [CloudHub Architecture](https://docs.mulesoft.com/cloudhub/cloudhub-architecture)

- [Monitor Applications](https://docs.mulesoft.com/runtime-manager/monitoring)

- [Manage Schedules](https://docs.mulesoft.com/cloudhub/managing-schedules)

- [Manage Application Data with Object Stores](https://docs.mulesoft.com/cloudhub/managing-application-data-with-object-stores)

- [Anypoint Platform Command-Line Interface](https://docs.mulesoft.com/anypoint-cli/latest/)

- [Secure Application Properties](https://docs.mulesoft.com/cloudhub/secure-application-properties)

- [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [Penetration Testing Policies](https://docs.mulesoft.com/cloudhub/penetration-testing-policies)

<!-- document id=73c0a84d83615ff551a34da96c0b3e80c202646054d92fdc869999e9e2372fec url=/mulesoft/current/en-us/cloudhub/managing-schedules.md -->

---
product: CloudHub
---

# Manage Schedules

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can use Runtime Manager to view and control the Scheduler components within the flows in your
deployed applications. Use the **Schedules** tab in the left navigation menu to enable or disable
Scheduler elements, change the frequency, or run the scheduled job immediately, all without changing
the running application.

The **Schedules** tab is useful in the following scenarios:

- You have a job that runs nightly but you want to debug it now.

  You can trigger the job while it’s running without updating the schedule in your application.

- You want to change the schedules in your application at runtime without redeploying.

- You want to disable a scheduled job while one of the applications you are connecting to is
  undergoing maintenance.

- You want runtime visibility into the schedules in your application.

The CloudHub scheduler reads the job configuration every time it runs. When you update the scheduler
configuration, the change takes effect the next time the scheduler runs.

> [!NOTE] You cannot manage CloudHub schedules using scripts. Use the **Schedules** tab or the
> CloudHub API to manage CloudHub schedules.

> [!IMPORTANT] To view the application schedules, you must have the **Exchange Viewer** and **Read
> Applications** permissions.

## Considerations and Limitations

When designing the schedule, consider the following:

- Plan for high availability during network failures, infrastructure restarts due to hardware issues
  or scheduled maintenance, and security updates.

  During service updates or security patching, CloudHub waits two minutes for existing schedules to
  complete. After two minutes, CloudHub retriggers any incomplete schedules. Additionally, during
  zero downtime deployments, schedules whose trigger time overlaps with the deployment window might
  be triggered more than once, even if the initial execution completed successfully.

  To avoid retriggers with long-running schedules, and duplicate processing during deployment
  overlaps, make sure that the app executes the flow idempotently.

- Design your schedules to prevent duplicate data processing, as they can be triggered more than
  once due to the issues mentioned previously.

- For multi-worker apps, CloudHub guarantees that the schedule trigger executes on a single worker.

  However, subsequent triggers might execute on a different worker. CloudHub distributes multiple
  concurrent schedules across workers.

- Schedules run on a best-effort basis and aren’t guaranteed to trigger at an exact time. The
  platform evaluates due schedules on a recurring cycle, so the actual run time can drift from the
  configured interval, and the schedule can occasionally skip or merge runs under load. This drift
  is most significant at short intervals. For time-sensitive workloads where each run must occur
  close to its scheduled time, use an interval of 60 seconds or greater. If you require precise,
  fixed-interval execution, trigger the flow externally (for example, through an HTTP endpoint)
  instead of using a schedule.

- If a scheduled job is not triggered because the application is not running, CloudHub triggers the
  job as soon as it restarts.

- When a Mule 4.x app uses a schedule to trigger a flow with subflow, the scheduler waits until both
  main flow and subflow complete before scheduling the next run.

  Flow names can contain only letters (a-zA-Z), numbers (0-9), hyphen (-), underscore (\_), and
  period (.) characters. The following characters are invalid: slash (/), square brackets (\[\]),
  curly brackets ({}), hash (#), and colon (:).

- All schedules are based in the UTC timezone, regardless of the geographic region where you deploy
  the app.

## View and Manage Application Schedules in Runtime Manager

To use the scheduling feature in Runtime Manager, deploy an application that includes one or more
Scheduler elements:

![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/cloudhub/_images/cloudhub-scheduler-studio.png)

Figure 1. The arrow shows the **Scheduler** component in the Anypoint Studio canvas.

You can download this example app from Exchange.

After deploying an app to CloudHub, view and manage the Scheduler elements in Runtime Manager:

1.  Click **Applications** in the left pane, click the app, and then click **Schedules**:

    ![Logs option](/mulesoft/current/en-us/cloudhub/_images/cloudhub-scheduler-rtm.png)

    Figure 2. The screenshot shows (**1**) the **Logs** option, (**2**) the **Last Run** column, and
    (**3**) the frequency link on the **Schedules** page.

    The **Last Run** column shows the date and time each Scheduler element last ran. You can click
    **Logs** in the left navigation menu to see more information about when the jobs started and
    ended scheduled runs.

    Runtime Manager lists the Scheduler elements in the order that they appear in your application.

2.  Select the elements to manage and then:

    - Click **Run now** to override the schedule and run the job immediately.

    - Click **Disable** to suspend a Scheduler element.

      CloudHub does not run the scheduled job until you reenable it.

    - Click the frequency link in the **Schedule** column to open the schedule editor:

      ![Switch to advanced mode link in the schedule editor](/mulesoft/current/en-us/cloudhub/_images/cloudhub-scheduler-frequency.png)

      Figure 3. The arrow shows the **Switch to advanced mode** link in the schedule editor.

      In the schedule editor, change the frequency of the schedule or deselect **Enabled** to
      disable the schedule.

      The value for the frequency can be between 10 and 100 seconds.

      You can also switch to advanced mode to use cron expressions to create more specific
      schedules, such as every Thursday at 3:00 pm.

      > [!NOTE] By default, schedules run at the frequency defined in the application. When you
      > change the frequency of a schedule from Runtime Manager, the schedule runs at the frequency
      > configured in Runtime Manager even if you update and redeploy the same schedule in the
      > application JAR file.

3.  Click **Update** to save changed settings or click **Cancel** to exit without saving.

## Use Cron Expressions

With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes
between 9:00 am and 10:00 on Fridays.

To use cron expressions to specify the schedule frequency:

1.  In the schedule editor, click **Switch to advanced mode**.

2.  In the advanced mode page, click **Quick reference** to expand or collapse the table that lists
    required fields and allowed values:

    ![Quick reference toggle](/mulesoft/current/en-us/cloudhub/_images/cloudhub-scheduler-cron.png)

    Figure 4. The screenshot shows (**1**) the **Quick reference** toggle, (**2**) the **more**
    link, and the **Switch to basic mode** link on the advanced mode page.

    The cron expression in this example sets the schedule to every 10 seconds, which is the minimum
    supported frequency.

    On this page:

    - Click **more** to view the
      [Quartz documentation](https://www.quartz-scheduler.org/documentation/) for information about
      building cron triggers.

      Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the
      **CronTrigger** lesson.

      > [!NOTE] Because all schedules are based on the UTC timezone, the timezone configuration is
      > ignored.
      >
      > Due to the current library implementation, you can’t specify both a day-of-week (DOW) and a
      > day-of-month (DOM) parameter. For example, `0 0 3 1 1 2` or `0 0 3 * 1 2`. As a workaround,
      > you can use the `?` character, which indicates no specific value. This is useful when you
      > need to specify something in one of the two fields but not the other. For example,
      > `0 0 3 1 1 ?`.

    - Click **Switch to basic mode** to exit advanced mode.

3.  Click **Update** to save changed cron settings or click **Cancel** to exit without saving.

## See Also

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)

- [Monitor Applications](https://docs.mulesoft.com/runtime-manager/monitoring)

- [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept)

- [Migrating the Poll Component](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept)

- [Example App on Exchange](https://www.mulesoft.com/exchange/org.mule.examples/sending-a-csv-file-through-email-using-smtp/)

- [Quartz documentation](https://www.quartz-scheduler.org/documentation/)

<!-- document id=5559a043007667f9c1057d12faef0815673af2fc6afe8e2e310df6313ce5ea09 url=/mulesoft/current/en-us/cloudhub/tgw-manage-arm.md -->

---
product: CloudHub
---

# Manage Transit Gateway Attachments

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Use Anypoint Runtime Manager to manage transit gateway attachments, such as adding and removing a
route from the route table or detaching an Anypoint VPN from a transit gateway.

## Rename a Transit Gateway Attachment

You might want to rename a transit gateway attachment to match the attachment name in AWS.

To rename a transit gateway attachment:

1.  On the **Transit Gateways** page, click the Transit Gateway menu (**…​**) and select **Edit
    name**:

    ![Edit name option in the Transit Gateways menu](/mulesoft/current/en-us/cloudhub/_images/tgw-rename.png)

2.  In the popup window, enter a new name and click **Save**.

## Add a Route to the Transit Gateway Route Table

You might want to add a route to enable a new subnet to be accessible through the transit gateway.

1.  In Anypoint Platform, navigate to **Transit Gateways** > **VPCs** and click **Add Route**.

2.  In the **Add VPC Route** window, use CIDR notation to enter a single subnet for your AWS VPC:

    ![Add VPC route](/mulesoft/current/en-us/cloudhub/_images/tgw-add-vpc-route.png)

3.  Click **Add Route**.

    Anypoint Platform submits the new route to AWS.

> [!NOTE] When you add a new route, the platform ensures it doesn’t conflict with any existing
> routes in the VPC, whether they’re static or propagated from a BGP connection. If the new route is
> a duplicate, either remove the existing route or split the new route into smaller ones to avoid
> any collisions.

When the route addition succeeds, the **Transit Gateways** page shows the **Route added** message
and the **Transit Gateways** page shows the route CIDR in the route table.

In the route tables, added routes show **Transit Gateway** as the value in the **Next Hop** column.

Specific routes attached to the transit gateway show under **Transit Gateway Routes**. Other routes
in the VPC show under **VPC Routes**.

![Transit Gateway in the Next Hop column of the route table](/mulesoft/current/en-us/cloudhub/_images/tgw-route-added.png)

## Remove a Route from the Transit Gateway Route Table

You might need to remove a route if you no longer want a subnet to be accessible through the transit
gateway.

To remove a route:

1.  On the **Transit Gateways** page, in the **VPCs** section, click the **X** icon in the
    appropriate Transit Gateway route row of the route table:

    ![Remove route icon in the VPCs section](/mulesoft/current/en-us/cloudhub/_images/tgw-remove-vpc-route.png)

2.  At the confirmation prompt, click **Remove**.

## Detach an Anypoint VPC from the Transit Gateway

You might need to detach a VPC so that you can reattach it.

Detaching a VPC from a transit gateway also deletes the attachment in AWS. Any apps deployed to the
VPC continue to run, but they are no longer connected to your Amazon VPCs and VPNs.

To detach a VPC from the transit gateway:

1.  On the **Transit Gateways** page, click the VPC menu (**…​**) and select **Detach**:

    ![Detach VPC option in the VPC menu](/mulesoft/current/en-us/cloudhub/_images/tgw-detach-vpc.png)

2.  At the confirmation prompt, click **Detach**.

    Detaching a VPC might take several minutes.

## Remove an Anypoint VPC from the Transit Gateway

If you reject an attachment in AWS, the VPC attachment appears as `rejected` in Anypoint Platform.
In this case, you must remove the attachment before trying to attach it again.

To remove a VPC from the transit gateway:

1.  On the **Transit Gateways** page, click the VPC menu (**…​**) and select **Remove**:

2.  At the confirmation prompt, click **Remove**.

    Removing a VPC might take several minutes.

    After the VPC is removed, the **Attach VPC** button becomes available.

## Remove a Transit Gateway from Anypoint Platform

You might need to remove a transit gateway if you’ve reached your entitlement limit or you want to
switch the connection to a new transit gateway.

If a transit gateway has no VPCs attached, you can remove it from Anypoint Platform.

> [!NOTE] Removing a transit gateway deletes the resource share in AWS that Anypoint Platform uses
> to access the transit gateway.

To remove a transit gateway from Anypoint Platform:

1.  On the **Transit Gateways** page, click the Transit Gateway menu (**…​**) and select **Remove**:

    ![Remove option in the Transit Gateway menu](/mulesoft/current/en-us/cloudhub/_images/tgw-remove.png)

    Anypoint Platform prevents you from removing a transit gateway if it has VPCs attached.

    If the **Transit Gateways** page doesn’t list any VPCs, but you can’t delete the transit
    gateway, the transit gateway might be attached to a VPC that belongs to another business group
    that you don’t have access to.

2.  At the confirmation prompt, click **Remove**.

## See Also

- [Troubleshoot Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub/tgw-troubleshoot)

- [Attach to Transit Gateways](https://docs.mulesoft.com/cloudhub/tgw-attach-arm)

- [Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub/tgw-about)

- [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [Create and Update a VPC for Runtime Manager](https://docs.mulesoft.com/cloudhub/vpc-tutorial)

- [Grant Permissions and Roles to Users](https://docs.mulesoft.com/access-management/users#grant-permissions-and-roles-to-users)

<!-- document id=8ae063e5a720aaa6cdf6e69cd24c91f67042f19be2226b73f6ac29ef2916f4b4 url=/mulesoft/current/en-us/cloudhub/vpn-update-arm.md -->

---
product: CloudHub
---

# Modify an Anypoint VPN Connection

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can update some Anypoint VPN connection settings using Runtime Manager.

## IP Addresses

After you create the Anypoint VPN connection, you cannot modify the **Remote IP Address** or
**Tunnel Configuration** settings. To change these settings, you must recreate the Anypoint VPN and
update your VPN endpoint with the new values.

Local external IP addresses are dynamically assigned during VPN creation. You cannot reserve or
reuse external IP addresses. When you recreate the VPN, new local external IP addresses are
assigned.

Point-to-point IP addresses and Pre-Shared Keys (PSK) are defined during VPN creation. You can use
**Automatic Tunnel Configuration** to generate values for these settings or use the **Custom Tunnel
Configuration** to define your values for these settings.

See [Create an Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-create-arm#create-an-anypoint-vpn) for more information.

## Routing

After you create the Anypoint VPN connection, you cannot modify the routing type or Autonomous
System Numbers (ASNs). To change these settings, you must recreate the Anypoint VPN and update your
VPN endpoint with the new values.

## Networks

The local network is inherited from Anypoint VPC. MuleSoft does not allow you to subnet the Anypoint
VPC CIDR block.

You can modify the remote networks for an Anypoint VPN after creation. The steps differ depending on
the configured routing type (static or dynamic).

> [!NOTE] A maximum of 95 route table entries is allowed per Anypoint VPC, regardless of the number
> of VPN connections. To avoid exceeding this limit, consolidate networks to the fewest number
> possible.

### Static Routes

To modify the remote networks for an Anypoint VPN that uses static routing:

1.  Sign into Anypoint Platform and select **Runtime Manager**.

2.  From the menu on the left, click **VPNs**, and then click the name of the VPN to update.

3.  Under **Static Routes**, click **Add New Rule**.

4.  In the **CIDR** field, enter a subnet to make accessible through the VPN, for example,
    `10.0.0.0/8`.

5.  If you want to add additional subnets, click **Add New Rule** and repeat step 4.

6.  Click **Apply Changes** to add the new rules.

7.  Review the firewall rules for the corresponding Anypoint VPC.

    See [Add or Edit Firewall Rules](https://docs.mulesoft.com/cloudhub/vpc-firewall-rules-concept#add-or-edit-firewall-rules).

    By default, all traffic to your Anypoint VPC is blocked unless a firewall rule explicitly allows
    it.

8.  Update the configuration on your VPN endpoint.

    See the documentation for your device.

    When the tunnel is active, the route table updates automatically.

### Dynamic Routes

To modify the remote networks for an Anypoint VPN that uses dynamic routing:

1.  Review the firewall rules for the corresponding Anypoint VPC.

    See [Add or Edit Firewall Rules](https://docs.mulesoft.com/cloudhub/vpc-firewall-rules-concept#add-or-edit-firewall-rules).

    By default, all traffic to your Anypoint VPC is blocked unless a firewall rule explicitly allows
    it.

2.  Update the Border Gateway Protocol (BGP) configuration on your VPN endpoint.

    See the documentation for your device.

    When BGP propagates the changes, the route table updates automatically.

## IPsec

You can set the **Initiator Mode** for Anypoint VPN. When enabled, your Anypoint VPN initiates IKE
negotiation to enable tunnels. If you use this feature:

- Configure your gateway to accept an IKEv2 connection, as IKEv1 is not supported.

- Used route-based VPN, as policy-based VPN is not supported.

All IPsec settings are defined on your endpoint.

You can modify the VPN configuration of your endpoint to take advantage of any supported IPsec
settings. See [IPsec Settings](https://docs.mulesoft.com/cloudhub/vpn-about#ipsec-settings).

You don’t need to change any VPN settings in Runtime Manager.

### See Also

- [Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-about)

- [Anypoint Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud)

- [Anypoint VPN Knowledge Articles](https://help.salesforce.com/s/articleView?id=001117281&type=1)

<!-- document id=1df34c731f82bacb96c248c4c065861b05b969cc06cd62fa890f87b9d3d8249a url=/mulesoft/current/en-us/cloudhub/vpc-provisioning-concept.md -->

---
product: CloudHub
---

# Provision a VPC

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Provisioning an Anypoint VPC for your organization consists of two major steps:

1.  Create the VPC.  
    This is a self-service process. You can create a VPC using either the Runtime Manager UI, or the
    Anypoint Platform CLI.

    > [!NOTE] The Anypoint Platform base subscription includes two Anypoint VPC licenses, which
    > entitles your Anypoint Platform organization to two VPCs. Once your Anypoint VPC license limit
    > is reached, the **Create VPC** option is disabled in the user interface.

2.  Connect to your Anypoint VPC.  
    Configure your [Anypoint VPN](https://docs.mulesoft.com/cloudhub/to-request-vpc-connectivity) or [transit gateway](https://docs.mulesoft.com/cloudhub/tgw-about) to
    connect the Anypoint VPC to your on-premises network.

    To connect your Anypoint VPC using VPC peering or AWS Direct Connect, contact your MuleSoft
    Support representative.

> [!NOTE] To avoid unnecessary downtime, it is critical to define the Anypoint VPC settings when you
> first create a new Anypoint VPC.  
> If you edit these settings after the Anypoint VPC is created, you must then remove all your
> workers and redeploy them after the change is complete.

These settings include:

- The address space for your network.  
  This determines the size of your Anypoint VPC.

- The location of your VPC.  
  To enable the VPC to host your workers, the Anypoint VPC must be bound to a business group and a
  specific CloudHub region.

  - The Organization or Business Group for your VPC.

  - The CloudHub Region for your VPC.

Read the following FAQs to understand how to plan a successful VPC setup.

## FAQ: How to Calculate Anypoint VPC and VPN Licensing Requirements

To connect an Anypoint VPC through IPSec VPN, you must have the required number of licenses for your
deployment scenario.

The Anypoint Platform base subscription includes two Anypoint VPC licenses, which entitles your
Anypoint Platform organization to two licensed Anypoint VPCs. Anypoint VPN licenses are bundled with
the Anypoint VPC license, so each Anypoint VPC license also entitles the organization to one VPN
gateway with a connection to one public IP address in a remote location.

> [!NOTE] Anypoint VPN licenses do not need to have a one-to-one relationship with the Anypoint VPC
> licenses. For example, you can have one Anypoint VPC with two Anypoint VPNs and another VPC with
> no VPNs.

An additional Anypoint VPC license is required for each remote location that needs to be accessible
from the Anypoint VPC.

## FAQ: How to Size my VPC

When you create an Anypoint VPC, the range of IP addresses for the network must be specified in the
form of a Classless Inter-Domain Routing (CIDR) block, using CIDR notation.  
This address space is reserved for Mule workers, so it cannot overlap with any address space used in
your data center if you want to peer it with your VPC.

To calculate the proper sizing for your Anypoint VPC, you first need to understand that the number
of dedicated IP addresses is not the same as the number of workers you have deployed.  
For each worker deployed to CloudHub, the following IP assignation takes place:

- For better fault tolerance, the VPC subnet may be divided into up to four Availability Zones.

- A few IP addresses are reserved for infrastructure.

- At least two IP addresses per worker to perform at zero-downtime.

Due to this structure, the smallest network subnet block you can assign for your Anypoint VPC is /24
and the largest /16.

The safe rule of thumb for deciding the size of your Anypoint VPC subnet is to calculate 10 times
the maximum number of expected apps to deploy in the VPC.

## FAQ: Where to Place an Anypoint VPC inside My Organization

As an organization administrator, you can create an Anypoint VPC and share it with any business
group within your main organization.  
However, once the Anypoint VPC is inherited by a business group, only the administrator of said
business group can operate the Anypoint VPC. For example, an Anypoint organization administrator or
a business group owner can create or update an existing Anypoint VPC (owned or inherited) to make it
the default for either the region, the environment, or both.  
However, if such an association already exists, it’s overwritten by the requested Anypoint VPC.

If no business group association is specified, or if your organization does not have any business
groups, the Anypoint VPC ownership remains associated with the main organization. The organization
under which the Anypoint VPC is created is the VPC owner and this organization’s administrator is
the only one who can share the Anypoint VPC.  
Anypoint VPCs can only be shared vertically from the main organization to one of its business
groups, or from a business group to one of its child business groups.  
You cannot share an Anypoint VPC created by a business group with another business group that is
higher in the hierarchy.

It is recommended that you create your Anypoint VPC in your main organization, and share it with the
other business groups.

## FAQ: Which Region to use When Creating an Anypoint VPC

You can create your Anypoint VPC inside any of the available CloudHub regions.  
The recommended region to use might vary depending on how you connect to your Anypoint VPC. If you
are using a VPN tunnel, you might want to choose the CloudHub region closest to your data center.  
However, if you are peering with your private AWS VPC, you need to create your Anypoint VPC in the
same AWS region.

## FAQ: How to deploy or move applications to a VPC

MuleSoft applications are deployed to an environment, such as development or sandbox.

When the deployment region matches the VPC region:

- If the environment is already associated with a VPC at the time of application deployment, the app
  resides inside the VPC.

- If the environment is associated with a VPC after the app deployment, the app will not reside
  inside the VPC until the app is restarted.

When the deployment region does not match the VPC region, the app is deployed outside of the VPC.
This means that the app does not have access to any connectivity methods configured for the VPC.

## FAQ: How to Associate an Environment with Multiple VPCs

You can assign an environment to more than one VPC if those VPCs reside in different regions. When
you deploy an application to that environment, the deployment region determines which VPC hosts it.
If the environment lacks a VPC association in that region, the application uses the default VPC for
that region. If you associate an environment with a new VPC in the same region as an existing VPC,
the new association replaces the previous one. However, already-deployed applications continue
running on the previous VPC until you restart them.

## See Also

- [Request VPC Connectivity to Your Network](https://docs.mulesoft.com/cloudhub/to-request-vpc-connectivity)

<!-- document id=e67b76a14d6c4d4c8fe75caa4141d2a8a097eeca356afb7c2b3759574ca138f8 url=/mulesoft/current/en-us/cloudhub/to-request-vpc-connectivity.md -->

---
product: CloudHub
---

# Request Anypoint VPC Connectivity to Your Network

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The process for requesting or updating Anypoint Virtual Private Cloud (Anypoint VPC) connectivity to
your network depends on the connectivity method you use: IPsec, transit gateway attachments, VPC
peering, or AWS Direct Connect.

> [!NOTE] The SLA for provisioning an Anypoint VPC connection is five business days after MuleSoft
> Support receives and approves your completed Anypoint VPC discovery form.

## Configure IPsec VPN Connections

As of November 2018, MuleSoft Support no longer creates new VPN connections. For all new VPNs, you
must follow the self-service steps in [Create an Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-create-arm).

To update _existing_ IPsec VPN connections that were created by MuleSoft Support before November
2018:

1.  Download the [Anypoint VPC discovery form](https://docs.mulesoft.com/cloudhub/_attachments/VPC-form-v9.5-template.xlsx).

    This form requires Microsoft Excel 2007 or later (with macros enabled).

2.  For each VPC connection to update, complete and submit a separate Anypoint VPC form:

    1.  Complete all fields in the **Overview** and **IPSec** tabs.

        To avoid processing delays, ensure that you complete all fields on both tabs.

    2.  Open a Support ticket and submit your completed form.

The MuleSoft Support team updates the VPN configuration using the details provided in the Anypoint
VPC discovery form. Support updates your ticket to notify you when your request is complete.

## Configure Transit Gateway Attachments

To configure transit gateway attachments, follow the self-service steps in
[Attach to Transit Gateways](https://docs.mulesoft.com/cloudhub/tgw-attach-arm).

## Configure VPC Peering Connections

Because MuleSoft does not support inter-region peering, both VPCs must reside in the same region.

To request new or update existing VPC peering connections:

1.  Download the [Anypoint VPC discovery form](https://docs.mulesoft.com/cloudhub/_attachments/VPC-form-v9.5-template.xlsx).

    This form requires Microsoft Excel 2007 or later (with macros enabled).

2.  For each VPC peering connection, complete and submit a separate Anypoint VPC form.

    You must complete the Anypoint VPC discovery form for both new connections and for updates to
    existing configurations.

    1.  Complete all fields in the **Overview** and **VPC Peering** tabs.

        To avoid processing delays, ensure that you complete all fields on both tabs.

    2.  Open a Support ticket and submit your completed form.

The MuleSoft Support team creates or updates the VPC peering connection request using the details
provided in the Anypoint VPC discovery form. Support updates your ticket to notify you when your
request is complete.

## Configure Direct Connect Connections

For Direct Connect high availability architecture, prerequisites, and failover behavior, see
[Direct Connect High Availability](https://docs.mulesoft.com/cloudhub/vpc-connectivity-methods-concept#direct-connect-high-availability).

To request new or update existing Direct Connect (DX) connections:

1.  Establish DX connections to your AWS account or your partner’s AWS account.

2.  Create either a virtual interface (VIF) or a hosted connection with the MuleSoft Account ID.

3.  Download the [Anypoint VPC discovery form](https://docs.mulesoft.com/cloudhub/_attachments/VPC-form-v9.5-template.xlsx).

    This form requires Microsoft Excel 2007 or later (with macros enabled).

4.  For each DX connection, complete and submit a separate Anypoint VPC form.

    You must complete the Anypoint VPC discovery form for both new connections and updates to
    existing configurations.

    1.  Complete all fields in the **Overview** and **Direct Connect** tabs.

        To avoid processing delays, ensure that you complete all fields on both tabs.

    2.  Open a Support ticket and submit your completed form.

The MuleSoft Support team accepts the VIF or connection request. Support updates your ticket to
notify you when your request is complete.

## See Also

- [Anypoint VPC Connectivity Methods](https://docs.mulesoft.com/cloudhub/vpc-connectivity-methods-concept)

- [Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-about)

<!-- document id=d78ccf8f36f67c89fe8434f17127868974264dd053c5b5de46ef482fee6a004b url=/mulesoft/current/en-us/cloudhub/resolve-private-domains-vpc-task.md -->

---
product: CloudHub
---

# Resolve Private Domains in Your Internal Network

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

You can specify custom private domains by adding the IP address and domain name for your network.
When you provide private domains, your worker resolves them using your private DNS, so you can still
use the internal host names of your private network (make sure your applications call the backend
resources by FQDN).

1.  Sign into Anypoint Platform, and in **Management Center**, click **Runtime Manager**.

2.  In the left navigation, click **VPCs**.

3.  Select the row of the Anypoint VPC to configure, then click **Manage VPC**.

4.  Click the **Internal DNS** tab.

5.  Click **Add New IP**, enter the IP address of your internal DNS server, then click **Add to
    List**.  
    You can enter up to 3 IP addresses.

    ![vpc tutorial f7641](/mulesoft/current/en-us/cloudhub/_images/vpc-tutorial-f7641.png)

6.  Click **Add New Domain**, enter your internal domain name, then click **Add to List**.  
    You only need to add the common portion of the domain name, for example: `mulesoft.com`.

    You can add several private domains.

    ![vpc tutorial 7770c](/mulesoft/current/en-us/cloudhub/_images/vpc-tutorial-7770c.png)

7.  Click **Apply Changes**.

    > [!NOTE] Changes to internal DNS IP addresses and domains can take up to 60 minutes to
    > propagate to your CloudHub workers.

When resolving a domain name in your internal network, consider the following:

- The IP address you configure is for the DNS server of your internal network. It is not the IP
  address of the service you are connecting to.

- The maximum number of characters of all the domains you configure must not exceed 229 characters.
  For example, adding the domains `mydomain1.com` and `mydomain2.com` requires 28 characters. Each
  domain name consumes an additional character because in the DNS hierarchy all domains end with a
  "." character.

- Avoid entering hostnames to ensure that you do not exceed the 229 character limit.

- All DNS servers must include valid and identical records for all of the private domains listed.

## See Also

- [VPC Network Architecture](https://docs.mulesoft.com/cloudhub/vpc-architecture-concept)

- [Create a VPC](https://docs.mulesoft.com/cloudhub/vpc-tutorial)

<!-- document id=084c7d433c4ca01fa0b60e1cbabad3674eb5e862e64eee333e659823e192abad url=/mulesoft/current/en-us/cloudhub/penetration-testing-policies.md -->

---
product: CloudHub
---

# Run Vulnerability Assessment and Penetration Tests

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

If your company security policies require that you perform vulnerability and penetration testing
against Anypoint Platform, you can commence testing without notifying Salesforce beforehand.

All assessments must be performed in accordance with the
[Security Assessment Agreement](https://help.salesforce.com/s/articleView?id=000392845&type=1).

## Run Penetration and Vulnerability Tests

Because penetration testing can interfere with other tenants, MuleSoft allows penetration testing on
your workers but not on other Anypoint Platform services.

> [!IMPORTANT] Salesforce does not address vulnerabilities found with custom development. You must
> validate and fix any findings with your custom development.

### Prerequisites

Before initiating penetration testing:

- Enable static IPs for the app.

  By default, CloudHub workers don’t use static IP addresses, so you can’t test them because their
  IP addresses might change. For information about how to enable static IPs, see
  [Static IPs Tab Settings](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub#static-ips-tab-settings).

- Assign a security resource at your company to review and validate findings from the tests.

### Steps

1.  Run the penetration tests.

    The Security Assessment Agreement includes restrictions and requirements for testing.

2.  Have your security resource use the following documents to identify common false positives and
    security issues related to settings:

    - [Platform Security FAQ](https://help.salesforce.com/s/articleView?id=000383448&type=1)

    - [Salesforce Help](https://help.salesforce.com/s/)

3.  If your assessment generates vulnerability findings, complete validation for any automated
    finding. Send all outstanding validated security vulnerability findings to the Salesforce
    Security Team at [security.salesforce.com/contact](https://security.salesforce.com/contact).

    Include the following information in your email:

    - Confirmation number for your Security Assessment approved by Salesforce

    - Summary of all findings and the associated severity level of each finding

    - Detailed assessment report that notes each finding

    - Steps to reproduce the vulnerability

    - All applicable HTTP requests and responses

    - Explanation of why the example is considered a finding

### Reporting Security Vulnerabilities

To report security vulnerability findings, follow the
[Security Vulnerability Finding Submittal Guide](https://help.salesforce.com/s/articleView?id=000384043&type=1).
Security vulnerability reports that do not follow the required steps are rejected.

Salesforce does not address any security vulnerabilities in the following categories:

- Scan output from automated vulnerability scanning tools without a valid proof of concept

- Security bugs without valid proof of concept

- Vulnerabilities identified in old or deprecated versions of Mule runtime engine

- Vulnerabilities introduced via code customization made by your company

- Known security issues that don’t pose any risk

## See Also

- [Manage Applications on CloudHub](https://docs.mulesoft.com/cloudhub/managing-applications-on-cloudhub)

- [CloudHub](https://docs.mulesoft.com/cloudhub/)

- [Develop Applications for CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

<!-- document id=19124b8a623ce92e58521cc041b2367fe32e2223c552bef1430b2f55f016aa2f url=/mulesoft/current/en-us/cloudhub/secure-application-properties.md -->

---
product: CloudHub
---

# Safely Hide Application Properties

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

CloudHub supports safely hidden application properties, in which the name of the property is visible
in Anypoint Runtime Manager, but the value is not displayed or retrievable by any user. CloudHub
resolves the property at runtime without exposing the sensitive information.

Internally, safely hidden application properties are encrypted and stored in a MuleSoft-managed
CloudHub properties database, which is encrypted per user organization.

For applications deployed to CloudHub workers or hybrid deployments, you can use Runtime Manager to
set hidden properties. For applications that you deploy using another deployment option, you must
use secure property placeholder files bundled in the deployable application archive file.

> [!NOTE] This page describes safely hidden application properties for CloudHub and hybrid
> deployments.
>
> On CloudHub 2.0, secure-property masking is configured in Runtime Manager on the **Properties**
> tab (property protection). Masked values aren’t viewable or retrievable after being set and are
> encrypted in the Anypoint Security secrets manager. Runtime Manager properties override
> archive-bundled properties of the same name, so configuring value masking through
> `mule-artifact.json` or a configuration file doesn’t take effect on CloudHub 2.0. For more
> information, see [Protecting App Property Values](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props).

> [!IMPORTANT] Safely hidden application properties are a separate feature and concept from the
> encrypted Mule application properties that are stored in secure configuration files. See
> [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties).

## Overview

Application properties are variables that act as placeholders in your Mule application and are set
at runtime. When you deploy an application or update an existing application in Runtime Manager,
Mule runtime engine supplies the values for the property variables using the information you
configure in the **Properties** tab.

For example, you can configure a JDBC connector in which the username is set to `${dbUsername}` and
the password is set to `${dbPassword}`. In Runtime Manager, you can set these two properties as
application properties.

For sensitive information, you can flag these properties as hidden so that, after they are entered
and saved in Runtime Manager, their values are neither visible in the console nor passed between the
console and the CloudHub server.

> [!IMPORTANT] For hybrid deployments, the values remain visible, even after the redeployment.

## Create Safely Hidden Application Properties

To create safely hidden application properties:

1.  Add the properties to the appropriate file:

    For Mule 4.0 and later, in the `mule-artifact.json` file under the `secureProperties` key, list
    the property names to safely hide as a comma-separated array:

    ```json
    {
      "configs": ["testprops-app.xml"],
      "secureProperties": ["password", "birthdate"],
      "redeploymentEnabled": true,
      "name": "secure-properties",
      "minMuleVersion": "4.2.1",
      "requiredProduct": "MULE_EE",
      "classLoaderModelLoaderDescriptor": {
        "id": "mule",
        "attributes": {
          "exportedResources": []
        }
      },
      "bundleDescriptorLoader": {
        "id": "mule",
        "attributes": {}
      }
    }
    ```

    Line 5 shows two secure properties.

    The `secureProperties` entry affects all properties regardless of where or if they are defined.

    If you want to perform local testing, create a YAML file that defines properties with values and
    add it to the `src/main/resources` folder:

    ```yaml
    http:
      port: 8081
    username: "testuser"
    password: "testpass123"
    birthdate: "01/01/2006"
    ```

2.  Deploy the Mule application to CloudHub.

3.  In the **Applications** page, click the application name and then click **Settings**.

4.  In the **Properties** tab, click **Text View** and then enter your application properties:

    ![Properties tab and key-value properties on the application Settings page](/mulesoft/current/en-us/cloudhub/_images/rtm-hide-props.png)

    Figure 1. The screenshot shows (**1**) the **Properties** tab and (**2**) the key-value
    properties on the application **Settings** page.

5.  Click **Apply Changes**.

6.  Redeploy or restart the app.

    After redeploying your app, navigate to the **Properties** tab. The values for properties that
    you marked as safely hidden are now no longer visible to you or any other user.

    In the following example, `birthdate` and `password` are safely hidden but `username` is not:

    ![Hidden values in the Properties tab on the application Settings page](/mulesoft/current/en-us/cloudhub/_images/rtm-hidden-props.png)

    Figure 2. The arrow shows the hidden values in the **Properties** tab on the application
    **Settings** page.

After the values are committed and the application is uploaded, the safely hidden properties are not
displayed on the console or sent and received between the console and the CloudHub server.

After you set the property, you can’t retrieve it; however, you can overwrite the property with a
new value. To update a value, enter a new value into the field.

After an application is deployed with safely hidden application properties, CloudHub maintains the
security flag for those properties. Even if you edit your application file to remove the
`secureProperties` definitions from your `mule-artifact.json` file and then upload that edited
application file to CloudHub, CloudHub keeps the invisibility of the properties previously flagged
as safely hidden. Any property added as secure at any time remains secure even after it is deleted
from the `mule-artifact.json` file.

## Copy Safely Hidden Application Properties between Sandboxes

When moving applications between sandboxes, safely hidden application property values are not copied
to the new environment. For all safely hidden application properties, the name of the property is
copied, but the value is left blank.

## Encrypted Application Properties vs. Safely Hidden Application Properties

Mule applications can also store properties with encrypted values using secure properties
placeholders.

See [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties) for
more information about creating and using secure configuration properties.

With encrypted properties, the Mule application bundles the secure property placeholder files inside
the Mule application’s deployable archive .jar file.

A secure property placeholder combines together the file containing the encrypted properties, plus
details about the encryption algorithm that is used to encrypt the secure property values. Secure
properties are encrypted using a secret key. Never store the secret key inside your Mule
applications. Instead, you need to safely (securely) pass in the secret key value at deployment
time.

To safely pass the secret key into the Mule application, develop the Mule application with a
property placeholder to represent the secret key value. There are then several options for how an
operator can safely pass in the secret key value at deployment time.

For on-premises deployments where you have access to the file system and the command-line, the
secret key can be passed in by setting a system environment variable when the Mule runtime is
started up. If the file system is secure, you can also store the secret key in a special secure
folder on the file system. Restrict permission for the Mule application to safely read in the secret
key at startup.

After the secret key is read into memory, it is used by the Mule application to decrypt all the
other properties in the secure properties placeholder, and the decrypted values are stored in
memory. To secure the Mule application, it is important to lock down access to the Mule runtime’s
host, so that no one can read the Mule application’s memory or JVM properties.

> [!NOTE] When specifying `secure properties` in the `mule-artifact.json` file for properties
> defined using the security properties module don’t forget to add the `secure::` prefix.

## Start a CloudHub Application That Uses Encrypted Properties

Mule applications can also be developed to store encrypted properties in secure properties
placeholder files.

For CloudHub deployments, none of the secure deployment approaches discussed for customer-hosted
deployments is available in CloudHub, because operators do not have access to the CloudHub worker’s
file system, nor can they log in to a command-line to start up the CloudHub worker.

Encrypted properties can also be flagged as safely hidden application properties, by listing the
encrypted property’s name in the `secureProperties` entry in the Mule application’s
`mule-artifact.json` file. In particular, the secret key used to decrypt the encrypted properties
can be set as a safely hidden property in the `mule-artifact.json` file’s `secureProperties` key.

Here is an example:

`config.yaml`

```yaml
http:
  port: 8081
username: "testuser"
password: "![r8weir09458riwe0r9484oi]"
birthdate: "01/01/2015"
```

`mule-artifact.json`

```json
{
  "configs": ["secure-properties.xml"],
  "secureProperties": ["secure::password", "birthdate", "secure.key"],
  "redeploymentEnabled": true,
  "name": "secure-properties",
  "minMuleVersion": "4.1.1",
  "requiredProduct": "MULE_EE",
  "classLoaderModelLoaderDescriptor": {
    "id": "mule",
    "attributes": {
      "exportedResources": []
    }
  },
  "bundleDescriptorLoader": {
    "id": "mule",
    "attributes": {}
  }
}
```

Then, at deployment time, the operator can type in the `secure.key` value into the Runtime Manager
Properties tab for the deployment. Because the secure key is flagged to be hidden in the console, no
one can see what the operator is typing.

After the secret key is passed into the Mule application, encrypted properties are decrypted into
memory just like they are with customer-hosted deployments. This is a safe thing to do in CloudHub,
because CloudHub workers are highly secure, with no access to the CloudHub worker’s command-line,
nor is there any way for an intruder to read the CloudHub worker’s memory or JVM properties.

## How to Override Encrypted Properties

Encrypted properties that are bundled with a Mule application inside a secure properties placeholder
file do not appear in the Runtime Manager **Properties** tab. This keeps the values safely locked
inside the Mule application.

If encrypted property names are listed in the Mule application’s `secureProperties` entry in
`mule-artifact.json`, once the application is deployed, the value of the encrypted property names is
hidden in the Runtime Manager **Properties** tab, along with decrypted properties.

The decrypted values are stored securely in the Mule worker’s memory and the encrypted values are
stored in the CloudHub database for your user account. The decrypted values are never stored in any
CloudHub worker’s files, nor are they ever passed between any other machines (including the Runtime
Manager console).

So for any encrypted property that is also marked as hidden in the Mule application’s
`secureProperties` entry, you can safely replace any encrypted property with a clear-text value. The
clear-text value is then securely stored in the CloudHub properties database, and securely passed
into the Mule application every time the Mule application is started.

For CloudHub deployments, the new value is hidden once the application is deployed and can never be
viewed again. For hybrid deployments, the new value remains visible, even after the redeployment.

This means that when you override a secure property in the CloudHub **Properties** tab for the
application, the value must not be encrypted. In this scenario, only users who have access to the
values in the application’s source files when they deploy or redeploy a secure application can
override secure properties.

An example of when to override secure properties is if you need to update the database user and
password stored in two properties named `db.user` and `db.password` in a production application. You
can enter the new `db.user` and `db.password` values in the CloudHub **Properties** tab for the
application and then start or restart the application. This allows the new application to upgrade
the secure login information with zero downtime. After all dependent applications are migrated, the
old account can be decommissioned.

> [!NOTE] If you use the **Table View** in the application’s **Properties** tab to update
> properties, you don’t need to escape the colons in property names, for example:
> `secure::someproperty`. If you use the **Text View** to update properties, you need to escape the
> colons in property names, for example: `secure\:\:someproperty`.

## Mule Applications Deployed Only to CloudHub Workers

If you don’t want to encrypt properties for Mule applications that are deployed only to CloudHub
workers, you can instead flag those properties as safely hidden properties in the Mule application’s
`mule-artifact.json` file’s `secureProperties` entry.

## See Also

- [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties)

- [Protecting App Property Values on CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props)

- [Manage Properties for Applications on CloudHub](https://docs.mulesoft.com/cloudhub/cloudhub-manage-props)

- [Manage Properties for Applications On-Premises](https://docs.mulesoft.com/runtime-manager/hybrid-manage-props)

- [Manage Deployed Applications](https://docs.mulesoft.com/runtime-manager/managing-deployed-applications)

- [Deploy to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub)

- [Hide Configuration Properties in Hybrid Deployments](https://help.salesforce.com/s/articleView?id=001117183&type=1)

- [How to Secure Properties before Deployment in Anypoint Studio](https://developer.mulesoft.com/tutorials-and-howtos/getting-started/how-to-secure-properties-before-deployment)

<!-- document id=47540a75cc6f8476a8af2ecfee1df8e083662024e3d200a6d89bc3de1a365235 url=/mulesoft/current/en-us/cloudhub/tgw-about.md -->

---
product: CloudHub
---

# Transit Gateway Attachments

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

AWS Transit Gateway acts as a cloud router in AWS, simplifying network access between VPCs,
on-premises data centers, and third-party software, while providing increased visibility and control
over the network. Transit gateways effectively merge your organization’s cloud resources and
on-premises datacenters into one network topology.

On CloudHub, you can take advantage of this network simplification by securely attaching Anypoint
Virtual Private Cloud (VPC) to AWS Transit Gateway in your AWS account.

You can add multiple transit gateways to your Anypoint Platform organization. The number of transit
gateways you can add depends on the network connection entitlements available to your account.
Contact your MuleSoft account representative if you don’t know how many entitlements are associated
with your account.

## Limitations

The following values are governed by AWS limits:

- Maximum number of transit gateways per VPC

- Maximum number of VPCs that you can attach to a transit gateway

For information about limitations when attaching a VPC to an AWS transit gateway, see
[Transit gateway attachments to a VPC](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)
in the AWS documentation.

## See Also

- [Attach to Transit Gateways](https://docs.mulesoft.com/cloudhub/tgw-attach-arm)

- [What is a transit gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
  in the AWS documentation

- [Transit gateway route tables](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html)
  in the AWS documentation

<!-- document id=9fd423bd2a7f6dac055e353a69f209474c6a8a62425943d73f7c85a82b6987de url=/mulesoft/current/en-us/cloudhub/vpn-troubleshooting.md -->

---
product: CloudHub
---

# Troubleshoot Anypoint VPN

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

These are some of the possible errors you may encounter when attempting to connect Anypoint VPN.

## Unable to Connect to the Anypoint VPN

If you are unable to connect to the Anypoint VPN, ensure any firewalls that are configured are
allowing traffic through the IP addresses in the `localExternalIpAddress` field in the VPN tunnels.

## Routes are Not Present in the VPC Route Table

The VPC route table is not updated until the tunnels are active. When using static routing, the
remote networks are added to the route table when the tunnel is active, and removed when the tunnel
is inactive. This is the expected behavior. When using BGP routing, the routes are propagated from
your VPN endpoint when the tunnel is active. If the route table does not show the required entries,
ensure that the BGP session is active and validate the BGP configuration on your device.

## Anypoint VPN Tunnel Connection Works, but Routes are not Propagated

Ensure that the neighbor IP address for the tunnel is taken from the Local point-to-point IP address
in the tunnel’s details.

## Phase 2 SA Established, but Traffic not Passing Through Tunnel

The VPN connection supports only one security association (SA) pair per tunnel, so any more than one
traffic selector per connection will cause unexpected results.

To solve this, ensure that only one unique SA is used per VPN tunnel connection. If more than one
policy is needed, you must consolidate and filter traffic in your network.

## Anypoint VPN Tunnel Disconnects After Period of Inactivity

IPsec is established by sending "interesting traffic" (traffic that should be encrypted over the
Anypoint VPN connection). If there is no interesting traffic, the tunnel disconnects. This is the
expected behavior, and the timeout value might vary.

Some VPN configurations require additional steps to keep the tunnel active, which means you need to
ensure you periodically send interesting traffic. For example, sending ICMP requests every 5 seconds
to a CloudHub worker’s internal IP address or FQDN will keep the tunnel active.

## Tunnel Status in the Runtime Manager UI Shows the Wrong Value

Because the time to retrieve the tunnel status includes the inherent delay in the
infrastructure-provider API, you can expect delays of up to five minutes when reporting the correct
status. Do not use this information to trigger a failover between the tunnels. Instead, monitor
tunnels at the customer-side VPN gateway.

## See Also

- [Anypoint VPN Knowledge Articles](https://help.salesforce.com/s/articleView?id=001117281&type=1)

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=b56aaa8139ce410e3906f56c719c8b991f15d9979e84ee036f4f1503a7541f33 url=/mulesoft/current/en-us/cloudhub/tgw-troubleshoot.md -->

---
product: CloudHub
---

# Troubleshoot Transit Gateway Attachments

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

These are some of the possible errors you might encounter when attempting to attach to a transit
gateway.

## Unable to Attach to a Transit Gateway

If you see the `Resource Share Not Found` error when attempting to attach to the transit gateway:

1.  Verify that the **ID** and **Owner** values that you specified are correct.

2.  Verify that the region matches the transit gateway region.

3.  Click the pencil icon to edit these values.

## Unable to Delete a Transit Gateway

If the **Transit Gateways** page doesn’t list any VPCs, but you can’t delete the transit gateway and
you see the `Can’t remove this transit gateway` error, the transit gateway might be attached to a
VPC that belongs to another business group that you don’t have access to.

## Unable to View a Transit Gateway

Runtime Manager always adds transit gateways at the root business group level. To view a transit
gateway, you need CloudHub Network Viewer permission.

## Unable to Modify a Transit Gateway

To modify a transit gateway, you need CloudHub Network Admin permission.

## Transit Gateway Status is Unknown

If the status for the transit gateway is `Unknown`, the resource share on AWS has been either
disabled or deleted.

Click the **View on AWS** button on the **Transit Gateways** page to resolve the issue on AWS:

![View on AWS button on the Transit Gateways page](/mulesoft/current/en-us/cloudhub/_images/tgw-view-on-aws.png)

## VPC Attachment Rejected

If you see the `The attachment was rejected in AWS` error when attempting to attach the VPC to the
transit gateway, remove the VPC and reattach it.

See
[Remove an Anypoint VPC from the Transit Gateway](https://docs.mulesoft.com/cloudhub/tgw-manage-arm#remove-an-anypoint-vpc-from-the-transit-gateway).

## Subnet Already Added to the Route Table

If you see the `This subnet has already been added to this route table` error, add a different
subnet to the table.

## Invalid CIDR Subnet

If you see the `Please enter a single subnet in CIDR notation` error, check that the subnet is in
the correct CIDR format.

## Attach VPC Button Is Disabled

If the **Attach VPC** button is disabled, all the VPCs you have access to are already attached to
the transit gateway.

## Connections Limit Has Been Reached

If you see an error such as
`Connections limit has been reached (max=4, used=4) for the organization`, you have consumed all
your network connections entitlements (VPC/VPN licenses). Contact your account team to purchase
additional licenses.

## See Also

- [Remove a Route from the Transit Gateway Route Table](https://docs.mulesoft.com/cloudhub/tgw-manage-arm#remove-a-route-from-the-transit-gateway-route-table)

- [Add a Route to the Transit Gateway Route Table](https://docs.mulesoft.com/cloudhub/tgw-manage-arm#add-a-route-to-the-transit-gateway-route-table)

- [Troubleshoot VPC attachment creation](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html#transit-gateway-vpc-attch-troubleshooting)
  in the AWS documentation

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=c9e1cef60db87ef35fbbf03071289a2df6d4d4fe1d75b81f7765f25054a07722 url=/mulesoft/current/en-us/cloudhub/cloudhub-use.md -->

---
product: CloudHub
---

# Using CloudHub

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Runtime Manager allows you to deploy your Mule application to different deployment targets,
such as an on-premises server and CloudHub. Using CloudHub implies the following:

- [Developing applications for CloudHub](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub), by following certain
  specific considerations.

- [Deploying to CloudHub](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub), by means of a variety of tools you can choose
  from.

- [Viewing log data](https://docs.mulesoft.com/cloudhub/viewing-log-data), including deployment messages and events for each worker and
  Mule runtime engine logs.

- [Integrating with your logging system](https://docs.mulesoft.com/cloudhub/custom-log-appender), by configuring logs to flow to your
  log system with the Log4j configuration, after which you can disable CloudHub logs.

- [Managing CloudHub-specific settings](https://docs.mulesoft.com/cloudhub/managing-cloudhub-specific-settings), including regions,
  subscription levels and plan types.

<!-- document id=e8f3f89785af1e7c9cd0fa014101226dfa69919227232525631e612eb41698bd url=/mulesoft/current/en-us/cloudhub/viewing-log-data.md -->

---
product: CloudHub
---

# View Log Data

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

CloudHub provides access to log data that includes deployment messages and events for each worker
and Mule runtime engine logs.

Logs and diagnostics are currently available only for applications deployed to CloudHub workers. For
applications deployed to a local server, you can send data to external analytics software. See
[Export Data to External Analytics Tools](https://docs.mulesoft.com/runtime-manager/sending-data-from-arm-to-external-analytics-software).

For more advanced searching and log management, you can:

- Use Anypoint Monitoring.

  See [Anypoint Monitoring Overview](https://docs.mulesoft.com/monitoring/).

- Integrate your CloudHub app with your logging system using the Log4j configuration.

  See [Integrate with Your Logging System Using Log4j](https://docs.mulesoft.com/cloudhub/custom-log-appender).

## View Logs

To view logs for applications deployed to CloudHub:

1.  In Anypoint Platform, select **Runtime Manager**.

2.  In the Runtime Manager navigation menu, click **Applications**, and then click the application
    name.

3.  In the navigation menu, click **Logs**.

4.  In the **Deployments** section, filter the output by day, deployment, system log, and workers.

    To remove a filter, deselect the checkbox for the date:

    ![Filter log output by deployment in the Deployments section](/mulesoft/current/en-us/cloudhub/_images/cloudhub-logs-deploy.png)

    Figure 1. The arrow shows the checkbox to filter log output by deployment in the **Deployments**
    section.

## Download Logs

For each worker in a CloudHub deployment, you can download logs specific to that worker’s activity:

1.  In the **Deployments** section, select the date and worker for which you want to download logs.

2.  Click the download icon for the worker and select **Logs**:

    ![Download log output by worker in the Deployments section](/mulesoft/current/en-us/cloudhub/_images/cloudhub-logs-download.png)

    Figure 2. The arrow shows the icon to download log output by deployment in the **Deployments**
    section.

CloudHub downloads the log output to a text file in the format
`_deploymentID_._instanceID_-_workerNumber_.log`. Use a text editor to view the log file.

To archive or download CloudHub application logs for audit, analytics, or other purposes at regular
intervals, use the custom log appender to extract logs. See
[Integrate with Your Logging System Using Log4j](https://docs.mulesoft.com/cloudhub/custom-log-appender).

## Download Mule Logs

Mule logs display the logs of the Mule runtime engine for CloudHub. The Mule log contains
information about app and lifecycle events. For example, the log records an entry when a Mule
service or app starts, deploys, stops, or undeploys.

1.  In the **Deployments** section, select the date and worker for which you want to download Mule
    logs.

2.  Click the download icon for the worker and select **Mule Logs**:

    ![Download Mule log output in the Deployments section](/mulesoft/current/en-us/cloudhub/_images/cloudhub-logs-mule-download.png)

    Figure 3. The arrow shows the icon to download Mule log output by deployment in the
    **Deployments** section.

CloudHub downloads the Mule log output to a text file in the format
`_appName_-instance-_instanceID_-_workerNumber_-mule_ee.log`. Use a text editor to view the log
file.

For more information about Mule logs, see
[Runtime Log](https://docs.mulesoft.com/mule-runtime/latest/logging-in-mule#runtime-log).

## Deployment History Persistence

CloudHub stores up to 30 days of inactive deployments history based on the last modified time of the
deployment.

## Log Persistence

CloudHub stores up to 100 MB of log data per application per worker, or up to 30 days, whichever
limit is reached first.

## Log Timezones

CloudHub stores log data in Universal Time (UTC); however, the console displays the log using your
computer’s local time zone.

## Retrieve Logs Using the CloudHub API

To retrieve application logs programmatically, use the CloudHub API log endpoints. See
[CloudHub API Reference](https://docs.mulesoft.com/cloudhub/cloudhub-api-reference).

When filtering by time range, the `startTime` and `endTime` parameters require ISO 8601 UTC format
with microsecond precision (`YYYY-MM-DDTHH:mm:ss.SSSSSSZ`), for example,
`2025-12-25T10:00:00.000000Z`. These parameters don’t accept epoch (Unix) timestamps.

## Search Logs

Search for logs that contain specified values or search for logs by date and priority.

To search logs:

1.  Enter a value in the search box, or click **Advanced** to search for logs for a specified time,
    day, date range, and message priority.

2.  Click **Apply**.

    ![Display Advanced search and Priority on the Logs page](/mulesoft/current/en-us/cloudhub/_images/cloudhub-logs-search-adv.png)

    Figure 4. The screenshot shows (**1**) **Advanced** search and (**2**) **Priority** on the
    **Logs** page.

You can search with queries. For more information, see
[Log Search Syntax](https://docs.mulesoft.com/cloudhub/cloudhub-log-search-syntax).

### Search by Date and Time

The **Date & Time** filter lets you search the log by specifying a date range. Possible values are:

- **Last hour**

- **Last 24 hours**

- **Last week**

- **Last month**

### Search by Message Priority

The **Priority** filter lets you view specific events in the log. You can also specify different
priorities by typing `priority<type>` in the search box, as shown in the **Command** column in the
table.

Possible values are:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Value</th><th>Description</th><th>Command</th></tr></thead><tbody><tr><td><div><div><p>All Priorities</p></div></div></td><td><div><div><p>List all messages</p></div></div></td><td><div><div><p>N/A</p></div></div></td></tr><tr><td><div><div><p><code>ERROR</code></p></div></div></td><td><div><div><p>List only error messages, such as when an exception occurs.</p></div></div></td><td><div><div><p>priority:ERROR</p></div></div></td></tr><tr><td><div><div><p><code>FATAL</code></p></div></div></td><td><div><div><p>List only fatal messages for when an application fails</p></div></div></td><td><div><div><p>priority:FATAL</p></div></div></td></tr><tr><td><div><div><p><code>INFO</code></p></div></div></td><td><div><div><p>List informative messages</p></div></div></td><td><div><div><p>priority:INFO</p></div></div></td></tr><tr><td><div><div><p><code>SYSTEM</code></p></div></div></td><td><div><div><p>List messages about application and worker startup</p></div></div></td><td><div><div><p>priority:SYSTEM</p></div></div></td></tr><tr><td><div><div><p><code>CONSOLE</code></p></div></div></td><td><div><div><p>List message about console events such as setting the object store</p></div></div></td><td><div><div><p>priority:CONSOLE</p></div></div></td></tr><tr><td><div><div><p><code>WARN</code></p></div></div></td><td><div><div><p>List warning messages</p></div></div></td><td><div><div><p>priority:WARN</p></div></div></td></tr><tr><td><div><div><p><code>DEBUG</code></p></div></div></td><td><div><div><p>List debugging messages</p></div></div></td><td><div><div><p>priority:DEBUG</p></div></div></td></tr></tbody></table>

> [!NOTE] Heap dumps cannot be shared. Instead, our **Support Center** representatives can analyze
> the dumps and share the required information with you.

## See Also

- [Integrate with Your Logging System Using Log4j](https://docs.mulesoft.com/cloudhub/custom-log-appender)

- [Configuring Logging](https://docs.mulesoft.com/mule-runtime/latest/logging-in-mule)

- [Log Search Syntax](https://docs.mulesoft.com/cloudhub/cloudhub-log-search-syntax)

- [Export Data to External Analytics Tools](https://docs.mulesoft.com/runtime-manager/sending-data-from-arm-to-external-analytics-software)

- [Monitor Applications and Servers](https://docs.mulesoft.com/runtime-manager/monitoring)

- [Generate Apps Diagnostics and Analyze with Einstein](https://docs.mulesoft.com/cloudhub/ch-diagnostics-agent)

- [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies)

<!-- document id=1314210b6521b9eae6f6a8d8ac2a542eb3bcbad155089eb6e9bbe1e5a6c805c7 url=/mulesoft/current/en-us/cloudhub/virtual-private-cloud.md -->

---
product: CloudHub
---

# Virtual Private Cloud

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Anypoint Virtual Private Cloud (VPC) offering allows you to create a virtual, private, and
isolated network segment in the cloud to host your CloudHub workers.

Connecting to your Anypoint VPC extends your corporate network and allows CloudHub workers to access
resources behind your corporate firewall. You can connect on-premises data centers through a secured
VPN tunnel or a transit gateway attachment, or connect a private AWS VPC to your Anypoint VPC
through VPC peering or AWS Direct Connect.

The base Anypoint VPC subscription includes two Anypoint VPCs and each Anypoint VPC can be
associated with multiple environments. This allows you, for example, to have one isolated network
for your production environment, and another for your non-productions environments, for example, QA
and staging. Your licensing requirements depend on your specific deployment scenario.

Anypoint VPC supports different Amazon regions. During setup, you need to specify which Amazon
region you want. You can even have multiple Anypoint VPCs inside a single Amazon region.

![virtual private cloud 78b5f](/mulesoft/current/en-us/cloudhub/_images/virtual-private-cloud-78b5f.png)

Each Anypoint VPC allows you to configure firewall rules to apply to your workers. You can choose to
expose or block your custom ports and even block requests to your apps coming from CloudHub’s shared
load balancer.

If you use dedicated load balancers, you can configure one or more dedicated load balancers to
validate requests using your own SSL certificates, and to map input URLs to call to different
CloudHub applications.

Combining firewall rules and dedicated load balancers configurations, enables you to fine tune how
external services reach your applications.

VPC-level network traffic metrics aren’t available in Anypoint Monitoring. For _application-level_
traffic metrics, see
[Can I get VPC-level network traffic metrics from Anypoint Monitoring?](https://docs.mulesoft.com/monitoring/am-faq#vpc-traffic-metrics).

## See Also

- [Anypoint VPC Network Architecture](https://docs.mulesoft.com/cloudhub/vpc-architecture-concept)

- [Provision an Anypoint VPC](https://docs.mulesoft.com/cloudhub/vpc-provisioning-concept)

- [CloudHub Dedicated Load Balancer](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer)

- [Anypoint VPC Firewall Rules](https://docs.mulesoft.com/cloudhub/vpc-firewall-rules-concept)

- [CloudHub Architecture](https://docs.mulesoft.com/cloudhub/cloudhub-architecture)

<!-- document id=26ae8810dcaa276c0301b46f43969326f5b009cb50b26c6aa49dbaae350ef0a3 url=/mulesoft/current/en-us/cloudhub/vpc-firewall-rules-concept.md -->

---
product: CloudHub
---

# VPC Firewall Rules

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

In CloudHub’s default configuration, all applications are hosted in a multi-tenant cloud balanced by
a publicly accessible load balancer.  
When you create an Anypoint Virtual Private Cloud (Anypoint VPC), you can add your own firewall
rules to allow specific IP ranges and ports to reach your workers. See
[Configure Firewall Rules](#configurefirewall).

> [!NOTE] Keep in mind that the firewall rules that you configure in your Anypoint VPC check inbound
> connections only to your workers, and not to the Anypoint VPC, your dedicated load balancer, or
> the publicly accessible load balancer.

## Default Firewall Rules

By default, all traffic to your VPC is blocked unless it’s explicitly allowed in a firewall rule.
When you create an Anypoint VPC, four firewall rules are created by default:

- Two rules to allow inbound connections from within your local Anypoint VPC through ports 8091 and
  8092:

  ```json
  {
    "CIDR Block": "10.111.0.0/24", // (Local VPC)
    "Protocol": "TCP",
    "From port": 8092,
  },

  {
    "CIDR Block": "10.111.0.0/24", // (Local VPC)
    "Protocol": "TCP",
    "From port": 8091,
  },
  ```

  These firewall rules allow traffic from within the Anypoint VPC to reach your workers through
  ports 8091 and 8092. These are the only ports used by your CloudHub-dedicated load balancer to
  proxy all external communications to your workers.

- Two rules to allow inbound connections from anywhere through ports 8081 and 8082:

  ```json
  {
    "CIDR Block": "0.0.0.0/0", // (Anywhere)
    "Protocol": "TCP",
    "From port": 8082,
  },

  {
    "CIDR Block": "0.0.0.0/0", // (Anywhere)
    "Protocol": "TCP",
    "From port": 8081,
  }
  ```

  > [!NOTE] These rules allow traffic from any host to reach your workers through ports 8081
  > and 8082. These ports are used by CloudHub’s shared load balancer to proxy external requests to
  > your workers. You can remove these rules if you don’t want your internal workers to be reached
  > by the publicly accessible load balancer.

## Firewall Rule Limits

You can configure approximately 35 firewall rules per VPC, depending on the number of rules CloudHub
requires, which might change.

If you create more than the number of available firewall rules, the VPC returns an error, indicating
that you have reached the maximum number of rules.

> [!NOTE] CloudHub doesn’t support IPv6 firewall rules.

## Configure Firewall Rules

You can configure firewall rules in the Anypoint Runtime Manager UI at the time you create an
Anypoint VPC, or you can add them to an existing Anypoint VPC. You can also modify the firewall
rules for an Anypoint VPC at any time.

Before you implement firewall rules, or make changes to existing rules, you should fully understand
all security implications. Make sure you follow the established best practices of your organization
before making any changes to firewall rules. In general, the rules you use to define access to your
Anypoint VPC should be as specific as is practical.

Firewall rules are inbound and use the following parameters:

- **Type**: Protocol type, for example, TCP

- **Source**: Source IP address

- **Port Range**: The only two ports exposed externally are 8081 (http.port) and 8082 (https.port).
  You can use this parameter to open additional ports inside the VPC.

> [!NOTE] You cannot configure firewall rules for ports below 1024.

### Add or Edit Firewall Rules

1.  Sign into Anypoint Platform as a user with the **Organization Administrators** role.

2.  In **Management Center**, click **Runtime Manager**.

3.  If you already have an Anypoint VPC:

    1.  In the left menu, click **VPCs** and click the row for the Anypoint VPC whose firewall rules
        you want to configure.  
        The right panel displays information about the Anypoint VPC instance.

    2.  Click **Manage VPC**, then click the **Firewall Rules tab**.

4.  If you are creating firewall rules when you create your Anypoint VPC:

    1.  Click **Firewall Rules >** to expand the fields.

        ![firewall rules page](/mulesoft/current/en-us/cloudhub/_images/firewall-rules-page.png)

5.  To edit a rule, select the new values from the **Type** and **Source** drop-down lists, and
    enter the value for the **Port Range**.

6.  To add additional rules:

    1.  Click **Add New Rule**.

    2.  Select the following values for the type and source in the corresponding columns:

        - **Type**: Select the transport protocol type for the rule.

        - **Source**: Select the source IP address, or select **Custom** to define your own source.

    3.  Enter a value for **Port Range** and click **Add to list**.

7.  To delete a firewall rule, hover over the firewall rule row to delete, then click the trashcan
    icon in the far-right column.

> [!NOTE] No confirmation dialog appears when you delete a firewall rule, so make sure you really
> want to delete it.

## See Also

- [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide)

- [CloudHub Load Balancers](https://docs.mulesoft.com/cloudhub/dedicated-load-balancer-tutorial)

- [Dedicated Load Balancers](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer)

- [CloudHub Architecture](https://docs.mulesoft.com/cloudhub/cloudhub-architecture)

<!-- document id=639ce0d1fe4763434505333277463a6b670e6a537fcc944a5d1d0256c4da33d2 url=/mulesoft/current/en-us/cloudhub/vpc-architecture-concept.md -->

---
product: CloudHub
---

# VPC Network Architecture

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

An Anypoint VPC is a logically private and isolated network hosted inside CloudHub. You can connect
your private intranet to your Anypoint VPC as if they were all part of a single, private network.

The Anypoint VPC configuration exposes the DNS record `mule-worker-internal-<app-name>.cloudhub.io`.
This is a DNS A record, which includes the IP addresses of all your workers. This DNS record cannot
be accessed from outside your Anypoint VPC.

Each Anypoint VPC allows you to configure firewall rules to check inbound connections directly to
your workers.

Four firewall rules are created by default—​two rules that allow your private address space to
connect through ports 8091 and 8092, and two rules that allow external requests proxied by
CloudHub’s shared load balancer through ports 8081 and 8082.

All traffic that is not allowed in a firewall rule is blocked by default.

![Default Anypoint VPC architecture](/mulesoft/current/en-us/cloudhub/_images/vpc-default-arch.png)

Figure 1. The graphic shows the default Anypoint VPC architecture.

You can configure a dedicated load balancer inside your VPC, which allows you to provide custom
certificates and optionally enforce two-way SSL client authentication. If you configure proxy rules
that map your applications to custom domains, you can, for example, host everything under a single
vanity domain.

![Anypoint VPC architecture with a dedicated load balancer](/mulesoft/current/en-us/cloudhub/_images/vpc-dlb-arch.png)

Figure 2. The graphic shows the Anypoint VPC architecture with a dedicated load balancer.

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 VPC.

Each dedicated load balancer has a DNS A record `_lb-name_.lb.anypointdns.net` or
`_lb-name_.lb-prod-eu-rt.anypointdns.net` (for EU control plane) that resolves to two public IP
addresses of its two instances.  
Through your DNS provider, you can add a `CNAME` record pointing to the dedicated `A` record and use
your own domain names to access it. This DNS A record can also be reached from outside the VPC.  
Additionally, a 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_.lb.anypointdns.net`.

## See Also

- [Resolve Private Domains in Your Internal Network](https://docs.mulesoft.com/cloudhub/resolve-private-domains-vpc-task)