# mulesoft CloudHub 2.0 - Full Documentation --- product: CloudHub 2.0 --- # Anypoint Virtual Private Network > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint VPN (virtual private network) creates a secure connection between your private space and your on-premises network. Anypoint VPN enables apps running in the private space to access resources in your on-premises data centers behind your corporate firewall. You can create multiple site-to-site VPNs if required. > [!NOTE] The number of VPNs you can create depends on the network connection entitlements available > to your account. Contact your MuleSoft account representative if you don’t know how many network > connection entitlements you have on your account. Anypoint VPN supports site-to-site Internet Protocol security (IPsec) connections between the private space and the VPN endpoint, a _gateway device_, a physical or software appliance located in your network. The MuleSoft side of the connection is an implementation of a virtual private gateway (VGW). The MuleSoft VGW is associated with a single private space but can support up to 10 VPN connections. > [!NOTE] MuleSoft implementation capabilities might vary from other VGW offerings. ![IPsec Tunnel Overview](/mulesoft/current/en-us/cloudhub-2/_images/ps-overview-ipsec.png) To create an Anypoint VPN connection to your network, see [Create a Connection to an External Network](https://docs.mulesoft.com/cloudhub-2/ps-create-configure#create-connection-to-external-network). ## 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. Routine maintenance can briefly disable one of the two tunnels of your VPN connection. Your VPN connection automatically fails over to the second tunnel during this time, so access is not interrupted. For this reason, you must configure both tunnels 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 private space 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. Anypoint VPN also supports _high availability_, wherein each Anypoint VPN connection consists of two endpoints to lessen the likelihood of connection failures. ## 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) ## 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 You must specify the routes (subnets) in your network accessible through Anypoint VPN. You can remove routes for static VPN connections. ### Anypoint VPN Routing Limitations - A maximum of 95 route table entries is permitted per private space, regardless of the number of VPN connections. To avoid exceeding the limit, consolidate networks to the fewest number possible. - You can’t add a route that matches a priority route (a route that your private network uses). - Only one connection can use a route at a time. If you enter a non-local/Internet Gateway (IGW) route to a route table, CloudHub 2.0 warns that another connection uses the route. - Routes should not overlap with existing routes. You receive a warning if you enter a route that overlaps with another route in the route table. ## Anypoint VPN Limitations Anypoint VPN does not support these features and configurations: - Network Address Translation (NAT) - IPv6 - IKEv2 with policy-based VPNs - 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 - Use 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 private space through one tunnel and traffic returns from the private space 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 support: - Establishing BGP peering - Using route-based VPNs (bind tunnels to logical interfaces) - For IPsec, enabling perfect forward secrecy (PFS) with the above Phase 2 Diffie-Hellman groups ## Anypoint VPN 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`. ## VPN High Availability To ensure your applications and related operations are tolerant to Anypoint VPN updates or issues, or individual customer gateway failures, implement high availability VPN connections. Set up a redundant VPN connection to prevent losing connectivity if another VPN or connection device is unavailable and allow for maintenance downtime. The redundant VPN inherits some settings from the initial VPN configuration automatically. For example, if the routing type for the initial VPN is dynamic (BGP), the redundant VPN is also dynamic. Other settings for the redundant VPN, such as the remote ASN for dynamic routing, include the values from the initial VPN, but you can change the values. To configure a redundant VPN connection, you must: - Have two VPN endpoints available in your network that use different public IP addresses. Each gateway device supports a single VPN. - Create two VPN connections in your private space. ### Configure High Availability with Anypoint VPN The following example shows a high availability VPN topology using a single Anypoint VPC and two VPN connections. A MuleSoft Virtual Private Gateway (VGW) supports one Anypoint VPC association, but it supports up to 10 VPN connections. You can locate your VPN Gateways in the same data center, or in different physical locations. ![VPN High Availability Topology](/mulesoft/current/en-us/cloudhub-2/_images/vpn-ha-topology.png) Use BGP routing to advertise the same routes via VPN-1 and VPN-2. See [Anypoint VPN Path Selection using BGP Routing](https://help.salesforce.com/s/articleView?id=001116889&type=1) for instructions on how to control path selection via the routing protocol. 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 to 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. ### How VPN Failover Works Failover to a redundant VPN depends on the routing type: - Dynamic (BGP) - Static Failover for dynamic or BGP VPNs is automatic. For static VPN failover, you must manually fail over to the other available VPN by modifying the routes. ### VPN and Tunnel Status New VPN connections that you create appear in the **Connections** section of the private space. Initially, both VPN tunnels display DOWN while the infrastructure is created. Depending on your configuration, tunnels might report a status of DOWN during normal operations.
StatusTunnel 1/2Description

Pending

DOWN/DOWN

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.

Available

DOWN/DOWN

The VPN connection is created, but the remote side is not configured or is not sending traffic.

Available

Up/Up or Up/Down

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.

Failed

DOWN/DOWN

The VPN connection is not created.

Delete the VPN and try again. If this failure recurs, contact MuleSoft Support.

## See Also - [Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure) - [Private Network Region](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#private-network-region) - [Configuring Firewall Rules to Manage Traffic to and from a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules) - [Dynamic VPN Connection Requirements](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#dynamic-vpn-routing) - [Static VPN Connection Requirements](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#static-vpn-routing) - [Supported Gateway Devices](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#supported-gateway-devices) --- product: CloudHub 2.0 --- # Assigning Permissions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before you set up your private space, ensure you have the required permissions assigned to your user account or a team to which you belong. To assign permissions, you need access to Access Management and the Organization Administrator permission. - To set up and manage a private space, you need the CloudHub Network Administrator permission. - To view a private space as an individual user within an organization, you need at least one of the following permissions: - Cloudhub Network Viewer, which enables you to view private spaces and their details. - Organization Administrator, which enables you to manage and update private spaces. - Cloudhub Network Administrator, which enables you to manage and update private spaces. Without at least one of these permissions, you can’t see any details upon selecting the **Private Spaces** tab. Instead, you receive a **Not Authorized** message. - To deploy applications from Exchange, you must assign the Exchange Contributor and Exchange Viewer permissions to the Business Organization that owns the asset. - To deploy applications in Runtime Manager, you need the Create Applications permission. - To view all applications on the **Applications** page in Runtime Manager, you need the Read Applications and CloudHub Network Viewer permission. - To view applications deployed to Runtime Fabric and CloudHub 2.0, you also need the following two permissions: - Read Applications for the Environment. - Read Runtime Fabrics for the Business Group. - Assigning the **Create Applications** role to a user also gives the **Read Applications** role that is required to deploy applications. - To view the schedules in applications deployed to CloudHub 2.0 and Runtime Fabric, you must assign the Exchange Viewer permission to the Business Organization that owns the asset. Depending on your organization’s permission structure, you can assign these permissions using the [Teams](https://docs.mulesoft.com/access-management/teams) feature, the [Roles](https://docs.mulesoft.com/access-management/users#grant-user-permissions) feature (deprecated), or by assigning an [individual user permission](https://docs.mulesoft.com/access-management/users#grant-user-permissions). Note that users who have the Organization Administrator permission can also view and manage all private spaces and additional privileges across Anypoint Platform. However, you should not assign this permission as a substitute for CloudHub 2.0-specific privileges. For more information, see [general permissions](https://docs.mulesoft.com/access-management/permissions-by-product). ## See Also - [Access Management Overview](https://docs.mulesoft.com/access-management/) --- product: CloudHub 2.0 --- # Associating Business Groups and Environments with a Private Space > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before deploying to a private space, you can specify environments and at least one business group to associate with it. This association specifies in which environments the private space appears as a target deployment in the **Deployment Target** list when deploying an app. For information, see [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space). You can associate a private space with the production and sandbox environments in the business group, and its child business groups, that it’s registered with or with a subset of business groups. By default, a private space is associated with all sandbox environments in its business groups. ## Associate Business Groups and Environments If you have the CloudHub Network Administrator permission, associate environments in the business group or groups with the private space: 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Environments** tab to: - [Associate Business Groups](#associate-business-groups) - [Associate Environments](#associate-environments) ### Associate Business Groups 1. Select the business groups from the drop-down list: - **This business group and its children** This option allows you to select either all environments, all sandbox environment or all production environments for the selected business group and all its children. - **Selected business groups** Enter the business group name in the **Add business group** field and select it from the list. This option allows you to select specific environments for specific business groups. The list includes the business group and its child business groups to which the private space is registered and that have not yet been added. 2. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Select the business group from the drop-down list.](/mulesoft/current/en-us/cloudhub-2/_images/ps-select-business-group.png) ### Associate Environments 1. Select the environments from the drop-down list: - **All Environment** Associates the private space with all sandbox and production environments in the business group and all its children, or in specific business groups. - **All Sandbox Environments** Associates the private space with only sandbox environments in the business group and all its children, or in specific business groups. - **All Production Environments** Associates the private space with only production environments in the business group and all its children, or in specific business groups. - **Select Environments Manually** Allows you to associate the private space with specific environments in specific business groups. - Check the **Sandbox** or **Production** box to bulk select all sandbox or production environments in specific business groups. - Check the box for each specific subenvironment to individually select the desired environments in specific business groups. 2. Click **Save Changes** or **Discard Changes** to discard or confirm the association. ![Select the environments from the drop-down list.](/mulesoft/current/en-us/cloudhub-2/_images/ps-select-environment.png) ### Add or Remove Business Groups You can add or remove business groups for your private space: To add new business groups, use the **Add business group** field. To remove a business group, click the trash can icon for the entry. ![Delete icon on the Environments tab](/mulesoft/current/en-us/cloudhub-2/_images/bg-delete.png) ## Manage Resources for a Business Group If you have the Organization Administrator permission, view or manage resources associated with a business group: 1. Log in to Anypoint Platform using an account that has the Organization Administrator permission. 2. In the navigation bar or the main Anypoint Platform page, click **Access Management**. 3. In the Access Management navigation menu, click **Business Groups**. 4. Click the **Settings** tab. 5. In the **Resources** section, view or modify the allocation for a resource, such as **Production vCores**. 6. Click **Save Changes** or **Discard Changes**. If **Business Groups** is not in the Access Management navigation menu: 1. Log in to Anypoint Platform using an account that has the Organization Administrator permission. 2. In the navigation bar or the main Anypoint Platform page, click **Access Management**. 3. In the Access Management navigation menu, click **Organization**. 4. Click the name of the business group you want to modify. 5. View or modify the allocation for a resource, such as **Production vCores**. 6. Click **Save Changes** or **Discard Changes**. ## See Also - [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space) - [Access Management Overview](https://docs.mulesoft.com/access-management/) --- product: CloudHub 2.0 --- # Automatic App Restarts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt CloudHub 2.0 restarts your Mule applications during infrastructure failure or maintenance, security patching, replica crashes, or replica rebalancing. The CloudHub 2.0 infrastructure gracefully shuts down by draining connections, transitioning traffic to a new instance of your application replica before terminating the older instance. To ensure business resiliency, design your application to be idempotent and deploy across multiple replicas with [clustering](https://docs.mulesoft.com/cloudhub-2/ch2-clustering) enabled with a layer of persistence ([Object Store v2](https://docs.mulesoft.com/object-store/)). ## Understand Local Storage Limitations CloudHub 2.0 replica local storage is ephemeral. Unlike local development environments, CloudHub 2.0 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 2.0 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 replica’s local disk. CloudHub 2.0 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 2.0: - 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 2.0 High Availability and Disaster Recovery](https://docs.mulesoft.com/cloudhub-2/ch2-ha-dr). ## Shutdown Timeout Behavior CloudHub 2.0 overrides the Mule runtime’s default `shutdownTimeout` value to avoid disruption for long-running flows. By default, the Mule runtime sets `shutdownTimeout` to five seconds. CloudHub 2.0 extends the shutdown grace period to accommodate applications that require more time to complete in-flight processing. For infrastructure-triggered restarts (such as infrastructure failure, maintenance, security patching, private space upgrades, or replica rebalancing): - CloudHub 2.0 provides a grace period up to a maximum of 12 hours. - If no custom `shutdownTimeout` is configured, CloudHub 2.0 applies a 12-hour maximum grace period to ensure long-running flows complete without disruption. For user-triggered restarts (such as stop, restart, update, redeploy, or terminate actions): - CloudHub 2.0 honors the configured `shutdownTimeout` value from your application configuration. - CloudHub 2.0 doesn’t provide the extended 12-hour grace period. You can optionally configure the `shutdownTimeout` attribute in your Mule application configuration. See [Global Configurations Reference](https://docs.mulesoft.com/mule-runtime/latest/global-settings-configuration#global-configurations-reference). ```xml ``` ## Considerations Review these details about how each replica strategy manages application optimization: Single Replica with Recreate Strategy The sole replica is terminated first, allowing it to gracefully shut down. A new replica launches as soon as the previous replica enters Stopping status. Incoming traffic experiences a brief downtime. If the application schedule triggers during this downtime, the trigger is missed. Single Replica with Rolling Restart A new replica launches before the old replica begins its graceful shutdown. Two replicas run concurrently until the old replica is fully terminated. Once in Stopping status, the old replica stops receiving new connections or triggering application schedules. Multiple Replicas with Recreate or Rolling Restart At least two thirds of the replicas remain available throughout the optimization process. Some replicas are gracefully shut down and restarted on new infrastructure. ## Infrastructure Failure and Maintenance If the compute infrastructure suffers a failure, CloudHub 2.0 moves your application to a healthy infrastructure and restarts the application replicas. Likewise, during infrastructure maintenance, the platform moves application replicas running on a compute infrastructure that becomes impaired or end-of-life onto a new infrastructure to ensure availability. ## Karpenter Node Downscaling in Private Spaces In Private Spaces, CloudHub 2.0 uses Karpenter to manage node lifecycle. When Karpenter downscales nodes to remove underused capacity, CloudHub 2.0 restarts applications running on those nodes as replicas move to remaining nodes. Restarts occur once per week at most. Each private space has a 4-hour consolidation window. CloudHub 2.0 randomizes the start time per space so it doesn’t restart all spaces in a region at once. The 4-hour block can start anytime between Friday 10:00 PM and Saturday 2:00 AM in the Private Space region’s local time zone, so restarts can occur anytime from Friday 10:00 PM through Saturday 6:00 AM. > [!NOTE] Apps in a Private Space can restart during Karpenter node downscaling in this weekly > window. These restarts are routine maintenance, not an outage. Design for resiliency so that > restarts have minimal impact. See > [CloudHub 2.0 High Availability and Disaster Recovery](https://docs.mulesoft.com/cloudhub-2/ch2-ha-dr). ## Security Patching To mitigate security vulnerabilities, CloudHub 2.0 patches and restarts applications every month. 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. ## Replica Crash If an application replica crashes for any reason, CloudHub 2.0 automatically restarts it. If it continues to fail to start, the platform attempts to restart it using an exponential backoff policy. ## Replica Rebalancing The CloudHub 2.0 infrastructure optimizes application efficiency through replica rebalancing. This process gracefully moves and restarts replicas, provided there are at least two replicas available. During rebalancing, a maximum of 30% of an application’s replicas are rebalanced concurrently. The system rounds up this percentage to the number of replicas that can be disrupted. For example, if your application has two replicas, a disruption affects one replica, exceeding the configured 30%. This table shows the potential impact of rebalancing operations on your applications based on the number of replicas.
Total Application ReplicasMaximum Replicas Disrupted

1

1

2

1

3

1

4

2

5

2

6

2

7

3

8

3

9

3

10

3

11

4

12

4

13

4

14

5

15

5

16

5

This method ensures that the application’s configuration, including the Mule runtime version and the infrastructure, remains consistent after all restarts, except for restarts occurring after a security patching. For more details about security patching, see [CloudHub 2.0 Operating System Patch Updates](https://docs.mulesoft.com/cloudhub-2/ch2-patch-updates). --- product: CloudHub 2.0 --- # Changing App Behavior with Properties > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can change the behavior of the app while it’s running using _properties_. 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 on 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 protect the property values so that, after you save them in Runtime Manager, their values aren’t visible in the console or passed between the console and CloudHub 2.0. For information, see [Protecting App Property Values](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props). You can set properties in 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 a private space is to define them on the **Properties** tab for the application. To add properties: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Settings**. 4. On the **Settings** page, click the **Properties** tab. ![Properties with New Key and New Value fields on the application Settings page](/mulesoft/current/en-us/cloudhub-2/_images/ch2-props-rtm.png) 5. Click **Table view**. Alternatively, you can click **Text view** and enter the key-value pair in the text field in this format: `New Key=New Value`. 6. In the **New Key** field, enter the property name. 7. In the **New Value** field, enter the property value. If the property value contains spaces, enclose it in quotation marks, such as `"ApiKey 898jdey1-13232"`. > [!NOTE] 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. In **Table view**, if you want to: - Hide the value in Runtime Manager, click **Protect** and then click **Protect value** to confirm. See [Protecting App Property Values](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props). - Change a key or value, edit the text in the field. - Delete a property, click **…​** > **Delete property**. 8. Click **Apply Changes**. Applying changes creates a new configuration and restarts the replicas. For information, see [Updating Apps Deployed to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps). ### Example: Using Properties to Set Environment Variables You can 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 2.0, you might configure the database host to be an Amazon RDS server. To set an environment variable using an application property: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Settings**. 4. On the **Settings** page, click the **Properties** tab. 5. Define the variable by entering it in the **Text view**, in `key=value` format. > [!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. **Table view** syntax requires no escape character. 6. 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 a file in the property placeholder YAML file deployable application archive file. See [Configuring Properties](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties). CloudHub 2.0 then loads these properties into the application when the application starts. Although this method isn’t the best practice on CloudHub 2.0 (because the **Properties** tab values override any with the same name in the file), you can work around this by changing options in the Mule app. > [!NOTE] To mask secure property values on CloudHub 2.0, set property protection on the > **Properties** tab in Runtime Manager. Because Runtime Manager properties override archive-bundled > properties of the same name, masking values through `mule-artifact.json` or a configuration file > doesn’t take effect on CloudHub 2.0. For information, see > [Protecting App Property Values](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props). To prevent CloudHub 2.0 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). ## Limitations - You can add up to 300 properties. - Property keys and their values cannot exceed 1024 characters. ## Reserved Properties CloudHub 2.0 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 2.0 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.
PropertyDescriptionExample

${java.runtime.name}

JVM name

OpenJDK Runtime Environment

${java.version}

JVM version

1.8.0_342

${java.runtime.version}

JVM version, including dot (point) release

1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

${http.port}

HTTP port

8081

${https.port}

HTTPS port

8081

${http.private.port}

HTTP private port

8081

${https.private.port}

HTTPS private port

8081

> [!NOTE] For proprietary reasons, MuleSoft doesn’t make public all internal, reserved properties. > CloudHub 2.0 runtime release updates might change the reserved properties. ## Access Environment and Organization IDs CloudHub 2.0 provides environment and organization identifiers through environment variables. Reference these variables to retrieve the deployment environment ID and organization ID. These environment variables are available:
Environment VariableDescription

ENV_ID

Environment ID where the application is deployed

ORG_ID

Organization ID (business group ID) associated with the application

To access these values, reference them using the standard property placeholder syntax: `${ENV_ID}` or `${ORG_ID}`. ## See Also - [Configuring Properties](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties) - [Deploying Apps to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-deploy) - [Protecting App Property Values](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props) --- product: CloudHub 2.0 --- # CloudHub 2.0 API > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Programmatically manage your CloudHub 2.0 resources with two APIs: **CloudHub 2.0 API** Manages infrastructure-level resources, such as: - Manage private spaces: - List available TCP ports for a private space - Retrieve availability zones and AWS account information. - Upgrade a private space. - Manage VPC endpoints (Private Link): - Create, list, update, and delete VPC endpoints. - Get VPC endpoint details and provisioning status. - Manage VPNs: - Update VPN settings (for example, enable VPN logs). - Manage transit gateways: - Delete a transit gateway from the organization. - Manage schedulers: - Reset the scheduler configuration for a specific flow. **Application Manager API** Manages application-level resources, such as: - Deploy and update applications with TCP port mapping. For an interactive reference that includes supported resources, methods, required properties, and expected responses, see [CloudHub 2.0 API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/) and [Application Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/amc-application-manager/) on Exchange. These APIs manage only applications and infrastructure deployed to CloudHub 2.0. To manage CloudHub 1.0 resources, see [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/). ## Base URLs Each API uses a different base URL:
APIBase URL

CloudHub 2.0 API

https://anypoint.mulesoft.com/runtimefabric/api

Application Manager API

https://anypoint.mulesoft.com/amc/application-manager/api/v2

## Use the CloudHub 2.0 APIs You can use any HTTP client with the CloudHub 2.0 APIs. To access operations, you must: 1. Generate an authorization bearer token to authenticate with the API. Follow the instructions from [Anypoint identity](https://docs.mulesoft.com/access-management/saml-bearer-token) or [external identity](https://help.salesforce.com/s/articleView?id=001115323&type=1) to get a bearer access token for your Anypoint organization. The token owner must have the appropriate permissions for the resources being managed. For example, managing private spaces requires private space management permissions. 2. Get the organization 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 [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. 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 [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/). ### List VPC Endpoints for a Private Space To list all VPC endpoints for a private space, run the following `curl` command: ```curl curl -X GET \ --url https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces \ -H 'Authorization: Bearer AUTH_BEARER_TOKEN' ``` ## 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 list VPC endpoints: ```json [ { "name": "S3-Global", "vpceId": "ec6a2988-5529-4fac-9262-9b9962ce0b50", "serviceName": "com.amazonaws.s3-global.accesspoint", "serviceRegion": "us-east-1", "serviceOwner": "amazon", "azIds": ["use1-az1", "use1-az2"] }, { "name": "Custom Service", "vpceId": "fc5c9c55-d943-4383-88ac-cc2b51446d54", "serviceName": "com.amazonaws.vpce.us-east-1.vpce-svc-03cef49533264d928", "serviceRegion": "us-east-1", "serviceOwner": "055970264539", "azIds": ["use1-az1"] } ] ``` ## Rate Limits The CloudHub 2.0 API enforces a global rate limit of 15 requests per second per remote IP address. When you reach the rate limit, the API returns a `429` status code. ## Status Codes and Error Handling When you call the CloudHub 2.0 APIs, the following status codes are returned:
Status CodeDescription

200

The operation was successful.

201

The resource was created.

The Location header contains the location of the resource.

400

The request was invalid. Check the request body for details.

401

Authentication failed. Verify your bearer token.

403

The authenticated user doesn’t have the required permissions.

404

The resource was not found.

429

The operation was unsuccessful due to reaching the rate limit.

Retry the operation after a short delay.

500

The operation was unsuccessful.

See the HTTP body for details.

When errors occur, the HTTP response contains a JSON body with an error message: ```json { "message": "Some error message." } ``` ## See Also - [CloudHub 2.0 API Reference](https://docs.mulesoft.com/cloudhub-2/ch2-api-reference) - [CloudHub 2.0 API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/) - [Application Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/amc-application-manager/) - [Access Management API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/) - [Deploying Apps to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-deploy) - [Setting Up an Outbound Private Link Connection](https://docs.mulesoft.com/cloudhub-2/ps-outbound-private-link) --- product: CloudHub 2.0 --- # CloudHub 2.0 API Reference > For the full documentation index, see: https://docs.mulesoft.com/llms.txt These tables list the most commonly used CloudHub 2.0 API endpoints grouped by category. Each row identifies which API the endpoint belongs to:
APIBase URL

CloudHub 2.0 API

https://anypoint.mulesoft.com/runtimefabric/api

Application Manager API

https://anypoint.mulesoft.com/amc/application-manager/api/v2

For full details on request parameters, payloads, and responses, see [CloudHub 2.0 API reference on Exchange](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/) and [Application Manager API reference on Exchange](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/amc-application-manager/). ## Deployments (TCP) Use these Transmission Control Protocol (TCP) endpoints to deploy and update applications with TCP port mappings.
MethodAPIEndpointDescription

POST

Application Manager

/organizations/{orgId}/environments/{envId}/deployments

Deploy a new application with TCP port mapping.

PATCH

Application Manager

/organizations/{orgId}/environments/{envId}/deployments/{deploymentId}

Update an existing application’s TCP port mapping.

For detailed request and response examples, see [Deploy an App with TCP using the Application Manager API](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-api). ## Private Spaces Use these endpoints to retrieve infrastructure information about a private space, such as available TCP ports, availability zones, and the Amazon Web Services (AWS) account ID.
MethodAPIEndpointDescription

GET

CloudHub 2.0

/organizations/{orgId}/privatespaces/{spaceId}/ports?available=true&count=10

List available TCP ports for a private space.

GET

CloudHub 2.0

/organizations/{orgId}/privatespaces/{spaceId}/azs

List availability zones for a private space.

GET

CloudHub 2.0

/organizations/{orgId}/privatespaces/{spaceId}/accounts

Get the AWS account ID associated with a private space.

For more information, see [Deploy an App with TCP using the Application Manager API](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-api) and [Setting Up an Outbound Private Link Connection](https://docs.mulesoft.com/cloudhub-2/ps-outbound-private-link). ## VPC Endpoints (Private Link) Use these endpoints to manage Virtual Private Cloud (VPC) endpoints that provide private connectivity through AWS Private Link.
MethodAPIEndpointDescription

POST

CloudHub 2.0

/organizations/{orgId}/privatespaces/{spaceId}/vpces

Create a VPC endpoint for a private space.

GET

CloudHub 2.0

/organizations/{orgId}/privatespaces/{spaceId}/vpces

List all VPC endpoints for a private space.

GET

CloudHub 2.0

/organizations/{orgId}/privatespaces/{spaceId}/vpces/{vpceId}

Get VPC endpoint details and provisioning status.

PATCH

CloudHub 2.0

/organizations/{orgId}/privatespaces/{spaceId}/vpces/{vpceId}

Update a VPC endpoint.

DELETE

CloudHub 2.0

/organizations/{orgId}/privatespaces/{spaceId}/vpces/{vpceId}

Delete a VPC endpoint.

For detailed curl examples, see [Setting Up an Outbound Private Link Connection](https://docs.mulesoft.com/cloudhub-2/ps-outbound-private-link). ## VPNs Use these endpoints to manage Virtual Private Network (VPN) connections for a private space.
MethodAPIEndpointDescription

PATCH

CloudHub 2.0

/organizations/{orgId}/privatespaces/{spaceId}/connections/{connectionId}/vpns/{vpnId}

Update a VPN (for example, enable VPN logs).

For more information, see [Managing Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-manage). ## Transit Gateways Use these endpoints to manage AWS Transit Gateway attachments for your organization.
MethodAPIEndpointDescription

DELETE

CloudHub 2.0

/organizations/{orgId}/transitgateways/{tgwId}

Delete a transit gateway from the organization.

For more information, see [Managing Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-manage) and the [delete transit gateway API calls](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/minor/1.0/console/method/%234136/). ## Schedulers Use these endpoints to manage Scheduler component configurations for deployed applications. > [!NOTE] The CloudHub schedules REST API doesn’t expose scheduler or domain details for CloudHub > 2.0 applications. Manage CloudHub 2.0 schedulers only through the CloudHub 2.0 APIs or the Runtime > Manager **Schedules** tab. See [Managing App Schedules](https://docs.mulesoft.com/cloudhub-2/ch2-manage-schedules).
MethodAPIEndpointDescription

DELETE

CloudHub 2.0

/organizations/{orgId}/environments/{envId}/deployments/{deploymentId}/schedulers/{flowName}

Reset the scheduler configuration for a specific flow.

For more information, see [Managing App Schedules](https://docs.mulesoft.com/cloudhub-2/ch2-manage-schedules). ## See Also - [CloudHub 2.0 API](https://docs.mulesoft.com/cloudhub-2/ch2-api) --- product: CloudHub 2.0 --- # CloudHub 2.0 Architecture > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To understand CloudHub 2.0 security and availability, you should understand the architecture behind CloudHub 2.0. CloudHub 2.0 architecture comprises two major components: Anypoint Platform services and shared global regions. These two components, along with Anypoint Runtime Manager through which you access them, work together to run your integration applications. ![CloudHub 2.0 Architecture with four callouts](/mulesoft/current/en-us/cloudhub-2/_images/ch2-architecture.png)

1 Integration Applications

Applications that you create and deploy to CloudHub 2.0 to perform integration logic for your business

2 Runtime Manager

User interface that enables you to deploy and monitor integrations, and setup the runtime plane

3 Platform Services

Shared CloudHub 2.0 platform services and APIs, which include Anypoint Monitoring, alerting, logging, account management, private spaces/secure data gateway, and load balancing

4 CloudHub 2.0

An elastic cloud of replicas, Mule instances that run integration applications

> [!NOTE] You can view the live status and detailed service history for Runtime Manager, platform > services, and CloudHub 2.0 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 2.0 Overview](https://docs.mulesoft.com/cloudhub-2/) and [Deploying Apps to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-deploy). ## Runtime Manager Runtime Manager is integrated into [Anypoint Platform](https://anypoint.mulesoft.com). Sign in with your Anypoint Platform credentials to deploy and manage your integration applications at runtime. The console provides monitoring information from the platform services and also functions as a comprehensive dashboard for both application-level and account-level management. Administrator account holders can use the Anypoint Platform to add and manage other users in the organization, define user roles, and create and manage sandbox environments. For information, see [Access Management Overview](https://docs.mulesoft.com/access-management/). ## Platform Services 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 2.0 REST API. ## CloudHub 2.0 Replicas _Replicas_ are dedicated instances of Mule runtime engine that run your integration applications on CloudHub 2.0. Replicas have the following characteristics: **Capacity** Each replica has a specific amount of capacity to process data. Select the size of your replicas when configuring an application. **Isolation** Each replica runs in a separate container from every other application. **Manageability** Each replica is deployed and monitored independently. **Locality** Each replica runs in a specific global region, such as the US, EU, or Asia-Pacific. The memory capacity and processing power of a replica depends on how you configure it at the application level. Replica sizes have different compute, memory, and storage capacities. You can scale replicas vertically by selecting one of the available vCore sizes:
vCore SizeTotal MemoryHeap MemoryStorage

0.1

1.4 GB

480 MB

8 GB

0.2

2 GB

1 GB

8 GB

0.5

2.6 GB

1.3 GB

10 GB

1

4 GB

2 GB

12 GB

1.5

6 GB

3 GB

20 GB

2

8 GB

4 GB

20 GB

2.5

9.5 GB

4.75 GB

20 GB

3

11 GB

5.5 GB

20 GB

3.5

13 GB

6.5 GB

20 GB

4

15 GB

7.5 GB

20 GB

Replicas with fewer than 1 vCore: - 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. Note that application bursting depends on resource availability for nodes and is not guaranteed to occur. If you need consistent performance, use replicas with more vCores. Replicas with 1 or more vCores provide performance consistency. Each replica has a minimum of 8 GB of storage, which is used for both system and application storage. If your application requires more storage (for example, verbose logging), use a replica with two or more vCores, enabling the application to access additional storage in `/tmp`. All running applications count toward replica usage. Stopped applications do not. If your applications require more vCores than are available, CloudHub 2.0 allows you to create the application, but you cannot start it until the additional vCores become available. To increase vCore allocation, stop or delete an application or contact your account manager to increase your subscription’s vCore allocation. The metaspace limit for apps deployed to CloudHub 2.0 is currently 256 MB, regardless of the replica 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 replicas for persistent queues. See [Replica Scale-out](https://docs.mulesoft.com/cloudhub-2/ch2-clustering#replica-scale-out). CloudHub 2.0 monitors replicas to verify that they are operating correctly, and automatically restarts applications if necessary. ## CloudHub 2.0 Resourcing for Anypoint Integration Customers If your organization uses the Anypoint Integration Starter package or Anypoint Integration Advanced package, CloudHub 2.0 uses replica sizing for application deployment. You can choose from the following replica sizes based on the application profile or size and display the equivalent in terms of vCores:
OfferingEquivalent vCore SizeTotal MemoryHeap MemoryStorage

mule.nano

0.05

1 GB

0.5 GB

8 GB

mule.micro

0.1

1 GB

0.5 GB

8 GB

mule.micro.mem

0.1

2 GB

1 GB

8 GB

mule.small

0.2

2 GB

1 GB

8 GB

mule.medium

0.5

3 GB

1.5 GB

10 GB

mule.medium.mem

0.5

5 GB

2.5 GB

10 GB

mule.large

1

4 GB

2 GB

12 GB

mule.large.mem

1

8 GB

4 GB

12 GB

mule.xlarge

2

7 GB

3.5 GB

20 GB

mule.xlarge.mem

2

12 GB

6 GB

20 GB

mule.2xlarge.mem

4

15 GB

7.5 GB

20 GB

Replica sizes with the suffix `.mem` are memory-intensive options with the same compute. During the monthly patching cycle, your applications automatically migrate to an equivalent replica size. You can deploy applications using the Runtime Manager UI or the Mule Maven Plugin. You can also use the Application Manager Experience APIs by leveraging a new field under `target.deploymentSettings` called `instanceType`. For more information, see [API Community Manager](https://docs.mulesoft.com/api-community-manager/). ## Shared Global Regions CloudHub 2.0 provides the ability to deploy apps in different regions of the world: North America, South America, the European Union, and Asia-Pacific. 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 Cloud and MuleSoft Government Cloud control planes, MuleSoft hosts the management console and platform services in the United States. For the EU Cloud control plane, MuleSoft hosts these services in Europe. The region that you deploy your application to determines the domain provided for your application. The load balancer that CloudHub 2.0 uses to route requests resides in the same region as your application. ### Runtime Plane Regions and DNS Records A runtime region is the geographic location where CloudHub 2.0 runs your application. You select it at deploy time. It is independent of control plane data residency: deploying to Canada (Montreal) from US Cloud does not give you Canada Cloud. The region determines the DNS record and the load balancer for your application. The **Region** value is the token used in CloudHub 2.0 DNS records. Private spaces use the same **Region** token: - Public: `...cloudhub.io` - Internal: `.internal-..cloudhub.io` For private space DNS records, see [DNS Records](https://docs.mulesoft.com/cloudhub-2/ch2-networking-guide#dns-records).
Control PlaneGeographic AreaRuntime LocationRegionTarget IDTarget NameExample DNS RecordExample Internal DNS Record

US Cloud

North America

US East (N. Virginia)

usa-e1

cloudhub-us-east-1

Cloudhub-US-East-1

myapp-uniq-id.shard.usa-e1.cloudhub.io

<app>.internal-<space-id>.usa-e1.cloudhub.io

US East (Ohio)

usa-e2

cloudhub-us-east-2

Cloudhub-US-East-2

myapp-uniq-id.shard.usa-e2.cloudhub.io

<app>.internal-<space-id>.usa-e2.cloudhub.io

US West (N. California)

usa-w1

cloudhub-us-west-1

Cloudhub-US-West-1

myapp-uniq-id.shard.usa-w1.cloudhub.io

<app>.internal-<space-id>.usa-w1.cloudhub.io

US West (Oregon)

usa-w2

cloudhub-us-west-2

Cloudhub-US-West-2

myapp-uniq-id.shard.usa-w2.cloudhub.io

<app>.internal-<space-id>.usa-w2.cloudhub.io

Canada (Montreal)

can-c1

cloudhub-ca-central-1

Cloudhub-CA-Central-1

myapp-uniq-id.shard.can-c1.cloudhub.io

<app>.internal-<space-id>.can-c1.cloudhub.io

South America

Brazil (São Paulo)

bra-s1

cloudhub-sa-east-1

Cloudhub-SA-East-1

myapp-uniq-id.shard.bra-s1.cloudhub.io

<app>.internal-<space-id>.bra-s1.cloudhub.io

Asia Pacific

Singapore (Singapore)

sgp-s1

cloudhub-ap-southeast-1

Cloudhub-AP-Southeast-1

myapp-uniq-id.shard.sgp-s1.cloudhub.io

<app>.internal-<space-id>.sgp-s1.cloudhub.io

Australia (Sydney)

aus-s1

cloudhub-ap-southeast-2

Cloudhub-AP-Southeast-2

myapp-uniq-id.shard.aus-s1.cloudhub.io

<app>.internal-<space-id>.aus-s1.cloudhub.io

Japan (Tokyo)

jpn-e1

cloudhub-ap-northeast-1

Cloudhub-AP-Northeast-1

myapp-uniq-id.shard.jpn-e1.cloudhub.io

<app>.internal-<space-id>.jpn-e1.cloudhub.io

Europe

Ireland (Dublin)

irl-e1

cloudhub-eu-west-1

Cloudhub-EU-West-1

myapp-uniq-id.shard.irl-e1.cloudhub.io

<app>.internal-<space-id>.irl-e1.cloudhub.io

Germany (Frankfurt)

deu-c1

cloudhub-eu-central-1

Cloudhub-EU-Central-1

myapp-uniq-id.shard.deu-c1.cloudhub.io

<app>.internal-<space-id>.deu-c1.cloudhub.io

UK (London)

gbr-e1

cloudhub-eu-west-2

Cloudhub-EU-West-2

myapp-uniq-id.shard.gbr-e1.cloudhub.io

<app>.internal-<space-id>.gbr-e1.cloudhub.io

EU Cloud

Europe

Ireland (Dublin)

irl-e1.eu1

cloudhub-eu-west-1

Cloudhub-EU-West-1

myapp-uniq-id.shard.irl-e1.eu1.cloudhub.io

<app>.internal-<space-id>.irl-e1.eu1.cloudhub.io

Germany (Frankfurt)

deu-c1.eu1

cloudhub-eu-central-1

Cloudhub-EU-Central-1

myapp-uniq-id.shard.deu-c1.eu1.cloudhub.io

<app>.internal-<space-id>.deu-c1.eu1.cloudhub.io

Canada Cloud

North America

Canada (Montreal)

can-c1

cloudhub-ca-central-1

Cloudhub-CA-Central-1

myapp-uniq-id.shard.can-c1.ca1.cloudhub.io

<app>.internal-<space-id>.can-c1.ca1.cloudhub.io

Japan Cloud

Asia Pacific

Japan (Tokyo)

jpn-e1

cloudhub-ap-northeast-1

Cloudhub-AP-Northeast-1

myapp-uniq-id.shard.jpn-e1.jp1.cloudhub.io

<app>.internal-<space-id>.jpn-e1.jp1.cloudhub.io

India Cloud

Asia Pacific

India (Mumbai)

ind-w1

cloudhub-ap-south-1

Cloudhub-AP-South-1

myapp-uniq-id.shard.ind-w1.in1.cloudhub.io

<app>.internal-<space-id>.ind-w1.in1.cloudhub.io

Australia Cloud

Asia Pacific

Australia (Sydney)

aus-s1

cloudhub-ap-southeast-2

Cloudhub-AP-Southeast-2

myapp-uniq-id.shard.aus-s1.au1.cloudhub.io

<app>.internal-<space-id>.aus-s1.au1.cloudhub.io

United Kingdom Cloud

Europe

United Kingdom (London)

gbr-e1

cloudhub-eu-west-2

Cloudhub-EU-West-2

myapp-uniq-id.shard.gbr-e1.gb1.cloudhub.io

<app>.internal-<space-id>.gbr-e1.gb1.cloudhub.io

MuleSoft Government Cloud

US Government

US GovCloud (West)

usg-w1.gov

-

-

myapp.usg-w1.gov.cloudhub.io

-

For example, if you deploy an application named `myapp` to Canada (Montreal) in a shared space on US Cloud, the domain used to access the application is `myapp-_uniq-id_._shard_.can-c1.cloudhub.io`. > [!NOTE] URL formats vary by control plane: > > US Cloud Control Plane > > URLs don’t include a region suffix before `cloudhub.io`. > Example: `myapp.usa-e1.cloudhub.io` > > Non-US Control Planes > > URLs include a region suffix (such as `eu1`, `ca1`, `jp1`, or `in1`) before `cloudhub.io`. > Examples: `myapp.irl-e1.eu1.cloudhub.io`, `myapp.can-c1.ca1.cloudhub.io`, > `myapp.jpn-e1.jp1.cloudhub.io`, `myapp.ind-w1.in1.cloudhub.io` CloudHub 2.0 backend services determine the values of: `uniq-id` A 6-digit value appended to the app name to ensure uniqueness, such as `a9cdqr`. `shard` A 6-digit value associated with the private space that the app is deployed to, such as `q9opcf`. A 6-digit value followed by hyphen (`-`) and number, associated with the shared space that the app is deployed to, such as `bsb3v6-2`. CloudHub 2.0 assigns each private space a value for `shard`. For apps deployed to shared spaces, each region might have multiple `shard` values. When an app is stopped or restarted, the `shard` value does not change. However, when an app is deleted and redeployed in a shared space, the `shard` value might change. DNS records are unique to each control plane. Although the EU control plane supports some of the same regions that the US control plane supports, the DNS records are different. For more on Anypoint Platform control planes, including EU Cloud, see [Anypoint Platform Control Planes Overview](https://docs.mulesoft.com/control-planes/). For example, if you are using the US control plane and deploy to the Ireland region, the DNS records for external and internal IP addresses are `myapp-_uniq-id_._shard_.irl-e1.cloudhub.io` and `myapp-_uniq-id_.internal-_shard_.irl-e1.cloudhub.io`. ## Multitenancy Because different levels of security and isolation are needed depending on the service, the platform provides three different levels of multitenancy. - The shared global region is a multitenant cloud of virtual machines (VMs). These VMs provide the security and isolation needed for your integrations to run custom code without affecting others. - If required, you can create single-tenant _private spaces_, which are virtual, private, and isolated areas in CloudHub 2.0 in which to run your apps. For information, see [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about). - The management console and platform services have a _shared everything_ architecture; all tenants share the same web UI, monitoring services, and load balancers. These services do not process or transmit your data. ## Availability and Scalability CloudHub 2.0 is designed to be highly available and scalable through redundancy, intelligent healing, and zero-downtime updates. It also enables you to scale and benefit from added reliability using [clustering](https://docs.mulesoft.com/cloudhub-2/ch2-clustering). ### Redundant Platform All CloudHub 2.0 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 2.0 monitors the replicas for problems and provides a self-healing mechanism to recover from them. If the underlying hardware experiences a failure, the platform migrates your application to a new replica 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 redeploy the replica automatically. ### Zero-Downtime Updates CloudHub 2.0 supports updating your applications at runtime so end users of your HTTP APIs experience zero downtime. If the application uses the rolling update deployment model, CloudHub 2.0 keeps the old version of your application running while your application update is deploying. 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. > [!NOTE] In some edge cases of applications using the rolling update deployment model, long > inflight requests aren’t completed during the grace period. In this scenarios, zero downtime isn’t > guaranteed, as the old instance of the application needs to be restarted during the upgrade. ### Clustering Clustering provides scalability, workload distribution, and added reliability to applications on CloudHub 2.0. These capabilities are powered by the scalable load-balancing service and replica scaleout features. For more information, see [Clustering](https://docs.mulesoft.com/cloudhub-2/ch2-clustering). #### Scale Out and Data Center Redundancy With [clustering](https://docs.mulesoft.com/cloudhub-2/ch2-clustering), you can add multiple replicas to your application to make it horizontally scale. CloudHub automatically distributes multiple replicas for the same application across two or more data centers for maximum reliability. When deploying your application to two or more replicas, the HTTP load balancing service distributes requests across these replicas, enabling you to scale your services horizontally. CloudHub distributes requests on a round-robin basis. ## Application Monitoring and Automatic Restarts CloudHub 2.0 monitors all applications and restarts them automatically if necessary so that your applications recover without your intervention. CloudHub 2.0 displays a notification that the app is restarting and another to report the success or failure of the restart. The logs report the details of the restart procedure. You can also receive alerts and diagnostic information if your application becomes unresponsive. For more information, see [Configuring Application Alerts](https://docs.mulesoft.com/cloudhub-2/ch2-config-app-alerts). ## Security CloudHub 2.0 architecture provides a secure platform for your integrations. CloudHub 2.0 does not inspect, store, or otherwise interact directly with payload data. CloudHub replicas provide a secure facility for transmitting and processing data by giving each application its own container. This ensures complete isolation between tenants for payload security, and isolation from other tenants’ code. CloudHub 2.0 collects monitoring, analytics, and log data from CloudHub replicas and might perform actions on behalf of the user. All communication between platform services and CloudHub is secured using SSL with client certificate authentication, ensuring that unauthorized parties cannot read data or initiate unauthorized actions. You can also [protect application property values](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props). Protected property values are not viewable or retrievable by any user. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization. ### Application License Every application deployed to CloudHub 2.0 runs with a shared cloud license that MuleSoft manages on behalf of all customers. This is the same license for all CloudHub applications across all customer organizations. When you inspect the Mule runtime logs for a deployed application, the license information displays these details: - Evaluation flag: Set to `false`. The license is a production-grade license, not a trial. - Contact information: References an internal MuleSoft account, not your organization. The contact name, email, and company name belong to MuleSoft. The company name displays as "Mulesoft Trial Account," but this doesn’t mean the license is a trial. It is the name of the internal account MuleSoft uses to generate CloudHub cloud licenses. - Expiration date: Shows a far-future date. This extended validity is standard for CloudHub cloud licenses. - Entitlements: Lists a broad set of connectors and modules. This doesn’t reflect your organization’s specific subscription entitlements. All of these details are expected. The license is not specific to your organization. MuleSoft reuses the same license for all CloudHub deployments to simplify platform-wide license management. Your organization’s actual entitlements, including vCore allocation, region access, and feature availability, are governed by your Anypoint Platform subscription, not by the license embedded in the deployed application. The license visible in the runtime logs doesn’t grant access beyond what your subscription allows. ## See Also - [Managing Apps Deployed to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-manage-apps) - [Monitoring Apps Deployed to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-monitor-apps) - [Protecting App Property Values](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props) - [Configuring Application Alerts](https://docs.mulesoft.com/cloudhub-2/ch2-config-app-alerts) - [status.mulesoft.com](https://status.salesforce.com/products/Mulesoft) - [eu1-status.mulesoft.com](https://status.salesforce.com/products/Mulesoft) - [Anypoint Cloud Security & Compliance whitepaper](https://www.mulesoft.com/sites/default/files/security-whitepaper.pdf) - [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies) --- product: CloudHub 2.0 --- # CloudHub 2.0 for CloudHub 1.0 Users > For the full documentation index, see: https://docs.mulesoft.com/llms.txt CloudHub 2.0 improvements make it easier to learn, develop, and manage than CloudHub 1.0. Benefits include: - Seamless Mule clustering for deployments with more than one replica - Container-based application deployment to regulate resource consumption, ensure application availability, and enable scalability - Deploying applications to shared spaces, which do not require advanced setup or infrastructure maintenance - Amazon Web Services (AWS) service roles for resource access control - More granular vCore allocation options - Outbound firewall rule configuration - Ingress self-service logs For a complete list of CloudHub 2.0 features, see [CloudHub 2.0 Features](https://docs.mulesoft.com/cloudhub-2/ch2-features). ## Technical Enhancements from CloudHub 1.0 to CloudHub 2.0 The following improvements have been made to features that are also available in CloudHub 1.0: - With the added fractional vCore offerings in CloudHub 2.0, you may no longer need to bundle multiple listeners in the same application to reduce your resource usage. - In CloudHub 2.0, private spaces function as improved VPCs from CloudHub 1.0. You can automatically assign a private network for the applications in a private space. You can also configure a private ingress load balancer that auto-scales to accommodate traffic. - By default, VPNs allow high availability. - Applications now have [endpoints and internal endpoints](https://docs.mulesoft.com/cloudhub-2/ch2-config-endpoints-paths) by default. You can also configure multiple endpoints. You can access the endpoint addresses in Runtime Manager. - You can make in-place edits and updates to the TLS context and truststore of the ingress layer. - In CloudHub, application names must be unique per control plane. In CloudHub 2.0, each name is unique per Business Group and Private Space. You can reuse a name in another Business Group or Private Space unless your organization has application name uniqueness enabled across Business Groups. > [!NOTE] When application name uniqueness is off (the default), you can use the same name in > different Business Groups if the name is unique within each Business Group and Private Space. > When the feature is on, names must be unique across all Business Groups in the organization. > > The platform controls this behavior with the feature flag > `app_mgr_quotas_app_name_uniqueness_enabled`. You can’t configure it. Contact MuleSoft Support > to confirm whether your organization has the feature enabled. - Custom log4j.xml is supported by default to enable [streaming logs](https://docs.mulesoft.com/cloudhub-2/ch2-integrate-log-system) to external log collectors. You no longer need to contact Support to enable or disable this feature. - You can disable log streaming using Runtime Manager. You no longer need to contact Support to enable or disable this feature. - Self-service logs for the dedicated load balancer and ingress are available via a private space. Titanium users can also download logs through Anypoint Monitoring. - Using ports 80 and 443, applications inside a private space can communicate using internal load balancer via the internal endpoint. This depends on application protocol. ## Considerations and Limitations While CloudHub 2.0 has many improvements from CloudHub 1.0, organizations should consider the following nuances before switching. ### Infrastructure Considerations CloudHub 2.0 infrastructure behavior deviates from CloudHub 1.0 in the following ways: - CloudHub 1.0 VPC peering and direct connect have been deprecated in CloudHub 2.0. You can now use transit gateway attachments. Further, when you delete a private space that has a transit gateway attached, the transit gateway is preserved, and you can reattach it to a different private space. - Unlike VPCs in CloudHub 1.0, you can associate a private space with multiple environments based only on the type of the environment, such as sandbox or production. You can now choose which environment type and individual business groups with which you share private spaces. - To move applications between regions, you must redeploy the application to another shared space or private space in a different region. You cannot move the app to a different region once deployed. - HTTP and HTTPS traffic uses port 8081. - You cannot create a VPN connection between a CloudHub 1.0 VPC and a CloudHub 2.0 private space. - When migrating from CloudHub 1.0 to CloudHub 2.0, the migration tool discovers two availability zones (AZs) for the CloudHub 1.0 VPC and creates the CloudHub 2.0 private space cluster with two AZs. This results in two sets of inbound and outbound static IP addresses (one per availability zone). Plan your network allowlists and firewall rules accordingly, as your private space will have more IP addresses than a single-AZ configuration. CloudHub 2.0 does not support the following infrastructure features or functions that CloudHub 1.0 supports: - [Get From Sandbox functionality](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub#copy-an-application-from-sandbox-to-production.adoc) - Insights. Use [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) instead. ### Application Considerations CloudHub 2.0 application behavior deviates from CloudHub 1.0 in the following ways: - Only Mule 4.3.0 and later versions are supported. - Application bursting depends on the resource usage of other applications that are deployed in the private space and is not guaranteed. - Secure application properties are stored in encrypted, private vaults and cannot be viewed directly by users or MuleSoft staff after they are created. Secure properties are accessible only by the application itself. You can overwrite the properties to new values at any time. - Use [Anypoint MQ](https://docs.mulesoft.com/mq/) for persistent queues and other queue management. Persistent queues are not supported. - HTTP, HTTPS, and TCP inbound protocols are supported. Inbound protocols that are not TCP or HTTP-based are not supported. - In [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/alerts-hf), you must set alerts for apps individually. Setting alerts for all apps simultaneously is not supported. - CloudHub application workers and CloudHub 2.0 application replicas of the same vCore sizes may differ in performance metrics and cannot be compared. - CloudHub applications have a two-minute grace period. CloudHub 2.0 applications have a five-minute grace period. For more information, see [Grace Period](https://docs.mulesoft.com/cloudhub-2/ch2-deploy#grace-period). CloudHub 2.0 does not support the following application features or functions that CloudHub 1.0 supports: - Mule versions prior to 4.3.0 - Overwriting JVM parameters - Overriding default JVM truststores with custom truststores - Creating custom notifications - Using the CloudHub Connector - TLS 1.0. Use 1.2 or 1.3 instead. ## See Also - [CloudHub 2.0 Features](https://docs.mulesoft.com/cloudhub-2/ch2-features) - [Endpoints](https://docs.mulesoft.com/cloudhub-2/ch2-config-endpoints-paths) - [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about) - [Anypoint Monitoring](https://docs.mulesoft.com/monitoring/) - [Anypoint MQ](https://docs.mulesoft.com/mq/) - [Runtime Manager](https://docs.mulesoft.com/runtime-manager/) --- product: CloudHub 2.0 --- # CloudHub 2.0 High Availability and Disaster Recovery > For the full documentation index, see: https://docs.mulesoft.com/llms.txt CloudHub 2.0 provides high availability (HA) and disaster recovery (DR) for applications and protects against hardware failures. For an overview of HA and DR across all Mule deployment models, and to compare CloudHub 2.0 with other options, see [High Availability and Disaster Recovery Across Deployment Models](https://docs.mulesoft.com/hosting-home/hadr-guide). CloudHub 2.0 runs on Amazon AWS, so its availability depends on Amazon services. CloudHub 2.0 bases deployments and availability on regions that correspond to Amazon regions. If an Amazon region goes down, applications in that region become unavailable, and CloudHub 2.0 doesn’t automatically replicate them to other regions. During a network partition between the control plane and the runtime plane, applications in the runtime plane keep running. The runtime plane buffers log and telemetry data locally until control plane availability returns. ## 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 2.0, you achieve HA by deploying your application with multiple replicas. Disaster recovery (DR) restores a system to an acceptable previous state after a natural or man-made disaster, such as flooding, tornadoes, earthquakes, fires, power failures, server failures, or misconfigurations. Both strategies increase availability but differ in scope: on CloudHub 2.0, HA keeps your application serving requests through replica and availability-zone failures with no loss of service, whereas DR restores service and data after a region-level disruption and usually incurs a brief loss of service while the DR plan runs. Two measurable objectives drive your HA and DR strategies on CloudHub 2.0: 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 2.0 CloudHub 2.0 builds high availability into the platform through mechanisms that MuleSoft manages automatically and that require no additional configuration. Multiple-replica deployment When an application uses multiple replicas, CloudHub 2.0 deploys those replicas across two or more availability zones (AZs) by default. If an AZ fails, CloudHub 2.0 automatically restarts the application in a different AZ to maintain availability. ### CloudHub 2.0 Improvements Over CloudHub CloudHub 2.0 improves on CloudHub in these areas: - Decouples the runtime plane region from the control plane region through a service-oriented architecture. - Supports clustering, which lets you configure HA while running the process on a single primary replica. - Optimizes usage through elastic scaling with Horizontal Pod Autoscaling (HPA) for scaled-down hot standby deployments when not in use and then scaling up when a failover is required. - Manages applications in active/passive mode, which lets you set schedulers and listening connectors—such as Anypoint MQ, Database, FTP, and Salesforce listeners—to a stopped or inactive state. Externalize DR flags and expose REST endpoints to enable and disable flows through a Groovy script as needed. ## Disaster Recovery in CloudHub 2.0 Disaster recovery in CloudHub 2.0 focuses on restoring systems after significant disruptions. MuleSoft manages in-region infrastructure, and you own your cross-region DR strategy. ### Global Distribution You can deploy applications to CloudHub 2.0 in global regions across North America, South America, the European Union, and Asia-Pacific. With the Global Deployment entitlement, and in the US Cloud or EU Cloud, you can deploy applications to more than one runtime plane region. To reduce latency, host integrations in a runtime plane region closer to your services. For the runtime plane regions available for your control plane region, see [Runtime Plane Regions and DNS Records](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#regions-and-dns-records). The runtime plane region is where you deploy your CloudHub 2.0 applications and create CloudHub 2.0 private spaces. ### Regional Infrastructure You can create your private space in a region of your choice. ### Your Responsibility for Disaster Recovery If your organization has cross-region DR requirements, build your applications accordingly and consider deploying them across multiple regions. For applications deployed to different regions, use a cloud-based or on-premises load balancer to switch traffic to your backup region as part of your DR strategy. For more about how to deploy for HA and DR strategies, see [High Availability and Disaster Recovery Across Deployment Models](https://docs.mulesoft.com/hosting-home/hadr-guide). ### Disaster Recovery Use Cases for the Runtime Plane CloudHub 2.0 supports multiple multiregion DR strategies based on application impact. These strategies typically use a bring-your-own (BYO) global load balancer to manage traffic distribution and failover across regions. To decouple your runtime plane application availability from the control plane region, configure your primary and backup runtime plane regions to differ from the region that hosts your Anypoint Platform control plane. This guidance applies to the EU, with the control plane in eu-central-1, and to the US, with the control plane in us-east-1. ![A bring-your-own global load balancer routing traffic across primary and backup CloudHub 2.0 runtime plane regions](/mulesoft/current/en-us/cloudhub-2/_images/hadr-load-balancer.png) #### Active-Active Configuration **When to use:** Choose this configuration for high-impact applications that require continuous availability with minimal downtime. **Application state:** Run applications in different regions simultaneously and fully scaled up. **Traffic management:** - Distribute traffic between both regions with a BYO global load balancer. - Run health checks to detect disasters. - Keep applications running even when the control plane region is unavailable, as long as you deploy them in different regions than the control plane. **Licensing:** - With usage-based pricing (UBP), this configuration distributes [Mule messages and data throughput](https://docs.mulesoft.com/general/usage-metrics) between the two regions and consumes Mule flows based on the number of running replicas per application deployment. - Without UBP, this configuration consumes additional vCores. #### Hot Standby (Active-Passive) Configuration In a hot standby configuration, you install, configure, and fully run your backup environment in the passive region, but it doesn’t process requests until you detect an outage. **When to use:** Choose this configuration for high-impact APIs that can only tolerate brief downtime during failover. **Application state:** - Set up infrastructure across multiple regions, and deploy and run your backup applications in the passive region. - Run the backup applications either fully scaled up or scaled down, with fewer replicas or smaller replica sizes. Scaled-down applications rely on the control plane to redeploy, start, or scale up during an outage. - For scaled-down backup applications, configure CPU-based Horizontal Pod Autoscaling (HPA) where your organization supports it. See [Configuring Horizontal Autoscaling (HPA) for CloudHub 2.0 Deployments](https://docs.mulesoft.com/cloudhub-2/ch2-configure-horizontal-autoscaling). **Traffic management:** - Route traffic to only one region at a time with a BYO global load balancer or DNS routing, such as Amazon Route 53. - Run health checks to determine DR and switch routing. - For non-HTTP use cases such as schedulers, externalize a DR flag in your application and use a Groovy script to enable and disable scheduler flows directly in the runtime plane. Because the backup application is already running, this approach doesn’t rely on the control plane to activate your backup applications. **Licensing:** - With UBP, this configuration consumes no messages or throughput until traffic switches to the backup region, and it consumes fewer flows when you configure [CPU-based HPA](https://docs.mulesoft.com/cloudhub-2/ch2-configure-horizontal-autoscaling). - Without UBP, this configuration consumes additional vCores for the backup deployment. It consumes fewer vCores when the backup deployment stays scaled down before it scales up in response to an outage in the primary region. **Recovery time objective:** A fully scaled backup application has minimal to no downtime, covering only the time to route traffic to the backup region. A scaled-down backup application has an RTO that depends on the time to scale up, either through control-plane-triggered redeployments or through [CPU-based HPA](https://docs.mulesoft.com/cloudhub-2/ch2-configure-horizontal-autoscaling). To let integrating systems resend events or in-flight transaction data, capture recovery points in logs and monitoring systems to improve application reliability. #### Warm Standby Configuration In a warm standby configuration, you fully set up your backup infrastructure in the passive region and deploy your backup applications, but no applications run until you detect an outage. **When to use:** Choose this configuration for medium-impact APIs that can only tolerate brief downtime during failover. **Application state:** - Create and configure your private space, including networking, in the passive region. A running private space is equivalent to a running production system or virtual machine in an on-premises environment. - Configure API Manager for your backup APIs in the passive region. - Deploy your backup applications to the passive region in a stopped state, for example, by setting `false` in your deployment configuration. - Start the applications only when you detect an outage. **Traffic management:** - Route traffic only to the region that is up with a BYO global load balancer or DNS routing, such as Amazon Route 53. - Run health checks to determine DR, and use scripts to start your backup applications and switch traffic routing. - If the control plane is unavailable, you cannot start the backup application in the runtime plane. **Licensing:** The private space and API Manager configuration in the passive region consume your entitlements for the DR region. Because the backup applications stay stopped, this configuration consumes no additional vCores, Mule flows, Mule messages, or data throughput until the backup applications start during a disaster. **Recovery time objective:** Your RTO depends on the time to start applications through the control plane and route traffic to the backup region. #### Cold Standby Configuration In a cold standby configuration, nothing runs in the passive region, and you keep your expense to a minimum. Your cold standby is a plan or script that builds your backup environment in the passive region after you detect an outage. **When to use:** Choose this configuration for low-impact applications that tolerate longer downtime during recovery. **Application state:** - Don’t create a private space or deploy applications or gateways in the passive region before an outage. - Maintain a plan or script that, when you detect an outage: 1. Creates a private space and other infrastructure connectivity, such as VPNs and transit gateway attachments, in the passive region. 2. Deploys and starts your Mule applications and Omni Gateway instances. 3. Deploys your API policies. - Keep the artifacts and configuration that your plan or script uses available outside the primary region, for example, in Exchange and in your source control or CI/CD pipeline. **Traffic management:** - Run health checks to determine DR, run your plan or script to build the backup environment, and switch traffic routing. - If the control plane is unavailable, you cannot create the private space or deploy the backup applications. **Licensing:** Because nothing runs in the passive region, this configuration consumes no private space, vCore, Mule flow, Mule message, or data throughput entitlements for the DR region until you build the backup environment during a disaster. **Recovery time objective:** Your RTO depends on the time your plan or script takes to create the private space and infrastructure connectivity, deploy and start your Mule applications and Omni Gateway instances, and deploy your API policies, plus the time to route traffic to the backup region. This configuration has the longest RTO of the standby options. ### Runtime Plane High Availability and Disaster Recovery Summary High-impact API Use an active-active setup with active replicas in two regions and an external load balancer. High-impact API Use a hot standby setup with fully scaled backup applications running in the secondary region. Use an external load balancer to route traffic, and run health checks to determine DR and switch traffic. Medium-impact API Use a hot standby setup with scaled-down backup applications, or a warm standby setup with backup applications deployed but stopped in the secondary region. Low-impact API Use a cold standby setup, and create the private space and deploy your backup applications in the secondary region only when you detect an outage. ### Disaster Recovery for Regional Services Some MuleSoft services are regional, which shapes their DR strategy. Anypoint MQ This regional service runs in the same region as the application and provides out-of-the-box region failover to a fallback region for standard queues. When your application’s RTO tolerates processing in-flight messages only after the primary site recovers, Anypoint MQ failover suffices. Otherwise, configure a backup application in an active/passive setup and resend in-flight events and data to the failover queue during a traffic switch. During backup with VM queues and Anypoint MQ, you can lose data for a few minutes, depending on your configuration. Object Store v2 This regional service runs in the same region as the application and provides no region failover. An application deployed in a different region cannot access it. Bring your own external storage to access or back up data across regions. Object Store v2 doesn’t retrieve data for regular backups. Caching in the object store, which you use for token management between calls, is region-specific, and you cannot transfer it to a secondary region. ### Disaster Recovery for the Anypoint Platform Control Plane The Anypoint control plane covers additional Anypoint services beyond CloudHub 2.0. For details, see the [DR Test Summary](https://compliance.salesforce.com/en/documents/a005A00000vvLBjQAM). ## Considerations and Limitations ### Considerations for Disaster Recovery Implementations A DR strategy for applications deployed to CloudHub 2.0 requires you to consider several factors. Control plane availability The CloudHub 2.0 management UI and control plane run in the US East region of North America, and also in the EU, Canada, and Japan. See [Control Plane and Runtime Plane Support Matrix](https://docs.mulesoft.com/hosting-home/#control-plane-and-runtime-plane-support-matrix). Caching Use caching in the object store to share tokens among calls. Object stores are region-specific, and you cannot transfer them to a secondary region. Rate-limiting API policies Rate-limiting policies apply at the replica level. When you need rate limiting for in-flight transactions during DR, define custom policies that use an external multiregion shared object store, and include a DR playbook with steps to adjust rate limits during and after DR. Schedulers Many applications run on a schedule to read from databases or files. In this case, schedulers keep running even when the control plane is briefly unavailable. Listeners and watermarks For listeners such as Database Table Row and Salesforce Events, use an external persistent store, such as a database or Redis, across replicas and regions for polling and watermarks. This matters only when connectors use watermarks directly or indirectly. ### Regional Differences for Specific Regions Some control plane regions limit multiregion DR. Control plane to runtime plane ratio Unlike the US (1:12) and EU (1:2) regions, Canada and Japan use a 1:1 control plane region to runtime plane region ratio. ### Cross-Region Disaster Recovery Limitations - Canada and Japan don’t support cross-region runtime plane DR. ## Best Practices - Keep your integrations stateless. - Don’t share transactional information between client invocations or scheduled executions. - If the middleware must retain data because of a system limitation, persist it in an external store, such as a database or a messaging queue, rather than in the middleware infrastructure or memory. - Keep each replica’s state and resources independent so that your applications scale and recover reliably across zones and regions. ## See Also - [High Availability and Disaster Recovery Across Deployment Models](https://docs.mulesoft.com/hosting-home/hadr-guide) - [CloudHub 2.0 Networking Architecture](https://docs.mulesoft.com/cloudhub-2/ch2-networking-guide) - [CloudHub 2.0 Architecture](https://docs.mulesoft.com/cloudhub-2/ch2-architecture) - [CloudHub High Availability and Disaster Recovery](https://docs.mulesoft.com/cloudhub/cloudhub-hadr) - [Usage-Based Pricing: Usage and Rates](https://docs.mulesoft.com/general/usage-metrics) --- product: CloudHub 2.0 --- # CloudHub 2.0 Networking Architecture > For the full documentation index, see: https://docs.mulesoft.com/llms.txt CloudHub 2.0 is MuleSoft’s fully managed, containerized integration platform as a service (iPaaS). Deploy APIs and integrations as lightweight containers in the cloud, ensuring they’re maintainable, secure, and scalable. This document provides relevant information regarding the configuration and administration of CloudHub 2.0 networks, network interfaces, and network services. For information about different deployment scenarios, see [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies). The basic components of the CloudHub 2.0 networking architecture are an HTTP load balancer, Mule replica DNS records, private spaces, and regional services. - [HTTP Load Balancer](#http-load-balancer) - [DNS Records](#dns-records) - [Private Spaces Configurations](#private-spaces-configurations) - [Regional Services](#regional-services) ![Basic Components of CloudHub 2.0 Networking Architecture in a Private Space](/mulesoft/current/en-us/cloudhub-2/_images/ch2-networking-architecture-ps-diagram.png) ![Basic Components of CloudHub 2.0 Networking Architecture in a Shared Space](/mulesoft/current/en-us/cloudhub-2/_images/ch2-networking-architecture-shs-diagram.png) ## HTTP Load Balancer CloudHub 2.0 provides a load-balancing service for all integrations. You can use a default endpoint or provision a custom endpoint with your own certificate. When you deploy an application to two or more replicas, CloudHub 2.0 provides an HTTP load-balancing service that automatically distributes HTTP requests among your assigned replicas. The CloudHub 2.0 load-balancing service performs a round-robin load distribution across application replicas, which provides horizontal scalability. The load-balancing service also provides transparent switchover when an application is upgraded. See [Updating Apps Deployed to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps). Each application deployed to CloudHub 2.0 has both default public and internal DNS records that refer to the load balancer: `...cloudhub.io.` and `.internal-..cloudhub.io.`. The CloudHub 2.0 private spaces load-balancing service accepts public traffic on the standard HTTPS port: `443`. For private spaces, you can also accept HTTP traffic on the standard HTTP port: `80`. Shared spaces don’t accept port `80`. ### Mule Application Ports Applications must listen on host `0.0.0.0` and port via the reserved property `${http.port}`. MuleSoft allocates the value of this property. The load-balancing service forwards traffic to deployed applications. ### Upstream HTTPS Traffic By default, the load-balancing service forwards traffic to deployed applications over HTTP. To use HTTPS: - Enable the **Last-Mile Security** setting in the **Ingress** tab of the [deployment settings](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space#configure-endpoint-path). - Configure the application to listen on HTTPS by providing a certificate in the TLS context of your private space. The following example shows a Mule application configuration that exposes an HTTPS endpoint: ```console ``` ### Load Balancer Connections For each request a client makes through the CloudHub 2.0 load balancer `(...cloudhub.io)`, the load balancer maintains two connections: one connection between the client and the load balancer, and another connection between the load balancer and the application. For each connection, the load balancer manages a default idle timeout of 15 seconds that is triggered when no data is sent over either connection. If no data is sent or received during this duration, the load balancer closes both connections. For connections that take longer than 300 seconds to process from either side, handle the processing asynchronously. You can customize the Read Response Timeout value in the **Advanced** tab of your [private space settings](https://docs.mulesoft.com/cloudhub-2/ps-config-advanced#configure-http-requests-and-read-response-timeout) in Runtime Manager, or via the Mule application [global configurations](https://docs.mulesoft.com/mule-runtime/latest/global-settings-configuration) of the [Mule configuration file](https://docs.mulesoft.com/mule-runtime/latest/about-mule-configuration). ## DNS Records The following DNS records are exposed for your CloudHub 2.0 applications:

*.<space-id>.<region>.cloudhub.io

Applications running inside a private space.

<space-id>.<region>.cloudhub.io

Record pointing to the load balancer. Use this record as the target of a custom domain CNAME.

*.internal-<space-id>.<region>.cloudhub.io

Applications running inside a private space. The IP addresses for this DNS record are accessible only within your private spaces. They cannot be accessed within shared spaces.

internal-<space-id>.<region>.cloudhub.io

Internal load balancer. Use this record as the target of a custom domain CNAME. The IP addresses for this DNS record are accessible only within your private spaces. They cannot be accessed within shared spaces.

## Private Spaces Configurations The following configurations apply to private spaces only. ### Application-to-Application Communication An application communicates with another application via: - The default public DNS name: `app.sxjsip.aus-s1.cloudhub.io` - The default internal DNS name (in private spaces only): `app.internal-sxjsip.aus-s1.cloudhub.io` - The custom domain name (if configured): `acme.example.com` If you use the internal DNS name, traffic remains within the private space network. You can delete or omit the externally exposed endpoint when deploying an application to a private space. In that case, use the application’s internal endpoint for internal traffic. If you use the private space’s local endpoint, traffic doesn’t leave the private space. However, the private space’s local endpoint isn’t highly available. The endpoint can be unreachable during some private space operations, such as disaster recovery. The private space’s local endpoint allows traffic within the same environment only. ### Custom Domain Name You can apply custom certificates to your private space. CloudHub 2.0 parses the CN and SAN lists from the certificate and makes those domains available when deploying applications. Configure either in the public or the internal DNS record to CNAME. For example: \*.example.com => sxjsip.aus-s1.cloudhub.io \*.example.com => internal-sxjsip.aus-s1.cloudhub.io ### IP Ranges Traffic egressing to the internet originates from an IP address listed under the **Outbound Static IPs** field of the private network configuration. These outbound static IPs don’t change during the lifetime of the private space. The public DNS target and the private DNS target IPs also don’t change during the lifetime of the private space. The private DNS target uses private static IP addresses. These IP addresses remain constant throughout the lifetime of the private space. This makes them suitable for use in internal DNS configurations or allowlists in your connected external networks. You can view the public DNS target IP addresses in the **Inbound IP Addresses** section of the private space network configuration. Traffic egressing to a VPN or Transit Gateway (TGW) originates from the private space CIDR block. ![Inbound and outbound IPs listed in the UI](/mulesoft/current/en-us/cloudhub-2/_images/ch2-networking-ip-ranges.png) Private spaces also use several secondary CIDR for internally. If you use BGP routing protocols, you can publish these CIDR blocks to your gateway: 100.64.0.0/16 100.66.0.0/16 100.67.0.0/16 100.68.0.0/16 Because of this, `100.64.0.0/10` is [not a supported range](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#unusable-cidr) for private spaces. You can filter these prefixes from the route map. You can also indicate a reserved range for your on-prem network upon creating your private space. CloudHub 2.0 doesn’t use reserved ranges indicated by customers. For more information, see [Reserved Corporate CIDR](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#reserved-cidr). ### Connections Private spaces support two types of connections: Virtual Private Network (VPN) and Transit Gateway (TGW). Each Anypoint VPN connection consists of two tunnels that enable you to connect to a single public IP address at a remote location. VPNs are highly available if you configure both tunnels on your endpoint. Additionally, you can define redundant VPN connections for increased resiliency. As a managed service, the underlying VPN service is often upgraded. Routine maintenance can briefly disable one of the two tunnels of your VPN connection. Your VPN connection automatically fails over to the second tunnel during this time, so access isn’t interrupted. For this reason, you must configure both tunnels on your endpoint. By design, TGW connections are highly available. Don’t create redundant TGW connections. For more information, see [Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub-2/ps-tgw-about). CloudHub VPC AWS direct connect connections are deprecated in CloudHub 2.0. Instead, use TGW attachments. If you delete a private space with an attached TGW, the transit gateway is saved, and you can reattach it to a different private space. #### Connections Between CloudHub and CloudHub 2.0 Use a [TGW attachment](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-tgw) to connect a dedicated VPC in CloudHub to a CloudHub 2.0 private space. You must apply the attachments independently in CloudHub and CloudHub 2.0. ### Firewall Rules and Port Access > [!NOTE] CloudHub 2.0 private spaces provide configurable inbound and outbound firewall rules, with > ports `80` and `443` open by default. Private spaces don’t include a built-in Web Application > Firewall (WAF) or Layer 7 DDoS protection. If you need these protections, implement them > externally. HTTP Ingress By default, ports `443` and `80` are exposed for all external inbound traffic. You can remove or change these ports to restrict inbound traffic. Non-HTTP Ingress By default, no non-http ports are open. You can open a fixed list of TCP ports (30500-32500) to allow non-http traffic to flow to your Mule applications. Those ports are only reachable from within the private space or originated from a VPN or a TGW. For more information about how to allow TCP traffic for your private space, see [Deploy an App with TCP using the Application Manager API](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-api). Egress By default, applications can make outbound connections to any destination and port. You can change this behavior to restrict egress traffic. You can remove all ingress and egress rules from and to the internet. In this case, the private space still functions normally because of these control measures: - Anypoint Monitoring ingestion traffic firewall rules are implicitly added to all Mule applications’ firewall rules. - Essential AWS services traffic flows are always allowed from Mule applications. - You can apply egress rules at the application level. For more information, see [Configuring Application-Level Egress Rules](https://docs.mulesoft.com/cloudhub-2/ps-config-app-level-egress). - You can remove the default route to the Internet Gateway. However, for the egress firewall rules to work, the destination IPs must be routable. ### Test Private Space Connectivity To test connectivity to applications in a private space, use the **Network Tools** application. ICMP ping isn’t a supported connectivity test, so a failed ping doesn’t mean that your application is down. For download and usage information, see [How To Use Network Tools Application](https://help.salesforce.com/s/articleView?id=001115029&type=1). If traffic reaches the firewall but gets no response, check these common causes: - A port restriction. The internal load balancer accepts traffic on port `443`. - A pod-network CIDR that isn’t allowlisted in your connected network. ## Regional Services The DNS record and the load balancer for your integration can change depending on the region you deploy your applications in. For the runtime regions available for each control plane, including the **Region** token used in DNS records, see [Runtime Plane Regions and DNS Records](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#regions-and-dns-records). > [!NOTE] URL formats vary by control plane: > > US Cloud Control Plane > > URLs don’t include a region suffix before `cloudhub.io`. > Example: `myapp.usa-e1.cloudhub.io` > > Non-US Control Planes > > URLs include a region suffix (such as `eu1`, `ca1`, `jp1`, or `in1`) before `cloudhub.io`. > Examples: `myapp.irl-e1.eu1.cloudhub.io`, `myapp.can-c1.ca1.cloudhub.io`, > `myapp.jpn-e1.jp1.cloudhub.io`, `myapp.ind-w1.in1.cloudhub.io` ## See Also - [Runtime Plane Regions and DNS Records](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#regions-and-dns-records) - [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about) - [Configure SSL Endpoints and Certificates](https://docs.mulesoft.com/cloudhub-2/ps-config-ssl-endpoints) --- product: CloudHub 2.0 --- # CloudHub 2.0 Operating System Patch Updates > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Because CloudHub 2.0 is an integration platform as a service (iPaaS), it manages operating system patching for you, enabling you to focus on developing and updating your applications. CloudHub 2.0 applies security patches as needed to ensure that your application is secure. Patch updates use blue-green deployment for applications that use the Rolling Update deployment model, which ensures zero downtime for applications that support it. CloudHub 2.0 applies continuous updates to two MuleSoft-managed deployment platforms: - US cloud - EU cloud ## CloudHub 2.0 Infrastructure Updates As a container-based platform, CloudHub 2.0 applies infrastructure fixes and security patches as needed to ensure the infrastructure is secure and up-to-date. Patch updates use rolling upgrade deployment (when selected as the deployment model) and can include operating system changes or changes to internal software. An update rotates, drains, and replaces the underlying hosts gradually to ensure zero downtime when using the Rolling Update deployment model. During the upgrade, the Mule application might be restarted onto a new secure host. If the Mule worker is not running with multiple replicas or is using the Recreate deployment model, it experiences slight downtime. When an update is available, CloudHub 2.0 includes it in Production environments as the default for new private spaces. The existing infrastructure patching schedule occurs in the same maintenance window as [CloudHub 2.0 Runtime patches](https://docs.mulesoft.com/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes). Infrastructure and runtime updates might cause your applications to restart. [Anypoint VPNs](https://docs.mulesoft.com/cloudhub/vpn-maintenance) used in CloudHub 2.0 are upgraded continuously. Whenever a new update is available, the VPN is patched within the service-level agreement. If the Anypoint VPN is not set up as high availability or if the non-high-availability VPN is not set up with two tunnels, downtime is expected. ### Clustered Replicas and Rolling Updates When running Mule in a [cluster](https://docs.mulesoft.com/cloudhub-2/ch2-clustering), a rolling update with a Mule runtime version that has a Hazelcast version change can result in multiple members of the cluster with different Hazelcast versions. This might cause application failure, with a Hazelcast serialization error, if the different Hazelcast versions are incompatible. To prevent this kind of error, use the Recreate update strategy. ## Schedule Infrastructure Upgrades (Optional) Schedule infrastructure upgrades earlier than the scheduled patching process, between the Release Available date and the start of the Sandbox Environment Auto-Update window in the [monthly updates table](https://docs.mulesoft.com/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes). This way, you can choose a date in the future that better suits your organization’s needs. After the Sandbox Environment Auto-Update window starts, you can’t schedule infrastructure upgrades for sandbox or production private spaces. You can still apply an immediate upgrade. See [Opt-in Early Infrastructure Upgrades (Optional)](#opt-in-early-infrastructure-upgrades). The upgrade process includes an infrastructure-triggered restart of your application replicas. Because CloudHub 2.0 provides a grace period of up to 12 hours for infrastructure-triggered restarts, the complete upgrade can take up to 12 hours. See [Shutdown Timeout Behavior](https://docs.mulesoft.com/cloudhub-2/ch2-understand-app-restart#shutdown-timeout-behavior). The impact of the upgrade process on running applications is consistent with the auto-patching behavior described in the previous sections. You can modify or delete your scheduled upgrade if it isn’t already in progress, as indicated by the `Queued` status. If you cancel the schedule and don’t create another or opt in to an earlier upgrade, the upgrade occurs during the mandatory patching window. ### Schedule the Upgrade via Runtime Manager 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. If an upgrade is available for a private space, the **Upgrade Available** status appears under the **Infra Status** column. 2. Click **Schedule an Upgrade**. 3. Select the date on which you want your private space to upgrade. Upgrades occur at 00:00 in your local timezone on the date you select. 4. Select the checkbox to confirm that you agree to upgrade early. 5. Click **Upgrade**. After applying the upgrade, you can check the status under the **Infra Status** column. ## Opt-in Early Infrastructure Upgrades (Optional) Opt in to apply an infrastructure upgrade immediately, earlier than the scheduled patching process. You can opt in between the Release Available date and the mandatory Auto-Update for that private space, as stated in the [monthly updates table](https://docs.mulesoft.com/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes). This way, you can choose the time that better suits your organization’s needs. After the Sandbox Environment Auto-Update window starts, you can’t schedule an upgrade for sandbox or production private spaces, but you can still select **Upgrade now** to apply an immediate upgrade. The upgrade process includes an infrastructure-triggered restart of your application replicas. Because CloudHub 2.0 provides a grace period of up to 12 hours for infrastructure-triggered restarts, the complete upgrade can take up to 12 hours. See [Shutdown Timeout Behavior](https://docs.mulesoft.com/cloudhub-2/ch2-understand-app-restart#shutdown-timeout-behavior). The impact of the upgrade process on running applications is consistent with the auto-patching behavior described in the previous sections. > [!NOTE] This upgrade is irreversible. Ensure that you understand the impact of the upgrade and > choose when to trigger the upgrade based on your organization’s needs before applying it in a > production environment. ### Apply the Opt-in Upgrade via Runtime Manager 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. If an upgrade is available for a private space, the **Upgrade Available** status appears under the **Infra Status** column. 2. Click **Upgrade available**. 3. Click **Upgrade now** and opt in to the early upgrade. 4. Click **Upgrade**. After applying the upgrade, you can check the status under the **Infra Status** column. ### Schedule or Apply the Upgrade via API You can upgrade a private space using the Upgrade Private Space API. For more information, see the [Upgrade Private Space API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/minor/1.0/console/endpoint/%232428/) documentation in Exchange. ## Monthly Date-Patch Updates In the first full week of each 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 monthly patches update applications only to the latest date patch for the patch version. They do not change the patch version number. The format of the version number for these updates to 4.3.x or 4.4.x versions is: _Major_._Minor_._Patch_ : _Date_ Here’s an example version number, including the patch date: `4.4.0:20211015` 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 - 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 during the first week of the month. - Applications in environments other than production are updated during the week. - Production applications are updated on the weekend. When an automatic update occurs, the audit log for your application adds 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. If your application does not support zero-downtime updates or requires a manual update, you can manually 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). ## 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.
Channel TypeRelease CadenceDifferentiatorsSupport Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • 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.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support

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 2.0:
Mule VersionRelease DateJava VersionEnd of Standard SupportEnd of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024

> [!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.
ActionCloudHub 2.0

Deploy net new apps

Deploy to the latest minor-patch version available under Standard Support of each channel.

Auto-upgrade

MuleSoft applies two distinct types of automatic updates:

  • 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 4.9.19 to 4.9.20. 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 CloudHub and CloudHub 2.0.

  • 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:

    • 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.

    • 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.

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.

Self-upgrade

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 CloudHub and CloudHub 2.0.

  • Edge: Six weeks

  • LTS: Manual upgrade only (no automatic minor upgrade schedule)

Rollback

Available to the previously used version

Restart apps

Always

Keep running applications

Until End of Extended Support

End of Extended Support

Shutdown running apps.
Starting with Mule 4.7, CloudHub and CloudHub 2.0 applications in the Edge or LTS channels that are still running End of Life versions will undergo a forced upgrade to the latest version during the monthly upgrade window (See upgrade window for CloudHub and CloudHub 2.0).

Retirement

Mule apps don’t reach End of Life because they’re always auto-upgraded.

Supportability

All Mule apps are under Standard Support.

## 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 2.0 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 2.0 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:
Hybrid StandaloneCloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)

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 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: ![ch2 update available column](/mulesoft/current/en-us/cloudhub-2/_images/ch2-update-available-column.png) - **Update available** and the new available updates appear in the **Deployment Target** tab of the **Settings** page for the application: ![ch2 update available field](/mulesoft/current/en-us/cloudhub-2/_images/ch2-update-available-field.png) MuleSoft applies the updates automatically, based on the published schedules. If you want, you can update them manually at your convenience. ## Update the Runtime Version Manually 1. Log in to Anypoint Platform. 2. Navigate to Runtime Manager. 3. In the Runtime Manager navigation menu, click **Applications** 4. Select the application you want to update. 5. In **Settings**, in the **Deployment Target** tab, click the **Runtime Version** drop-down. 6. Select the latest build for your version. 7. Click **Deploy**. The application redeploys with the new runtime version. 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-2/_images/ch2-app-edge-auto-update.png) ## Possible Status Types for Private Space Upgrades and Updates The **Infra Status** column in the **Private Space** page shows the status of infrastructure upgrades for your private space.
StatusDescription

Latest

The private space is running the latest available infrastructure version. It is currently not undergoing an infrastructure upgrade or configuration update.

Upgrade Available

An upgrade is available for the private space. You can either initiate an upgrade immediately or schedule a time for the upgrade to begin.

Upgrade Scheduled

The private space has an upgrade scheduled for a future date.

Queued

The upgrade that was scheduled or initiated is about to begin. You can no longer make changes to the schedule or interrupt the upgrade.

Upgrading

The private space is undergoing an infrastructure upgrade, either scheduled, self-triggered, or as part of a monthly infrastructure upgrade.

Updating

The private space is undergoing an update that was triggered by a configuration change.

Failed

The private space experienced a failure which can be related to a user configuration update, or to an infrastructure upgrade, either scheduled, self-triggered, or as part of a monthly infrastructure upgrade.

Degraded

The private space is in degraded state.

 — 

Unable to get the details of the private space status and the status is unknown.

## Security Updates MuleSoft regularly runs scans to identify security vulnerabilities in JVM and the underlying operating system, and then automatically applies security patches based on the following SLA:
Severity LevelSeverity DefinitionPatch Applied Within

P0

Critical

7 days

P1

High

30 days

## Check Your Application Status After an Update After a new update occurs, you can check your [applications status state](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps#replica-statuses) 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 [Viewing Log Data for Deployed Apps](https://docs.mulesoft.com/cloudhub-2/ch2-view-logs). ## See Also - [Edge and LTS Releases for Mule](https://docs.mulesoft.com/release-notes/mule-runtime/lts-edge-release-cadence). --- product: CloudHub 2.0 --- # CloudHub 2.0 Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt CloudHub 2.0 is a fully managed, containerized integration platform as a service (iPaaS) where you can deploy APIs and integrations as lightweight containers in the cloud. ## Why Deploy on CloudHub 2.0? CloudHub 2.0: - Supports deployments across all MuleSoft regions. - Dynamically scales infrastructure and built-in services up or down to support elastic transaction volumes. - Builds in security policies, protecting your services and sensitive data with encrypted secrets, firewall controls, and restricted shell access. - Encrypts certificates, passwords, and other sensitive configuration data at rest and in transit within Anypoint Platform. - Provides a standardized isolation boundary by running each Mule instance and service as a separate container. For CloudHub 2.0 pricing information, contact either your account executive or your account development representative. ## CloudHub 2.0 Features by Control Plane All CloudHub 2.0 features are supported across all control planes, with a few exceptions that vary by deployment region: - Deleting the default egress traffic route (0.0.0.0) can cause Anypoint Monitoring to fail in CloudHub 2.0. - The endpoint URL format requires the region suffix or not before `cloudhub.io`. - India Cloud uses a different Ingress controller. It maintains feature parity, but has some behavioral differences. Read this [knowledge article](https://help.salesforce.com/s/articleView?id=005387259&type=1).
CloudHub 2.0 FeaturesUS CloudEU CloudCanada CloudJapan CloudIndia Cloud

Deleting the Default Route

Available

Available

Not Available

Not Available

Not Available

Endpoints URL Format

No region suffix: https://*.10u6w7.usa-e1.cloudhub.io

Needs region suffix: https://*.10u6w7.usa-e1.eu1.cloudhub.io

Needs region suffix: https://*.10u6w7.can-c1.ca1.cloudhub.io

Needs region suffix: https://*.10u6w7.jpn-e1.jp1.cloudhub.io

Needs region suffix: https://*.10u6w7.ind-w1.in1.cloudhub.io

> [!NOTE] URL formats vary by control plane: > > US Cloud Control Plane > > URLs don’t include a region suffix before `cloudhub.io`. > Example: `myapp.usa-e1.cloudhub.io` > > Non-US Control Planes > > URLs include a region suffix (such as `eu1`, `ca1`, `jp1`, or `in1`) before `cloudhub.io`. > Examples: `myapp.irl-e1.eu1.cloudhub.io`, `myapp.can-c1.ca1.cloudhub.io`, > `myapp.jpn-e1.jp1.cloudhub.io`, `myapp.ind-w1.in1.cloudhub.io` ## See Also - [Features of CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-features) - [Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure) - [Private Network Region](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#private-network-region) --- product: CloudHub 2.0 --- # CloudHub 2.0 Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - [CloudHub 2.0 Feature Release Notes](https://docs.mulesoft.com/release-notes/cloudhub-2/cloudhub-2-release-notes) - [CloudHub 2.0 Runtime Release Notes](https://docs.mulesoft.com/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes) - [Anypoint VPN Updates Release Notes](https://docs.mulesoft.com/release-notes/cloudhub/anypoint-vpn-release-notes) ## See Also - [CloudHub 2.0 Documentation](https://docs.mulesoft.com/cloudhub-2/) - [Known Issues](https://help.salesforce.com/s/issues) --- product: CloudHub 2.0 --- # Clustering > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Clustering provides scalability, workload distribution, and added reliability to your applications on CloudHub 2.0. This functionality is powered by CloudHub’s scalable load-balancing service and replica scale-out. You can enable clustering features on a per-application basis using the Anypoint Runtime Manager console when either deploying a new application or redeploying an existing application. ## High Availability and Clustering _High availability_ refers to having multiple replicas that, unlike clustering, do not share data between each replica. _Clustering_ enables multiple replicas to communicate with each other and share data because they share memory. ### CloudHub 2.0 Clustering and Object Store v2 CloudHub 2.0 supports clustering using Mule in addition to Object Store v2 for Mule 4 apps. When you enable Object Store v2 in CloudHub 2.0, note that it is rate limited. For more information, see [Object Store v2 Overview](https://docs.mulesoft.com/object-store/). > [!IMPORTANT] CloudHub 2.0 clears local disk storage when an app restarts or redeploys. Because > `persistent="true"` writes to local disk, CloudHub 2.0 doesn’t preserve data across restarts. > > In Anypoint Studio and standalone Mule runtimes, object stores retain data across restarts because > the local file system persists. CloudHub 2.0 replicas use volatile disk storage. > > To persist data across restarts, use [Object Store v2](https://docs.mulesoft.com/object-store/) to store data externally. > [!NOTE] If you enable both **Clustering** and **Use Object Store V2** on CloudHub 2.0, all Object > Store access routes to Cloud Object Store v2, including internal runtime, policy, and connector > usage. This can result in metered, billable usage even if your application doesn’t explicitly use > Object Store. You don’t configure apps to use Object Store in CloudHub 2.0. Mule 4 apps support Object Store v2, which you enable in Anypoint Runtime Manager. ## Before You Begin Clustering requires: - The Anypoint Integration Advanced package or a Platinum or Titanium subscription to Anypoint Platform - A CloudHub Enterprise or Partner account type that enables you to use this feature. - Familiarity with deploying applications using Runtime Manager. ## Replica Scale-out CloudHub 2.0 enables you to select vCore options for 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. You can deploy your application with up to 8 replicas, or you can deploy with up to 16 replicas if you have the Anypoint Integration Advanced package or a Platinum or Titanium subscription to Anypoint Platform. To ensure that you have sufficient resources, see [CloudHub 2.0 Replicas](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#cloudhub-2-replicas). Replica scale-out also adds additional reliability. Mule runtime engine (Mule) automatically distributes multiple replicas for the same application across two or more data centers for maximum reliability. When deploying your application to two or more replicas, you can distribute workloads across these instances of Mule. CloudHub provides the following an HTTP load balancing service that automatically distributes HTTP requests among your assigned replicas. Batch jobs only run on a single replica at a time, and cannot be distributed across multiple replicas. If Mule restarts in the same deployment, the status persists and the batch continues processing. If the entire application is updated or redeploying while the batch is running, the rest of the batch job doesn’t continue. The main solution for persistent batch jobs in CloudHub 2.0 is to use [Object Store v2 Overview](https://docs.mulesoft.com/object-store/). In Kubernetes, a Horizontal Pod Autoscaler (HPA) automatically updates a workload resource to scale the workload to match demand. Horizontal scaling automatically deploys more pods as a response to an increased load. As a result of these regular autoscaling operations, an application can be changed to a new replica without user action. ## Enable Clustering Features You can enable and disable either or both of cluster mode and horizontal autoscaling in one of two ways: - When you deploy an application to CloudHub 2.0 for the first time using Runtime Manager: - Use the **Replica Count** and **Replica Size** drop-down menus on the **Runtime** tab to select the vCore options and configure the computing power you need. - Check the **Run in Runtime Cluster Mode** in the **Runtime Options** section to enable Mule clustering across each replica of the application. This option requires at least two replicas. - For previously deployed applications, use the **Replica Count** and **Replica Size** drop-down menus on the **Deployment Target** tab. - Check the **Run in Runtime Cluster Mode** in the **Runtime Options** section to enable Mule clustering across each replica of the application. This option requires at least two replicas. See [CloudHub 2.0 Replicas](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#cloudhub-2-replicas) for more information about deploying to multiple replicas. If your application is already deployed, you must redeploy it for your new settings to take effect. ## How High Availability is Implemented HTTP load balancing is implemented by an internal reverse proxy server. Requests to the application (domain) URL are automatically load balanced between all the application’s replica URLs. ## How Clustering is Implemented When you enable clustering, all the replicas of a Mule application act as a unit. A cluster is a virtual server composed of multiple replicas. The nodes in a cluster communicate and share information through a distributed shared memory grid. Thus, data is replicated across memory in different replicas. For more information, see [On-Premises Mule Runtime High Availability Cluster Overview](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters). ## Use Cases You can combine clustering features in a single application.
Use CaseSuggested Clustering ConfigurationImplications

You want to scale out your application, but you are satisfied with the existing highly available CloudHub 2.0 architecture in terms of preventing service interruption or message loss. You agree with having the mule schedules executed multiple times simultaneously. Ideally, the schedule flows are idempotent to avoid any conflicts.

Number of Replicas: Two or more
Clustering not enabled

  • Application performance isn’t affected by message queue latency.

  • No need to configure your application to support Anypoint MQ.

  • Application schedules are executed on all replicas independently.

  • Object Stores are not shared between replicas.

  • If the object is written to one replica, the other replicas won’t see the object, unless Cloud Object Store is used.

  • If one data center experiences an outage, your replicas are available in a different data center.

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.

Number of Replicas: One
Clustering not enabled

  • The application can experience some message queue latency.

  • Configure your application to support Anypoint MQ before deploying.

  • Application schedules are executed once on a single replica.

  • Application schedule execution can be missed if the application runtime is not available at the time of execution.

  • If the data center in which your replica operates experiences an outage, CloudHub 2.0 automatically migrates your application to another availability zone. You can experience downtime during the migration; however, your message queues ensure zero message loss.

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.

Number of Replicas: Two or more
Clustering enabled

  • The application can experience some message queue latency.

  • Configure your application to support Anypoint MQ before deploying.

  • Application schedules are executed only once on the primary replica.

  • Application schedules can be missed during the lead election.

  • Object Stores are replicated and shared with each replica.

  • All replicas can read objects written by another replica, with or without Cloud Object Store.

  • If one data center experiences an outage, your replicas are automatically distributed to ensure redundancy.

You have an application that does not have any special requirements regarding either processing load or message loss.

Number of Replicas: One
Clustering not enabled

  • Application performance isn’t affected by message queue latency.

  • You don’t need to configure your application to support Anypoint MQ.

  • Application schedules are executed once on a single replica.

  • If the data center in which your replica operates experiences an outage, CloudHub 2.0 automatically migrates your application to another availability zone; however, you can experience some downtime and message loss during the migration.

## See Also - [CloudHub 2.0 Architecture](https://docs.mulesoft.com/cloudhub-2/ch2-architecture) - [Object Store v2 Overview](https://docs.mulesoft.com/object-store/) --- product: CloudHub 2.0 --- # Configure SSL Endpoints and Certificates > For the full documentation index, see: https://docs.mulesoft.com/llms.txt While you do not have to manage load balancers manually in CloudHub 2.0, each private space 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. ## Before You Begin To associate an SSL endpoint, you must provide: - An encrypted, PEM-encoded (Privacy-Enhanced Mail) certificate file. - A second file containing the private key of your PEM certificate. ## Create a Certificate File and Private Key with the openssl Command You can create both an encrypted, 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 -keyout example-com-private-key.pem -x509 -days 3000 -out example-com-crt.pem -passout pass:examplePassword 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 encrypted, PEM-encoded file. Ordering is not important for independent CA certificates, but certificates in a chain of trust must be concatenated. --- product: CloudHub 2.0 --- # Configuring Advanced Private Space Settings > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use options on the **Advanced** tab to: - Configure how the ingress load balancer handles HTTP requests. - Specify the read-response timeout. This value is the amount of time the CloudHub 2.0 ingress controller waits to receive a response from your Mule application after forwarding the request. If your application takes longer than the configured time to process the request and start sending the response, CloudHub 2.0 drops the connection with a 504 error. > [!IMPORTANT] This timeout setting is separate from the read-request timeout, which controls how > long the CloudHub 2.0 ingress controller waits to receive the full request from the client. The > read-request timeout is hardcoded to 300 seconds and isn’t configurable. If your client takes > longer than 300 seconds to send the complete request, for example, when uploading large files, > CloudHub 2.0 drops the connection even if you configure a longer read-response timeout. > > For data transfers that exceed 300 seconds, consider breaking the request into smaller chunks or > implementing asynchronous processing patterns. - Configure ingress load balancer logs levels and download logs. - Configure Amazon Web Services (AWS) service roles. ## Configure HTTP Requests and Read-Response Timeout When you modify HTTP requests, applications may not be reachable for up to 5 seconds. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Advanced** tab. 4. Configure how the private accepts inbound traffic: CloudHub 2.0 doesn’t allow you to accept only insecure HTTP requests. From the **HTTP Requests** list, select one of the following: - **Redirect to HTTPS** Redirects HTTP requests to the same URL using the HTTPS protocol. - **Accept HTTP** Accepts the inbound request on the default SSL endpoint using the HTTP protocol. - **Drop HTTP** Silently drops HTTP requests. 5. Specify the read response timeout value. The default read-response timeout is 300 seconds. You can configure this value up to 3600 seconds (1 hour). 6. Click **Save Changes** or **Discard Changes**. > [!NOTE] The maximum request size is 1 GB. ## Understanding Timeout Behavior CloudHub 2.0 uses multiple timeout settings to manage different phases of request handling: Read Request Timeout (hardcoded at 300 seconds) The time the CloudHub 2.0 ingress controller waits to receive the complete request from the client. If the client takes longer than 300 seconds to send the entire request payload (for example, uploading a large CSV file), CloudHub 2.0 drops the connection. This timeout is not user-configurable and applies to both shared and private spaces. Read Response Timeout (user-configurable) The time the CloudHub 2.0 ingress controller waits to receive a response from your Mule application after the request has been forwarded. Configure this timeout in the **Advanced** tab of your private space settings. This setting controls how long your Mule application takes to process the request and begin sending a response. Connection Idle Timeout (hardcoded at 15 seconds) The time the CloudHub 2.0 ingress controller waits before closing an idle connection when no data is being transferred. For long-running operations that exceed these timeout limits, consider implementing one of the following approaches: - Break large requests into smaller chunks - Use asynchronous processing patterns where the client receives an immediate acknowledgment and polls for results - Implement keep-alive mechanisms to prevent idle timeout during processing ## Configure Default Ingress Load Balancer Log Levels CloudHub 2.0 enables you to specify the default severity level of messages that are written to the log file for all apps deployed to the private space. > [!IMPORTANT] More verbose log levels affect performance. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Advanced** tab. 4. Select the default [log level](#ingress-load-balancer-log-levels) from the drop-down list. 5. Click **Save Changes** or **Discard Changes**. ## Configure Custom Ingress Load Balancer Log Levels CloudHub 2.0 enables you to specify the default severity level of messages that are written to the log file for specific IP addresses, for example, for troubleshooting. > [!IMPORTANT] More verbose log levels affect performance. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Advanced** tab. 4. Configure custom log levels: 1. Enter the IP address and select the [log level](#ingress-load-balancer-log-levels) from the drop-down list. 2. Click **Add IP Address** to enter additional custom log levels. 3. To remove a custom log level, click the trash can icon (**Delete**) for the entry. 5. Click **Save Changes** or **Discard changes**. ## Ingress Load Balancer Log Levels The default log level for IP address filtering is `DEBUG`.
Table 1. Ingress Load Balancer Log Levels
LevelDescription

Error (Recommended)

Only error messages, such as when an exception occurs

Debug

Debugging messages

Trace

Tracks application metadata such as path, headers, state, and timeline between Ingress and APIs to facilitate collaboration

Info

Informative messages

### Download Ingress Load Balancer Logs To download ingress load balancer logs: 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Advanced** tab. 4. Click **Download Logs**. ## Configure AWS Service Role If you have identity and access management (IAM) roles configured in AWS, associate the role with your private space. The private space receives the permissions from the IAM role in AWS and accesses AWS resources. To configure this feature in AWS: - Use the unique AWS IAM role name that Anypoint Platform generates. - Use the organization ID for the organization in which the private space was configured. - Allow outbound traffic on port 443 to use this feature. For more information, see [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html). 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Advanced** tab. 4. Click **Enable AWS Service Role**. 5. Click **Save Changes** or **Discard changes**. A unique service role name is generated. Use this role to configure identity and access management for AWS. Role generation takes a few minutes. If the role name doesn’t appear, refresh the page. > [!NOTE] Each private space supports only one AWS service role. ### IAM Roles and AWS S3 Connector: STS Endpoint Behavior When you enable the AWS service role for a private space, the cluster injects environment variables such as `AWS_STS_REGIONAL_ENDPOINTS=regional`. The AWS SDK credential provider that this setup uses ignores custom STS endpoint settings in your Mule application and always uses the public regional STS endpoint, such as `sts.{region}.amazonaws.com`. > [!IMPORTANT] If your private-space firewall doesn’t allow outbound traffic to that STS endpoint, > connectivity tests for the AWS S3 Connector and other AWS SDK-based connectors fail, and > applications stop responding. Allow outbound HTTPS on port 443 to the regional STS endpoint for > the region where your private space runs. Configure this outbound access in > [Configuring Firewall Rules to Manage Traffic to and from a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules). > > Don’t use application-level egress rules for the STS domain. Those rules don’t support this > endpoint and can cause intermittent connection failures. See > [ps-config-app-level-egress.adoc#limitations](https://docs.mulesoft.com/cloudhub-2/ps-config-app-level-egress#limitations). If you can’t open outbound access to the public regional STS endpoint, set the AWS\_ENDPOINT\_URL environment variable for your application to the STS endpoint URL so that the SDK uses that URL instead. To apply this workaround: 1. In Runtime Manager, open your application, and then go to **Settings** > **Properties**. 2. Add an application property or environment variable that sets `AWS_ENDPOINT_URL` to your STS endpoint URL, for example `[https://sts.{region}.amazonaws.com](https://sts.{region}.amazonaws.com)` or your custom endpoint. 3. To have the runtime use the new value, apply the changes, and then redeploy or restart the application. For more information about setting environment variables, see [Example: Using Properties to Set Environment Variables](https://docs.mulesoft.com/cloudhub-2/ch2-manage-props#example-using-properties-to-set-environment-variables). ## See Also - [Configuring Firewall Rules to Manage Traffic to and from a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules) - [Configuring Application-Level Egress Rules](https://docs.mulesoft.com/cloudhub-2/ps-config-app-level-egress) - [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) in the AWS documentation --- product: CloudHub 2.0 --- # Configuring Application Alerts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt _Alerts_ indicate whether an app is behaving as expected. You can create alerts in [Runtime Manager](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager) for applications deployed to CloudHub 2.0. You can also create basic alerts in Anypoint Monitoring that focus on application metrics such as message count and CPU utilization. See the Anypoint Monitoring documentation for more guidance on [creating basic alerts](https://docs.mulesoft.com/monitoring/alerts-hf). ## Rate Limits on Alerts Anypoint Platform enforces rate limits that determine how often an alert is triggered and prevent excessive emails from being sent. The rate limit is one alert notification email sent every 2.5 seconds per organization. This limit is enforced by a combination of organization, environment, alert (name or ID), and application. ## Before You Begin - Ensure that your default environment (defined in your profile) has Read Application permissions. ## Create a Custom Alert In Runtime Manager, bind the custom notification to an alert: 1. From Anypoint Platform, select **Runtime Manager**. 2. In the navigation menu, click **Alerts**. 3. Click the blue plus icon (**+**) to create a new alert. 4. In the **Create an Alert** page, configure your custom alert and click **Submit**: 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 2.0 and RTF Applications**. Applications Select the application that contains the flow that you configured to trigger a custom alert. Condition Select one of the following: - Deployment success: An app deploys and runs - Deployment failure: An app cannot deploy. Note that this condition is triggered only for failures and not when the app is stuck in a deployment loop. 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. ## See Also - [Configuring Alerts in Anypoint Monitoring](https://docs.mulesoft.com/monitoring/alerts-hf) --- product: CloudHub 2.0 --- # Configuring Application-Level Egress Rules > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Application-level egress rules are independent of private-space-level firewall rules. For egress traffic to go through, it must pass both private space and application-level control. ## Before You Begin - Set up your private space and finish provisioning your private network. - Verify that your account has CloudHub Network Viewer permission, which is required to view a private space’s firewall and application-level rules. - Verify that your account has CloudHub Network Administrator permission, which is required to modify a private space’s firewall and application-level rules. ## Configure Application-Level Rules in Your Private Space To configure the application-level rules in a private space: 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Firewall rules** tab, expand the **App-Level Rules** section. By default, the application-level egress rules feature is disabled when you create a new private space. Toggle the feature to enable it. Add your private DNS IP addresses to the route table if you have a transit gateway to reach your internal DNS servers and the default route is routed to the transit gateway. > [!NOTE] Ensure that you finished provisioning your private network before enabling the toggle. Toggling **App-Level Egress Rules** enables the **Default-Egress-Rule-Group**. The default egress rule is **Allow any protocol to any destination**. ![Toggle the application-level egress rules feature](/mulesoft/current/en-us/cloudhub-2/_images/ps-toggle-app-level-egress.png) To modify the default egress rule group: 1. Click **Edit**. 2. In the **Egress Rules** section of the group configuration window, select the desired protocol and destination. 3. Click **Add Rule** to add new rules to the rule group. You can delete rules by clicking the delete button (![Delete button](/mulesoft/current/en-us/cloudhub-2/_images/trash-icon.png)). 4. Click **Update Egress Rules** to save your changes. Your changes affect all applications in the current private space. You cannot rename or delete the default rule group. ![Edit the default app level egress rule group](/mulesoft/current/en-us/cloudhub-2/_images/ps-egress-edit-default.png) To create a new custom egress rule group: 1. Click **Create Rule Group**. 2. In the rule group configuration window, add a group name. You can edit and rename custom rule groups. The generated firewall rule name (`-`) can’t exceed 53 characters. 3. In the **Egress Rules** section, click **Add Rule** and select the protocol and destination for every rule that you want to add. You can delete rules by clicking the delete button (![Delete button](/mulesoft/current/en-us/cloudhub-2/_images/trash-icon.png)). 4. Click **Create Egress Rules** to save your changes. To use custom rule groups, select them in the application settings. To delete an existing custom rule group: 1. Select **More actions** (![More actions menu](/mulesoft/current/en-us/cloudhub-2/_images/more-icon.png)) > **Delete**. 2. When prompted, click **Delete Rule Group** to confirm the deletion. > [!NOTE] Once you delete a custom rule group, any applications that use it immediately start > using the default egress rule group instead. ![Delete custom egress rule group](/mulesoft/current/en-us/cloudhub-2/_images/ps-egress-delete-ruleset.png) You can disable the application-level egress rule feature by clicking the feature’s toggle. When prompted, click **Delete and Disable App-Level Rules** to confirm. > [!NOTE] Once you disable the application-level egress rule feature, all custom application-level > egress rule groups are deleted, and all application-level egress is allowed for all applications. ## Apply Application-Level Egress Rules When Deploying Your Applications You can apply the application-level egress rules that you configured in your private space when you deploy an application: 1. When deploying an application to your private space, select the **Firewall Rules** tab. 2. In the **Egress Rule Group** section, select the ruleset to apply to your application. 3. Click **Apply Changes**. ## Application Clustering and Egress Rules Application clustering in CloudHub 2.0 requires replicas to discover each other via Hazelcast. For clustered applications that use application-level egress rules, add an egress rule that allows this traffic. > [!IMPORTANT] Add an application-level egress rule that allows traffic to the local private network > on port 5701. Without this rule, replicas can’t discover or join the Hazelcast cluster, and > clustering fails. > > Add this rule to the egress rule group for your clustered application: > > - **Protocol**: `TCP` > > - **Destination**: `Local private network` > > - **Port**: `5701` ## Configure an Application-Level Egress Connection to Anypoint MQ To allow HTTPS connections to Anypoint MQ, add an application-level egress rule group with the following rules: Allow egress to the Anypoint control plane: - **Protocol**: `HTTPS` - **Destination**: `Custom Domains` - With value: - For prod: `anypoint.mulesoft.com` - For prod-eu: `eu1.anypoint.mulesoft.com` Allow egress to the MQ destination: - **Protocol**: HTTPS - **Destination**: `Custom Domains` - With the value of the domain name configured in the MQ connector URL For example, if the MQ connector URL is `[https://mq-us-east-1.anypoint.mulesoft.com/api/v1/organizations/{{anypointOrgId}}/environments/{{anypointEnvId}}/](https://mq-us-east-1.anypoint.mulesoft.com/api/v1/organizations/{{anypointOrgId}}/environments/{{anypointEnvId}}/)`, use the value `mq-us-east-1.anypoint.mulesoft.com`. ## Configure an Application-Level Egress Connection to Object Store v2 To allow HTTPS connections to Object Store v2, add an application-level egress rule group with the following rules: Allow egress to the Anypoint control plane: - **Protocol**: `HTTPS` - **Destination**: `Custom Domains` - With value: - For prod: `anypoint.mulesoft.com` - For prod-eu: `eu1.anypoint.mulesoft.com` Allow egress to the Object Store v2 destination: - **Protocol**: `HTTPS` - **Destination**: `Custom Domains` - With value: - For prod: `object-store-us-east-1.anypoint.mulesoft.com` - For prod-eu: `eu1.anypoint.mulesoft.com` This URL varies depending on the region. For example, to access Object Store in `ap-southeast-1`, add the URL `object-store-ap-southeast-1.anypoint.mulesoft.com` as the value. If you enable egress for a domain that includes redirection, such as when `salesforce.com` redirects to `www.salesforce.com`, allow egress for both the original target, `salesforce.com`, and the redirected target, `www.salesforce.com`. Wildcard records are not supported. For example, `salesforce.com` does not automatically cover `example.salesforce.com`. > [!NOTE] You can’t enable domains with double hyphens. For example, `abc—​xyz.com`. > > Domains with identical IP addresses are handled together. Allowing one domain allows all identical > domains. ## Configure an Application-Level Egress Connection to API Manager To add application-level egress support to API Manager, add a custom rule group with the following rule to allow egress to the Anypoint control plane: - **Protocol**: `HTTPS` - **Destination**: `Custom Domains` - With value: - For prod: - `anypoint.mulesoft.com` - `exchange-files.anypoint.mulesoft.com` - `analytics-ingest.anypoint.mulesoft.com` - For prod-eu: - `eu1.anypoint.mulesoft.com` - `exchange-files.eu1.anypoint.mulesoft.com` - `analytics-ingest.eu1.anypoint.mulesoft.com` The preceding list includes common endpoints. Depending on your use case, add Anypoint Platform hostnames and ports for your application to communicate with the online Anypoint Platform APIs and services that are managed by MuleSoft. See [Ports, IPs, and Hostnames to Allow](https://docs.mulesoft.com/mule-gateway/mule-gateway-hostnames). > [!NOTE] When configuring application-level egress connections to Anypoint MQ, Object Store v2, or > API Manager, you must also allow outbound access to all 443 ports at the private-space level > separately. For more information about allowing outbound access to 443 ports, visit > [Configuring Firewall Rules to Manage Traffic to and from a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules). > > You can’t use custom domains with private space internal DNS. ## Performance Impact Given the extra layer of validation, using the application-level egress rules can introduce three-millisecond to ten-millisecond network latency delays to your applications' connections and in some cases intermittent connection failures. To balance security and performance: - Use domains with a minimum Time to Live (TTL) of 30 seconds. - Limit active rule groups to 20 in your private space. - Use up to 8 domains per rule group with a minimum Time To Live (TTL) of 30 seconds per domain. You can add more domains if the TTL is longer. - Limit the total combination of rule groups and rules to 800. You can customize the number of rule groups and rules in the combination based on your needs. These measures help optimize latency while maintaining effective network security. > [!NOTE] DNS record timing issues can sometimes lead to unexpected connectivity errors. To enhance > the reliability of Mule applications, implement robust error handling and connection retry > mechanisms. ## Limitations Application-level egress rules don’t support domains that have aggressive Time to Live (TTL) values (under 30 seconds) and rapidly changing IP pools. Egress rules for these domains can cause intermittent connection failures. Examples of affected endpoints include: - AWS S3 regional endpoints (for example, `s3.ap-northeast-1.amazonaws.com`) with 5-second TTL - AWS CloudWatch endpoints with short TTLs - Other cloud provider endpoints with dynamic IP pools and aggressive TTLs Application-level egress rules don’t support AWS STS regional endpoints, such as `sts.{region}.amazonaws.com`. The STS domain uses a 30-second TTL, and egress rules for this domain can cause intermittent connection failures. Avoid configuring application-level egress rules for these scenarios. For more information, see [Known Issue: App-level Egress Rules with Low TTL Domains](https://help.salesforce.com/s/issue?language=en_US&id=a02Ka00000llC4i). When you enable an [AWS service role](https://docs.mulesoft.com/cloudhub-2/ps-config-advanced#configure-aws-role), applications using the AWS S3 Connector or other AWS SDK-based connectors still require outbound access to the public regional STS endpoint. Allow that traffic at the private-space firewall. Don’t add an application-level egress rule for STS. For details and a workaround, see [IAM Roles and AWS S3 Connector: STS Endpoint Behavior](https://docs.mulesoft.com/cloudhub-2/ps-config-advanced#aws-iam-role-sts-s3-connector-conflict). > [!IMPORTANT] The `ap-southeast` region updates its DNS records more frequently than other regions. > This behavior can cause stale DNS entries and intermittent connectivity issues. When deploying > applications in this region: > > - Implement connection retry logic with exponential backoff. > > - Monitor DNS resolution errors in your application logs. > > - Use shorter TTL values to reduce stale cache entries. ## See Also - [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) - [Configuring Firewall Rules to Manage Traffic to and from a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules) - [Anypoint MQ Overview](https://docs.mulesoft.com/mq/) - [Object Store v2 Overview](https://docs.mulesoft.com/object-store/) - [API Manager Overview](https://docs.mulesoft.com/api-manager/latest/latest-overview-concept) # Configuring Domains and Certificates (TLS Context) for a Private Space CloudHub 2.0 uses Transport Layer Security (TLS) contexts to encrypt inbound traffic to the private space. TLS contexts enable your apps to be reached at custom domains and, optionally, enable partial client authentication. Each private space includes one TLS context by default (for traffic to `cloudhub.io`), which can’t be removed. The default certificate renews automatically and requires no action from the user. You can create additional TLS contexts as required.

The cloudhub.io parent domain is shared across all customers, control planes, and regions. Because private spaces from different customers resolve under this same parent domain, browsers treat them as the same site. As a result, cookies set at the cloudhub.io scope aren’t isolated between customers.

The domain format varies by control plane. For example, applications on the US control plane use .<space-id>.<region>.cloudhub.io, while applications on other control planes add a control-plane suffix, such as .<space-id>.<region>.eu1.cloudhub.io. For more information, see Deploying Apps to Private Spaces.

Hosting websites or other browser-facing applications isn’t supported for the default cloudhub.io domain. To keep browser-facing applications isolated, deploy them to a customer-owned vanity domain by configuring a TLS context with your own domain and DNS records. See Before You Begin to create the DNS records, and DNS Records for the CloudHub 2.0 DNS record formats.
The TLS contexts that you configure for the private space define the domains that are available when deploying apps to the private spaces. See [Configuring Endpoints and Paths for Apps Deployed to a Private Space](https://docs.mulesoft.com/cloudhub-2/ch2-config-endpoints-paths). ## [](#tls-contexts)TLS Contexts Each TLS context includes a keystore and an optional truststore. To [create a TLS context](#create-tls-context): 1. Upload the keystore. 2. Upload the truststore (optional). 3. Accept the default ciphers or select ciphers to add or remove. ### [](#keystore)Keystore A _keystore_ is a repository of security certificates (either authorization certificates or public key certificates), along with their corresponding private keys used, for example, in SSL encryption. The keystore allows communication to your app using custom domains. CloudHub 2.0 supports the following keystore types: PEM (Privacy-Enhanced Mail) A PEM file is a Base64-encoded ASCII file with a `.cer`, `.crt`, or `.pem` extension. For PEM, the keystore consists of: - Public certificate - Private key - Certificate Authority (CA) path file (optional) The keystore in PEM format uses TLS default values. JKS (Java Keystore) A JKS file is a repository for authorization or public key certificates. Use this option to upload a JKS file and use TLS default values. With this option, you can’t change the default values for TLS versions, ciphers, and other TLS configuration options.
If you find any issues with your certificates after uploading a JKS keystore, use a PEM file instead.
### [](#truststore)Truststore A truststore is a set of client certificates that the server checks against to enforce partial client authentication. The optional truststore identifies trusted external clients or certificate authorities (CAs). To enable partial client authentication, configure a truststore. If a truststore is not configured, partial client authentication is disabled. CloudHub 2.0 accepts truststore files in PEM formats. ### [](#dns-targets)DNS Targets Configure a DNS target to allow clients to reach your applications from within or outside of the private network. _Public DNS targets_ allow external clients to reach your applications at custom domains. _Private DNS targets_ can only be reached from inside a private network, or through VPN or transit gateway connections. Use them with internal DNS or allowlists in your connected external networks, so clients in those networks may make requests to your applications. Private DNS targets use private static IP addresses that don’t change during the lifetime of the private space. See [IP Ranges](https://docs.mulesoft.com/cloudhub-2/ch2-networking-guide#ip-ranges). ### [](#ciphers)Ciphers When you add the TLS context, accept the default ciphers or select ciphers to add or remove. CloudHub 2.0 uses these default cipher suites, listed from most secure to lesser secure:
Cipher suite TLS version

TLS_AES_256_GCM_SHA384

TLS 1.3

TLS_CHACHA20_POLY1305_SHA256

TLS 1.3

TLS_AES_128_GCM_SHA256

TLS 1.3

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS 1.2

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS 1.2

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS 1.2

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS 1.2

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS 1.2
You can’t view or change the ciphers on the default `cloudhub.io` TLS context. To inspect the defaults in Runtime Manager, create a custom TLS context and select **Customize Ciphers**. CloudHub 2.0 then displays the default (selected) ciphers. See [Create a TLS Context](#create-tls-context). ## [](#before-you-begin)Before You Begin 1. Generate a keystore: - [PEM](https://docs.mulesoft.com/cloudhub-2/ps-config-ssl-endpoints#pem) - [JKS](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#generate-a-keystore) 2. Generate a [truststore](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#truststore-generation) (if you want to enable partial client authentication). 3. Create DNS records for your domains. To enable traffic to reach the apps deployed to the private space using a custom domain: 1. Log in to your domain registrar. Use [Whois](https://www.whois.com/) to look up your registrar. 2. Create a CNAME record in your vanity domain, pointing to your non-wildcard private space FQDN. Your registrar might take up to 24 hours to apply the change. 4. Verify that your account has CloudHub Network Administrator permission, which is required to modify a private space. For information, see [Using Teams to Manage User Permissions](https://docs.mulesoft.com/access-management/teams). ## [](#create-tls-context)Create a TLS Context To create a new TLS context: 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Domains & TLS** tab and then click **Create TLS Context**. If you don’t have CloudHub Network Administrator permission, the **Create TLS Context** button is not available. 4. Enter a name for the TLS context. The TLS context name can contain letters, numbers, spaces, and hyphens. 5. **Configure the keystore:** PEM format 1. Select **Upload PEM files**. 2. Click **Choose file** and select a public certificate to upload. Uploading the public certificate displays a summary of the certificate. - Click **…​** > **View Details** to display the keystore details. - Click **…​** > **Delete** to delete the public certificate. 3. Click **Choose file** and select a private key to upload. 4. Enter the key password used to access the private key within the keystore. If the private key is unencrypted (plain text), which is not recommended, leave the **Key Password** field blank. CloudHub 2.0 validates the password against the keystore. 5. If you have a Certificate Authority (CA) path certificate file, click **Choose file** to upload it. JKS format 1. Select **Upload JKS file**. 2. Click **Choose file** and select a keystore file to upload. 3. Enter the password used to access the keystore file. CloudHub 2.0 validates the password against the keystore. 4. Select an alias from the drop-down list. Selecting an alias displays a summary of the alias. Click the **i** to display the alias details. 5. Enter the key password used to access the private key within the keystore. CloudHub 2.0 validates the password against the key. 6. Follow the steps in [Before You Begin](#before-you-begin) to configure DNS. 7. **Configure the truststore (optional):** If you want to use partial client authentication, configure a truststore. The truststore defines the client certificates to use to enable partial client authentication with the configured keystore. Click **Add Certificates** to upload a certificate file (in PEM format). When you upload a PEM file, CloudHub 2.0 displays the client certificates from the truststore file. - Click **Add Certificates** to upload additional certificate files. - Click the information icon (**View Details**) to display the details of an individual client certificate. - Click the trash can icon (**Delete**) to delete an individual client certificate. - If more than four certificates are uploaded, click **Show all x Certificates** to expand the link. 8. **Configure advanced options: (Optional)** If you want to customize ciphers, configure advanced options. 1. Click **Advanced Options** to display the cipher configuration. 2. Select either **Use Default Ciphers** or **Customize Ciphers**. If you choose to customize ciphers, CloudHub 2.0 displays the default (selected) ciphers. - Click **X** to remove a cipher from the list. - Click **Select** to choose a different cipher from the drop-down list. 9. Click **Create TLS Context** or **Cancel** to discard changes. ## [](#view-tls-context-details)View TLS Context Details 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Domains & TLS** tab, in a custom TLS section, click the TLS context menu (**…​**) and select **View Details**. ## [](#delete-a-tls-context)Delete a TLS Context 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Domains & TLS** tab, in a custom TLS section, click the TLS context menu (**…​**) and select **Delete**. The **Delete** option appears only if you have CloudHub Network Administrator permission. ## [](#edit-a-tls-context)Edit a TLS Context 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Domains & TLS** tab and then click **Edit**. The **Edit** button appears only if you have CloudHub Network Administrator permission. 4. **Configure the keystore:** PEM format 1. Click **Choose file** to replace the current public certificate with a new public certificate. You can’t change the private key or password unless you replace the public certificate. Uploading the public certificate displays a summary of the certificate. Click the information icon (**View Details**) to display the keystore details. 2. Choose a private key to upload. 3. Enter the password used to access the private key within the keystore. If the key password is unencrypted (plain text), which is not recommended, leave the **Key Password** field blank. CloudHub 2.0 validates the password against the keystore. 4. If you have a Certificate Authority (CA) path certificate file, click **Choose file** to upload it. You can remove and add a CA path certificate without replacing the public certificate. JKS format 1. Click **Choose file** to replace the current keystore file with a new keystore file. 2. Enter the password used to access the keystore file. CloudHub 2.0 validates the password against the keystore. 3. Select an alias from the drop-down list. You can select a different alias without replacing the keystore file. Selecting an alias displays a summary of the alias. Click the information icon (**View Details**) to display the alias details. 4. Enter the key password used to access the private key within the keystore. CloudHub 2.0 validates the password against the key. 5. **Configure the truststore: (Optional)** If you want to use partial client authentication, configure a truststore. The truststore defines the client certificates to use to enable partial client authentication with the configured keystore. Click **Add Certificates** to upload a certificate file (in PEM format). When you upload a PEM file, CloudHub 2.0 displays the client certificates from the truststore file. - Click **Add Certificates** to upload additional certificate files. - Click the information icon (**View Details**) to display the details of an individual client certificate. - Click the trash can icon (**Delete**) to delete an individual client certificate. 6. **Configure advanced options: (Optional)** If you want to customize ciphers, configure advanced options. 1. Click **Advanced options** to display the cipher configuration. 2. Select either **Use Default Ciphers** or **Customize Ciphers**. If you choose to customize ciphers, CloudHub 2.0 displays the default (selected) ciphers. - Click **X** to remove a cipher from the list. - Click **Select a cipher to add** to choose a different cipher. 7. Click **Update TLS Context** or **Cancel** to discard changes. Add the LetsEncrypt root to your truststore if you want the client to trust the `cloudhub.io` certificates. ## [](#see-also)See Also - [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space) - [Configuring Endpoints and Paths for Apps Deployed to a Private Space](https://docs.mulesoft.com/cloudhub-2/ch2-config-endpoints-paths) - [Configure TLS with Keystores and Truststores](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration) --- product: CloudHub 2.0 --- # Configuring Endpoints and Paths for Apps Deployed to a Private Space > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] CloudHub 2.0 supports customizing endpoints only for apps deployed to private spaces, > not shared spaces. A private space routes requests from clients to apps deployed to the private space. When you deploy an app to a private space, CloudHub 2.0 creates two types of _endpoints_ by default: - **Endpoint**: A URL used to reach the app deployed to the private space. In this context, it’s accessible externally and enables clients outside the network to reach the app. You can delete this endpoint to prevent external traffic from reaching the app. - **Internal endpoint**: A URL used to reach the app deployed to the private space, but it’s accessible only within the private network, VPN, or transit gateway (TGW). You can’t modify or delete this type of endpoint. An example endpoint URL is `https://my-app.example.com/`. To ensure an app is accessible only within the network, use internal endpoints. You can customize how requests from clients reach the app by configuring: - Multiple custom endpoints The administrator specifies the domains that you can use for the endpoints by configuring the TLS context in the private space settings. For information, see [Configuring Domains and Certificates (TLS Context) for a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains). - Different paths for the app and the endpoint URL The _path_ is where you want your app to be reachable, for example `/api` in `my-app.example.com/api`. For information, see [HTTP Listener Reference - Mule 4](https://docs.mulesoft.com/http-connector/latest/http-listener-ref). - Different path rewrite configurations for each endpoint URL of an application The path rewrite is the base path expected by the HTTP listener in your app, for example, `/v1/api` You can also remove the external endpoint to ensure clients outside the private network can’t make requests to the app. ## Before You Begin The administrator must set up the TLS contexts for the private space before you can configure the endpoints and paths for the app. For information, see [Configuring Domains and Certificates (TLS Context) for a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains). ## Configure Multiple Endpoints You can enable your app to be reached via multiple endpoints, for example, `my-app.example.com` and `my-old-app.oldname.com`. > [!TIP] To ensure that each endpoint name is unique, use the `app-name` placeholder in the > subdomain, or the path if the domain doesn’t include a wildcard. To configure multiple endpoints: 1. When deploying an app to a private space, click the **Ingress** tab. See [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space). If the app is already deployed: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Settings**. 4. Click the **Ingress** tab. 2. Configure the first endpoint: 1. Select the first domain from the **Domain** drop-down list, for example `*.example.com`. If the domain includes a wildcard, the **Subdomain** field becomes available. 2. Enter the subdomain, or enter the `my-app` placeholder in the **Subdomain** field to use the name of the app that you specified in the **Application Name** field as the subdomain. For information, see [placeholders](#placeholder-table). 3. Enter the path that the client requests, for example `/api`. 4. Optionally enter, the path rewrite where the HTTP Listener in the app is listening, for example `/v1/api`. 5. Configure the **Access**: - External endpoints are accessible externally, and enable clients outside the network to reach the app. - Internal endpoints are only accessible within your private network or via your VPN or Transit Gateway connection. 3. If you want to configure additional endpoints, click **Add Endpoint** and repeat steps 2.1 through 2.3. 4. Depending on the deployment status, choose either: - If you’re ready to deploy the application, click **Deploy**. - If this application is deployed, click **Apply Changes**. 5. Verify that the app can be reached at each configured endpoint. ### Placeholders The subdomain and path support the following optional lowercase placeholders:
PlaceholderResolves to

app-name

Name of the app that you specified in the Application Name field when you deploy the app

business-group-id

Business group ID associated with the app

environment-id

Environment that you deploy the app to

## Configure a Different Path and Path Rewrite for the App and the URL Endpoint You can configure different paths and path rewrite for the app and the URL endpoint. For example, if the app is listening on `my-app.example.com/v1/api` and you want the app to be reachable from the internet using `my-app.example.com/api`. To configure different paths: 1. [Deploy the app to a private space](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space). 2. Click the **Ingress** tab. 3. In the **Path** field, enter the path where you want the app to be reachable, for example, `/api`. 4. In the **Path Rewrite** field, enter the base path expected by the HTTP Listener in your app, for example, `/v1/api`. 5. Click **Apply Changes** to create a configuration for your application. ## Remove an Endpoint To remove an endpoint: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Settings**. 4. Click the **Ingress** tab. 5. In the endpoint link row, click **X** (**Delete**). ## View the Default Internal Endpoint for an App An internal endpoint is accessible from inside the same private space or through the VPN or transit gateway connection for the private space. You cannot make changes to the path or domain for an internal endpoint. To view or copy the URL for the internal endpoint: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Settings**. 4. Click the **Ingress** tab. 5. In the **Endpoint** section, view or copy the endpoint labeled **Default** and **Internal**. ![Endpoint section showing the default internal endpoint for an application](/mulesoft/current/en-us/cloudhub-2/_images/default-internal-endpoint.png) ## Send Application-to-Application Requests within a Private Space In a private space, every application replica exposes an endpoint inside the private space. When you enable inbound traffic, that endpoint is exposed externally. Every application has a DNS record in the private space internal domain. For example, the DNS record for the application `helloch2` in the `2abc2ce6-cce6-463b-afaa-a1979e3xxxxx` environment is: ```none helloch2.2abc2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local ``` Because application replicas first search DNS records in the same domain before searching the parent domain, you need only the application name to send a request to another application in the same private space. If both applications are in the same namespace, you need only the application name: ```none http://helloch2:8081/hello ``` If required, replace `http` with `https`. > [!NOTE] You can’t send traffic between applications in different namespaces by using > `svc.cluster.local` endpoints. ### Application-to-Application Communication An application communicates with another application via: - The default public DNS name: `app.sxjsip.aus-s1.cloudhub.io` - The default internal DNS name (in private spaces only): `app.internal-sxjsip.aus-s1.cloudhub.io` - The custom domain name (if configured): `acme.example.com` - The cluster local DNS: `app` or `app.envid.svc.cluster.local` If you use the internal DNS name, traffic remains within the private space network. You can delete or omit the externally exposed endpoint when deploying an application to a private space. In that case, you can use the application’s internal endpoint for internal traffic. If you use the cluster local endpoint, the traffic doesn’t leave the cluster. However, the cluster local endpoint isn’t highly available. During some cluster operations such as disaster recovery, the endpoint can be unreachable. During disaster recovery, the cluster local DNS endpoint can fail if an application migrates to a new cluster. This is because traffic routed through the local DNS endpoint doesn’t traverse the ingress load balancer, which is essential for directing traffic to the new cluster. However, using other available endpoints forces traffic to pass through the ingress load balancer. The ingress load balancer detects if a disaster recovery event is happening. It also knows if an application linked to a certain endpoint has moved to a new cluster. It then routes traffic to the new cluster if needed. During node upgrades and scaling, cluster local DNS endpoints remain reachable as long as you deploy multiple application replicas. The cluster local endpoint allows traffic within the same environment only. ## See Also - [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space) - [Configuring Domains and Certificates (TLS Context) for a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains) - [HTTP Listener Reference - Mule 4](https://docs.mulesoft.com/http-connector/latest/http-listener-ref) --- product: CloudHub 2.0 --- # Configuring Firewall Rules to Manage Traffic to and from a Private Space > For the full documentation index, see: https://docs.mulesoft.com/llms.txt By default, all traffic to your private space is blocked unless it’s explicitly allowed in a firewall rule. Creating a private space automatically creates these firewall rules: - Two rules that enable inbound connections from any host: - HTTPS: port 443 - HTTP: port 80 - Two rules that enable outbound connections from within your private space to any host: - TCP: All ports - HTTPS: 443 You can also configure inbound firewall rules that use TCP as the protocol. To support Anypoint MQ, API Manager, and ObjectStore v2, you must enable outbound traffic on port 443 (HTTPS). > [!NOTE] CloudHub 2.0 doesn’t support IPv6 firewall rules. ## Configure Firewall Rules 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Firewall rules** tab. 4. Configure default rules for inbound traffic by selecting the **Protocol** and **Source** from the drop-down lists: Protocol Protocol type: - **HTTP** - **HTTPS** Source Source IP address: - **Anywhere (0.0.0.0/0)** - **Local private network** This option is available only if a private network exists in the private space. Ports Ports for inbound traffic are not configurable: - Port 80 is reserved HTTP. - Port 443 is reserved for HTTPS. - Other ports under 1024 aren’t allowed. For inbound TCP connections, only ports 30500–32500 are supported, and only for private connections (from within the private space or from a VPN or TGW). You must create a firewall rule to allow traffic on these ports. 5. Configure default rules for outbound traffic by selecting the **Protocol** and **Destination** from the drop-down lists: Protocol Protocol type: - **All** - **TCP** - **UDP** - **HTTP** - **HTTPS** Destination Destination IP address: - **Anywhere (0.0.0.0/0)** - **Local private network** This option is available only if a private network exists in the private space. Ports Port ranges for outbound traffic are configurable. 6. Click **Add rule** to add more rules. 7. To remove a firewall rule, click the trash can icon (**Delete**) for the entry. ![Delete icon on the Firewall rules tab](/mulesoft/current/en-us/cloudhub-2/_images/fw-rule-delete.png) 8. Click **Save Changes** or **Discard changes**. > [!NOTE] You can’t configure duplicate firewall rules. If you attempt to do so, an error shows > prompting you to delete any duplicated firewall rules. --- product: CloudHub 2.0 --- # Configuring Horizontal Autoscaling (HPA) for CloudHub 2.0 Deployments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Configure CPU-based horizontal scaling for Mule applications to make them responsive to CPU usage by automatically scaling up or down the deployment replicas as needed. > [!NOTE] This feature is available to organizations with an Enterprise License Agreement (ELA) or > those opted into the new pricing and packaging model. If the Horizontal Pod Autoscaling option > isn’t visible in the Runtime Manager UI, contact your account team. In Kubernetes, a Horizontal Pod Autoscaler (HPA) automatically updates a workload resource to scale the workload to match demand. Horizontal scaling automatically deploys more pods as a response to an increased load. For more information, visit the [Kubernetes documentaton](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/). The [Global Resource Pool Limit](https://docs.mulesoft.com/general/pricing#global-resource-pool-limits) does not limit the applications configured with Horizontal Pod Autoscaling. ## Configure Horizontal Pod Autoscaling To configure horizontal autoscaling for Mule apps deployed to CloudHub 2.0, follow these steps: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click **Deploy application**. 3. In the **Runtime** tab, check the **Enable CPU Based Horizontal Autoscaling** box. 4. Set the minimum and maximum **Replica Count** limits. You can deploy your application with up to 8 replicas, or you can deploy with up to 16 replicas if you have the Anypoint Integration Advanced package or a Platinum or Titanium subscription to Anypoint Platform. 5. Select the **Replica Size** from the dropdown menu. If you have the Anypoint Integration Advanced package, you can select from `Micro`, `Micro.Mem`, and `Small` replica sizes. If you have a different pricing plan, select `Micro` or `Micro.Mem` replica sizes. For more information, see [CloudHub 2.0 Application Deployment](https://docs.mulesoft.com/general/pricing#cloudhub-2-0-application-deployment). 6. Click **Deploy Application**. ![Configure horizontal autoscaling](/mulesoft/current/en-us/cloudhub-2/_images/ch2-config-autoscaling.png) ## Autoscaling Status and Logs When an autoscaling event occurs and your Mule application with horizontal autoscaling scales up, you can check the **Scaling** status by clicking **View status** in your application’s details window. You can also see your application’s **Scaling** status in the **Applications** list. ![Check the application’s scaling status.](/mulesoft/current/en-us/cloudhub-2/_images/ch2-status-autoscaling.png) To track the scaled-up replicas startup and the number of replicas your application scaled from and to, check the application’s logs: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the row of the application with autoscaling. 3. Click **Manage application**. 4. Select the **Logs** tab. Example application log ```console Info 8 minutes ago - 2023-11-08 14:35:01.466 PST - Runtime Manager Application id: scaled UP from 1 to 2 replicas. Info a minute ago - 2023-11-08 14:41:24.819 PST - Runtime Manager Application id: scaled DOWN from 2 to 1 replicas. : ``` You can track autoscaling events through [Audit Logs](https://docs.mulesoft.com/access-management/audit-logging) in Access Management. Each time an application deployment scales, an audit log is published under the product **Runtime Manager**, by user **Anypoint Staff**. The log has **Action** set to `Scaling`, and the **Object** is the application ID. The following is an example log payload: ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` ## Understand CPU-Based Autoscaling Policy MuleSoft owns and applies the [autoscaling](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale//) policy for your Mule application deployments. The CPU-based HPA policy used for all Mule apps deployed to CloudHub 2.0 is as follows: apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: 3 metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: 1 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app Some points to consider: - Scale-up can occur, at most, every 180 seconds. Horizontal autoscaling might add up to 100% of the currently running replicas until reaching the maximum configured replicas. There is no stabilization window for scaling up. The target scales up immediately after the metrics indicate a scale-up is needed. - Scale-down can occur, at most, every 15 seconds. Horizontal autoscaling might remove up to 100% of the currently running replicas, scaling down the target to the minimum allowed replicas. The number of replicas removed is based on the aggregated calculations over the past 1800 seconds of the stabilization window. Min replicas: - The minimum number of replicas guaranteed to run at any given moment. - Scale-down policy should never remove replicas below this number. Max replicas: - The maximum number of capped replicas. No more replicas can be added above this number for scaling up. - Scale-up policy should never add replicas above this number. Enabling HPA can result in customers incurring additional flow usage when your application scales horizontally. To avoid overages from unpredicted scaling, configure the maximum configured replicas judiciously to stay within purchased flow limits. Track your incurred flow usage through [usage reports](https://docs.mulesoft.com/general/usage-reports). ## Performance Considerations For a successful horizontal autoscaling of your Mule apps, review the following performance considerations: - Mule apps that scale based on CPU usage are a good fit for CPU-based HPA. For example: - HTTP/HTTPS applications with async requests. - Reverse Proxies. - Applications with low latency and high throughput. - DataWeave Transformations. - APIKit Routing. - API Gateways with policies. - Non-reentrant applications that don’t have built-in parallel processing such as batch jobs, scheduler applications without re-entrance and duplicate scheduling across applications, and applications with low throughput and high latency with large requests are not a good fit for CPU-based HPA. --- product: CloudHub 2.0 --- # Configuring Private Spaces > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After creating the private space, private network, and connections to external networks, you can configure the private space by: - [Configure SSL Endpoints and Certificates](https://docs.mulesoft.com/cloudhub-2/ps-config-ssl-endpoints) - [Configuring Domains and Certificates (TLS Context) for a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains) - [Configuring Firewall Rules to Manage Traffic to and from a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules) - [Associating Business Groups and Environments with a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-env) - [Configuring Advanced Private Space Settings](https://docs.mulesoft.com/cloudhub-2/ps-config-advanced) ## See Also - [Gathering Required Setup Information](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info) - [Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure) - [Creating VPN Connections](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-vpn) - [Creating Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-tgw) - [Managing Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-manage) --- product: CloudHub 2.0 --- # Creating Private Spaces > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To extend your network to Anypoint Platform, create a _private space_, a virtual, private, and isolated network hosted in CloudHub 2.0, to deploy your apps to. ## Create a Private Space 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. The page shows any private spaces associated with the selected business group. 2. Click **Create private space**. 3. Enter a [name](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#private-space-name) for your private space and click **Create**. You cannot rename your private space after you create it. ## Create a Private Network > [!IMPORTANT] You can’t change the private network configuration after it’s created. To change the > configuration, delete the private space and create it again. See > [Managing Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-manage). 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. The page shows any private spaces associated with the selected business group. 2. Click the name of the private space to manage. 3. On the **Network** tab, click **Create Private Network**. 4. On the **Create Private Network** page: 1. Select the [region](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#private-network-region) where you want your apps to run. If you select **Canada (Central)**, subnet count depends on your control plane. Existing MuleSoft Government Cloud private spaces in this region don’t receive three-subnet support automatically. See [Canada (Central) Private Space Subnet Availability](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#ca-central-subnet-availability). 5. Enter the [CIDR block](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#cidr-block), which is the range of IP addresses that your apps can use. 6. Optionally, reserve your corporate private network’s CIDRs to connect to your private space by entering them in a comma-separated list. When you reserve your corporate CIDRs, Anypoint Platform creates IPs for your private space without using these blocks to prevent conflicts with your corporate private network. 7. Click **Create**. The private network can take up to 30 minutes to create. \+ While the network is created, you can [create a connection to an external network](#create-connection-to-external-network). . After the network creation succeeds, you can [deploy an application](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space) to test the private network connection. If the private network creation fails, delete it and click **Create Private Network** to try again. ### Resolve Private Domains in Your Internal Network If your corporate network uses internal DNS servers to resolve requests to custom domains, configure the private space with these IP addresses and domain names. The private space uses your internal DNS to resolve internal host names of your private network (make sure your applications call the backend resources by FQDN). 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, click the **Configure** link for **Internal DNS servers**. 4. Enter the (comma-separated) [server IP addresses](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#server-ip-addresses) for your internal DNS servers. 5. Enter the (comma-separated) [domain addresses](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#domains) to be resolved by internal DNS. 6. Click **Save**. After you configure internal DNS, the **Network** tab indicates the number of configured server IP addresses and domains: ![Internal DNS configuration in the Private Network section](/mulesoft/current/en-us/cloudhub-2/_images/internal-dns.png) > [!NOTE] You can’t add MuleSoft domains or public domains as private space internal DNS. ## Create a Connection to an External Network After you create your private network, connect it to an external network using a VPN or transit gateway attachment. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, click **Create Connection**. 4. On the **Create Connection** page, select the connection type, enter the [VPN](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#vpn-name) or [transit gateway](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#transit-gateway-name)connection name, and click **Next**. Depending on the connection type you selected: - **VPN**: Follow the steps in [Creating VPN Connections](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-vpn). - **Transit Gateway**: Follow the steps in [Creating Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-tgw). ## See Also - [Gathering Required Setup Information](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info) - [Creating VPN Connections](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-vpn) - [Creating Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-tgw) - [Configuring Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-configure) - [Managing Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-manage) --- product: CloudHub 2.0 --- # Creating Transit Gateway Attachments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When you attach a transit gateway to a private space, CloudHub 2.0 creates a _transit gateway attachment_ to represent the connection on Amazon Web Services (AWS). You can attach the same transit gateway to on-premises VPCs in your own AWS account to enable communication between private spaces and VPCs. Multiple private spaces can connect to an internal VPC. You can reuse a transit gateway attachment by connecting another private space to it and accepting the attachment. You don’t need to create the resource share again. ## Before You Begin - Before creating a transit gateway attachment, [create the private network](https://docs.mulesoft.com/cloudhub-2/ps-create-configure#create-private-network). - Ensure the private space belongs to the same region in which you are creating the transit gateway attachment. Inter-region peering is not supported. For example, you cannot attach transit gateway attachment from region A to a private space belonging to region B. > [!IMPORTANT] Update your infrastructure (such as firewalls, routes, and connections) before > creating transit gateway attachments. When a transit gateway is pending acceptance, all > infrastructure updates are delayed until you accept the attachment. ## Connect to a Transit Gateway For information about limitations when attaching a 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 connect to a transit gateway: 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, **Create Connection**. 4. On the **Create Connection** page, select **Transit Gateway**. If CloudHub 2.0 finds any existing transit gateways in the organization, you can select a transit gateway or click **Add a new transit gateway** and then enter the [name](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#transit-gateway-name) in the **Connection Name** field. Use the same name for your transit gateway in AWS. You can change this name later. Connection names can contain up to 60 alphanumeric characters (a-z, A-Z, 0-9), spaces, and hyphens (-). Runtime Manager supports Unicode characters in connection names. 5. Click **Next**. Depending on whether you selected an existing transit gateway or are adding a new one, the **Add Transit Gateway** page lists the steps to create a resource share in AWS: 1. [Configure routes](#configure-tgw-routes). 2. [Create a resource share](#create-resource-share). (new gateway only) 3. [Verify the resource share](#verify-resource-share). (new gateway only) 4. [Accept the attachment](#accept-tgw-attachment). ## Configure Routes In **Static Routes**, enter the IP prefixes of the external networks to connect through the transit gateway, and then click **Next**. The routes should match VPC CIDR range so traffic can flow between the private VPC in AWS and the private space in CloudHub 2.0. After you attach the transit gateway, the private space includes the routes you specify here. To display the existing routes for the network, click **Show Existing Routes for this Network**. You can add or remove routes later. For information, see [Add or Remove a Route from the Route Table](https://docs.mulesoft.com/cloudhub-2/ps-manage#add-remove-routes). ## Create a Resource Share 1. In another browser window, 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 for your private space. 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 in Anypoint Platform, 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. 7. Click **Next**. ## Verify the Resource Share 1. On the Anypoint Platform **Add Transit Gateway** page, paste the values you copied from AWS in the **ID** and **Owner** fields: - The resource share **ID** field contains alphanumeric characters (a-z, A-Z, 0-9) and hyphens (-). - The resource share **Owner** field contains only numbers. 2. Click **Next**. CloudHub 2.0 uses the resource share owner and ID you provide to attach the associated transit gateway on AWS to the private space. When the attachment succeeds, you see the `Attachment Created` message and you return to the **Add Transit Gateway** page. ## Accept the Attachment 1. On the **Add Transit Gateway** page, click the **Transit Gateway Attachments** link. The link opens the AWS RAM console to the page for accepting the transit gateway attachments in the region you specified. 2. On the **Transit Gateway Attachments** page, select the attachment that shows **pending acceptance** in the **State** column. The attachment might take a few minutes to appear. To verify that the attachment is correct, select the transit gateway attachment ID and, on the **Details** tab, ensure that the **Resource owner account ID** is the MuleSoft AWS account ID from the **Add Transit Gateway** page. 3. From the **Actions** menu, select **Accept**. 4. When the attachment state changes to **available**, return to the **Add Transit Gateway** page and click **Done**. You return to the **Network** tab for the private space. The **Connections** section shows the transit gateway ID and owner from AWS and indicates that the transit gateway state is **Available** and the attachment state is **Attached to Private Network**: If the VPC attachment state is **Not Attached to VPC**, the transit gateway is not attached. Click **Accept the attachment** link and follow the steps again. 5. [Test the connection](#test-connection) from your private space to the transit gateway. ## Configure Transit Gateway Routing CloudHub 2.0 supports static routing for transit gateways. Configure the network routes (subnets) that you want to be accessible through the transit gateway: - On Anypoint Platform, [configure routes for outbound traffic from the private space](#enable-outbound-traffic-from-ps) to an external destination. - On AWS, [enable inbound traffic](#enable-inbound-traffic-on-aws) through your transit gateway. ### Configure Routes for Outbound Traffic from the Private Space After the **Attached to Private Network** message appears, the private spaces adds the routes that you [specified](#connect-tgw) so that apps deployed to the private space can access the transit gateway. To add routes to the transit gateway route table, see [Add or Remove a Route from the Route Table](https://docs.mulesoft.com/cloudhub-2/ps-manage#add-remove-routes). ### 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. ## Test the Connection to Your Private Space After you connect to a transit gateway, test the connectivity from CloudHub 2.0 to your networks. To test the connection, use the Network Tools application. For download and usage information about the Network Tools application, see [How To Use Network Tools Application](https://help.salesforce.com/s/articleView?id=001115029&type=1). ## Maintain the Transit Gateway After you test the connection to your private space, periodically check the connection to your transit gateway. If your private space loses access to the transit gateway, the state of the transit gateway changes to `unknown` or `deleted`. If the transit gateway remains in the `unknown` or `deleted` state for 14 days, Anypoint Platform might remove the private space attachments from the transit gateway. However, the transit gateway itself is not removed. Your private space loses access to a transit gateway when: - The transit gateway is deleted from CloudHub 2.0. - The transit gateway is deleted from the AWS console. - A resource share is deleted. - The MuleSoft account principal is deleted from the resource share. To remove or delete the transit gateway from CloudHub 2.0, complete the steps in [Delete a Transit Gateway](#delete-tgw) before deleting the transit gateway, transit gateway attachment, or resource share from the AWS console. Removing connections from the AWS console without removing them from CloudHub 2.0 disrupts the connection but does not remove it. ## Troubleshoot States for the Transit Gateway or Transit Gateway Attachment When the transit gateway connection is disrupted, the state of the transit gateway or transit gateway attachment changes to `unknown`, `rejected`, or `deleted`. Depending on the cause of the state change, you can fix the state of the transit gateway or transit gateway attachment by deleting and recreating or detaching and reattaching them. ### Resolve Transit Gateway States The `unknown` state for a transit gateway state occurs when: - The transit gateway or resource share is deleted. To fix this state, delete the transit gateway from CloudHub 2.0 using the steps in [Delete a Transit Gateway](#delete-tgw). - The MuleSoft account principal is deleted. To fix this state, add the principal in the resource share. The `deleted` state occurs when the transit gateway is deleted from the AWS console but not CloudHub 2.0. To fix this state, delete the transit gateway from CloudHub 2.0 using the steps in [Delete a Transit Gateway](#delete-tgw), then create a new transit gateway. ### Resolve Transit Gateway Attachment States The `deleted` state for a transit gateway attachment occurs when the transit gateway attachment is deleted from the AWS console but not CloudHub 2.0. To fix this state, detach the transit gateway attachment from the private space using the steps in [Detach a Transit Gateway from the Private Space](#detach-tgw), then reattach the transit gateway attachment. The `rejected` state for a transit gateway attachment occurs when the transit gateway attachment is rejected. To fix this state, detach the transit gateway attachment from the private space using the steps in [Detach a Transit Gateway from the Private Space](#detach-tgw), then reattach the transit gateway attachment. ## 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. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, click the transit gateway menu (**…​**) and select **Rename**: 4. Enter the new name and click **Save**. ## Detach a Transit Gateway from the Private Space You might want to detach a transit gateway attachment for the following reasons: - If you reject an attachment in AWS, the transit gateway attachment appears as `Rejected` in Anypoint Platform. In this case, you must remove the attachment before trying to attach it again. - If an attachment is deleted on AWS, you can remove the attachment from Anypoint Platform. Removing a transit gateway attachment also deletes any associate routes. The resource share on AWS remains unaffected so you can readd the transit gateway without creating a new one. However, detaching a transit gateway from a private space also deletes the attachment in AWS. The transit gateway appears under **Add a transit gateway** if you only detach it and do not delete it from your organization. Any apps deployed to the private space continue to run, but they are no longer connected to your Amazon VPCs and VPNs. To detach the transit gateway: 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, click the transit gateway menu (**…​**) and select **Detach**: 4. At the confirmation prompt, click **Detach**. Detaching a transit gateway might take several minutes. ## Delete a Transit Gateway To completely remove the transit gateway from your Anypoint Platform organization, use the [delete transit gateway API call](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/minor/1.0/console/method/%234136/) (`DELETE <>/organizations/:orgId/transitgateways/:tgw-id`) and delete the resources share on AWS. For information, see [Deleting a resource share](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-delete.html) in the AWS documentation. ## See Also - [Gathering Required Setup Information](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info) --- product: CloudHub 2.0 --- # Creating VPN Connections > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To connect your private network to an external network using a VPN, create the VPN connection on the **Network** tab. If you have an existing Anypoint VPN, change the remote IP to repurpose the VPN for use with CloudHub 2.0. For more information, see the [Anypoint VPN documentation](https://docs.mulesoft.com/cloudhub/vpn-about). > [!NOTE] After you create a VPN, you can’t change any of the VPN settings, except the static IP > prefixes for static routing. ## Before You Begin Before creating a VPN connection, [create the private network](https://docs.mulesoft.com/cloudhub-2/ps-create-configure#create-private-network). ## Create a VPN 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, **Create Connection**. 4. On the **Create Connection** page, select **VPN**, enter the [name](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#vpn-name) in the **Connection Name** field, and click **Next**. Connection names can contain up to 60 alphanumeric characters (a-z, A-Z, 0-9), spaces, and hyphens (-). Runtime Manager supports Unicode characters in connection names. 5. On the **Create VPN Connection** page, enter the [remote IP address](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#remote-ip-address) (a single, static IP address) for your VPN endpoint. 6. Select the routing type: [Dynamic (BGP)](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#dynamic-vpn-routing) Select this option if your device supports Border Gateway Protocol (BGP). BGP supports automatic failover for redundant connections. 1. In the **Local ASN** field, enter a [local private ASN](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#local-asn) that isn’t already assigned to your network. If you have already created a VPN in this private space, the **Create VPN Connection** page doesn’t display the **Local ASN** field. 2. In the **Remote ASN** field, enter a [remote private ASN](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#remote-asn). [Static](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#static-vpn-routing) Select this option if your device doesn’t support BGP. 1. In the **Local ASN** field, enter a [local private ASN](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#local-asn) that isn’t already assigned to your network. Although the local ASN isn’t used for static routing, you must specify this value when you create the first VPN because it is required for any future VPN connections using BGP for this private space. 2. In the **Static Routes** field, specify the (comma-separated) [static IP prefixes](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#static-ip-prefixes) in CIDR notation. Click **Show Existing Routes for this Network** to view the existing routes for the private network. > [!NOTE] You cannot use/have an overlap with the following > [reserved CIDR blocks](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#cidr-block) for static routes 7. If you want to customize the tunnel configuration, expand **Advanced Options**: 1. Select [**Automatic Tunnel Initiation**](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#auto-tunnel-initiation) to specify that the VPN starts up automatically. If you deselect this option, you must generate traffic from the customer gateway to establish VPN tunnels. If you have already created a VPN in this private space, this option isn’t available. 2. Select the tunnel configuration: - **Automatic** Select this option to use the default tunnel configuration. - **Custom** Select this option to customize: - [IP ranges](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#inside-ip-cidrs) (in CIDR format) for the internal address of each VPN tunnel. - [Pre-shared keys](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#preshared-keys) (PSKs) for each VPN tunnel. > [!NOTE] You must specify values for all four fields. 8. Click **Create VPN**. The VPN can take up to 15 minutes to create. Once created, you can [connect the VPN to your corporate network](#connect-vpn) or you can click **Close** and complete this step later. While the VPN is created, you can [create a redundant VPN](#create-redundant-vpn). If the VPN creation fails, click **Create VPN** to try again. . [Test the connection](#test-connection) from your private space to the VPN. ## Connect a VPN to Your Corporate Network After the VPN creation completes successfully, the tunnel status is **Down** until you connect the VPN to your corporate network. To connect the VPN to your corporate network, you or your network administrator must configure your gateway device outside of Anypoint Platform. To facilitate this configuration, you provide information about your gateway device, which Anypoint Platform uses to generate a connection guide to use to configure your device. After the VPN connection creation completes, the **Create VPN Connection** window displays the **Connect VPN** step. You can also display this page from the **Network** tab by clicking **View Connection Guide** or clicking the VPN menu (**…​**) and selecting **Connection Guide**. 1. Select options from the drop-down lists: - **Device vendor** - **Device platform** - **Device software** See [Supported Gateway Devices](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#supported-gateway-devices). 2. Click **Download Connection Guide**. The connection guide, in `.txt` format, downloads to your local system. 3. Give the connection guide to your network administrator to use to configure your gateway device. For information, see [Your customer gateway device](https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html) in the AWS VPN documentation. ## Create a Redundant VPN If only one VPN has been configured, the **Network** tab displays an option to create a redundant VPN. MuleSoft strongly recommends that you create a redundant VPN. For information, see [VPN High Availability](https://docs.mulesoft.com/cloudhub-2/ps-vpn-about#vpn-ha). Redundant VPNs inherit some settings from the initial VPN configuration automatically. > [!IMPORTANT] After you create a redundant VPN, you can’t change any of the settings. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, click **Create Redundant VPN**. 4. On the **Create Redundant VPN Connection** page, complete the fields, based on the routing type of the initial VPN: Dynamic (BGP) 1. In the **Remote IP** field, enter the public IP address (a single, static IP address that isn’t used by other VPNs) of your VPN endpoint. 2. In the **Remote ASN** field, enter a private ASN. By default, **Remote ASN** contains the value from the first VPN, but you can change this value. Static In the **Remote IP** field, enter the public IP address (a single, static IP address that isn’t used by other VPNs) of your VPN endpoint. Because you have already created a VPN in this private space, the **Create Redundant VPN Connection** page doesn’t display the **Local ASN** field. 5. If you want to customize the tunnel configuration, expand **Advanced Options** and specify: - The IP ranges (in CIDR format) for the internal address of each VPN tunnel. - The PSKs for each VPN tunnel. > [!NOTE] The redundant VPN uses the tunnel initiation option specified for the initial VPN. Any tunnel configuration values that you don’t customize are set to the default. 6. Click **Create VPN**. The redundant VPN can take up to 15 minutes to create. If the redundant VPN creation fails, click **Create Redundant VPN** to try again. ## Test the Connection to Your Private Space After you create the VPN, test the connectivity from CloudHub 2.0 to your networks. To test the connection, use the Network Tools application. For download and usage information about the Network Tools application, see [How To Use Network Tools Application](https://help.salesforce.com/s/articleView?id=001115029&type=1). ## See Also - [Gathering Required Setup Information](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info) - [Anypoint Virtual Private Network](https://docs.mulesoft.com/cloudhub-2/ps-vpn-about) --- product: CloudHub 2.0 --- # Deploy an App with TCP using the Application Manager API > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To configure protocols other than HTTP or HTTPS, first set up TCP inbound firewall rules to allow TCP traffic for your private space. You can then use the [Application Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/minor/1.0/pages/home/) to deploy an app using TCP. TCP inbound firewall rules don’t support custom endpoints. To configure firewall rules using TCP, follow the steps in [Configure Firewall Rules](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules#configure-firewall-rules) and select TCP. ## Before You Begin Configure these network-level rules for the firewall in your private space: - An ingress rule: `Allow TCP` on the port range `30500-32500`. - An egress rule: `Allow HTTP/HTTPS` to `Any Destination`. If you must restrict outbound traffic, configure `Allow TCP` to `Any Destination` on the port `` as a rule. ## Find Available Ports for Your App The port range for TCP is between 30500 to 32500. To confirm port availability, use the [CloudHub 2.0 API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/) that returns a list of available ports. These examples show the API request and response when you use it to find available ports: Request: ```json GET https:/anypoint.mulesoft.com/runtimefabric/api/organizations/{organizationId}/privatespaces/{privatespaceId}/ports?available=true&count=10 ``` In the request, the `available` parameter provides unused ports in the response. The `count` parameter lets you specify the number of ports, between 1 and 10. The actual availability of ports limits the end result. Response: ```json { "ports": [30500, 30501, 30502, 30503, 30504, 30511, 30512, 30513, 30514, 30515] } ``` ## Deploy an App Using the Application Manager API In the [Application Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/amc-application-manager/minor/4.0/console/method/%231158/), use the `tcp` section under `deploymentSettings` to map your TCP port and deploy your app. The mapping uses the external port to expose `portNumber` and the app level-defined port `applicationPortNumber`. You can use the same value for both fields, and there are no restrictions requiring them to differ. You can configure up to 10 ports per application. This example shows the request to deploy a new app using a TCP port mapping: ```json POST https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{organizationId}/environments/{environmentId}/deployments { "name": "logs-app-uc01", "labels": [ "beta" ], "target": { "provider": "MC", "targetId": "cfe2157f-438b-4fb8-81fe-13ec89c55545", "deploymentSettings": { "clustered": false, "enforceDeployingReplicasAcrossNodes": false, //------------------------------------NEW------------------------------------- "tcp": { "inbound": { "ports": [ { "portNumber": 30500, "applicationPortNumber": 9000 }, { "portNumber": 30501, "applicationPortNumber": 9001 }, { "portNumber": 30502, "applicationPortNumber": 9002 }, ] } }, //------------------------------------NEW------------------------------------- "jvm": {}, "runtimeVersion": "4.4.0:20220523-1", "updateStrategy": "rolling", "disableAmLogForwarding": false, "generateDefaultPublicUrl": true }, "replicas": 1 }, "application": { "ref": { "groupId": "66310c16-bce5-43c4-b978-5945ed2f99c5", "artifactId": "app-with-40-schedulers", "version": "1.0.5", "packaging": "jar" }, "assets": [], "desiredState": "STARTED", "configuration": { "mule.agent.application.properties.service": { "applicationName": "logs-app-uc01", "properties": {}, "secureProperties": {} }, "mule.agent.logging.service": { "artifactName": "logs-app-uc01", "scopeLoggingConfigurations": [] } }, "integrations": { "services": { "objectStoreV2": { "enabled": false } } }, "vCores": "0.05" } } ``` Deployments that include unavailable ports fail. Successful deployments use the newly mapped ports, and those ports become unavailable. If the app is deleted, the ports become available again. ## Update an App Using the Application Manager API Using the [Application Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/amc-application-manager/minor/4.0/console/method/%231158/), change the `tcp` mapping in the `deploymentSettings` section to update the TCP port, and then redeploy the app. This example shows a request to update an existing app and its body with a new TCP mapping: ```json PATCH https://anypoint.mulesoft.com/amc/adam/api/organizations/{organizationId}/environments/{environmentId}/deployments/{deploymentId} { "id": "id", "target": { "provider": "MC", "targetId": "873a9879-cca7-4211-b90e-826e98123929", "deploymentSettings": { "tcp": { "inbound": { "ports": [ { "portNumber": 30507, "applicationPortNumber": 9007 }, { "portNumber": 30508, "applicationPortNumber": 9008 }, { "portNumber": 30509, "applicationPortNumber": 9009 } ] } } } } } ``` Updates that include unavailable ports fail. Successful deployments occupy the newly mapped ports, and those ports become unavailable. The ports that you replaced with new mappings become available. ## Access Your TCP App - You can access the app using VPN or a transit gateway and within the private space. Because the apps run on worker nodes, you can’t access them directly over the internet. TCP endpoints use wildcard domains. The app-name or prefix is irrelevant. You can access applications on the endpoint: `*...tcp.cloudhub.io:`. A sample URL is `mllp-app-2-mpskt5.q8b5lv.usa-e2.tcp.cloudhub.io:30500`. - You can’t establish a connection directly to the TCP URL, such as: `corvette-azeiuc.internal-yvs7m6.usa-w1.tcp.cloudhub.io.".` The TCP URL format has the structure: {application-url}.{environment}.tcp.cloudhub.io:{port}. You can’t add "internal-" to the {environment}, as CloudHub 2.0 doesn’t support internal endpoints for TCP applications. --- product: CloudHub 2.0 --- # Deploying Apps to CloudHub 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can deploy Mule apps to either a shared or private space in CloudHub 2.0. - [Deploying Apps to Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-shared-space) - [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space) - [Downloading Test Apps from Exchange](https://docs.mulesoft.com/cloudhub-2/ch2-download-test-app) > [!IMPORTANT] CloudHub 2.0 supports Mule runtime engine versions 4.3.x and later. ## Application Deployment After triggering a deployment, the application status eventually changes to `RUNNING`. If the application status never changes to `RUNNING`, the replicas contain a `state` and `reason` to indicate why the application status is not `RUNNING`. When an application is deployed, the following events occur: 1. The expected state of your application is stored, including application bundle and number of replicas. 2. The application replica status is `PENDING`. 3. When adequate compute and memory resources are available, each replica is attached to a node. 4. The replica status is `STARTING`. 5. The replica finishes loading the application. 6. The replica status is `STARTED` and the replica can now perform work. ## Application Deployment Failure If an application fails, for example, due to running of out memory, the following events occur: 1. The replica status is `TERMINATED`. 2. CloudHub 2.0 immediately attempts to restart the replica. 3. The replica status is `RECOVERING`. If the replica is able to restart: 1. The replica finishes loading the application. 2. The replica status is `STARTED` and the replica can now perform work. If the replica can’t restart, for example, it relies on a network resource which temporarily unavailable, the following events occur: 1. The replica status is `PENDING`, with a message indicating "CrashLoopBackoff". CloudHub 2.0 attempts to restart the replica, using exponential backoff to avoid an excessive number of restart attempts. 2. The replica status alternates between `RECOVERING` and `PENDING` until the issue preventing a successful restart is resolved. 3. The replica loads the application. After a successful restart, the replica status is `STARTED` and the replica can now perform work. ## Grace Period When you stop, restart, update, redeploy, or terminate an application, CloudHub 2.0 tries to delete it from Mule. To make sure inflight messages are delivered, there’s a five-minute timeout period. After that period, CloudHub 2.0 shuts down the whole instance. This grace period applies to the application instance, not to the runtime. The runtime uses its own configuration for shutdown. By default, the runtime grace period is five seconds. For more information about shutdown timeout behavior and how CloudHub 2.0 handles long-running flows, see [Shutdown Timeout Behavior](https://docs.mulesoft.com/cloudhub-2/ch2-understand-app-restart#shutdown-timeout-behavior). ## See Also - [Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) - [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about) # Deploying Apps to Private Spaces You deploy apps to a private space using Runtime Manager.
CloudHub 2.0 supports Mule runtime engine versions 4.3.x and later.
Runtime Manager doesn’t support deploying an application to CloudHub 2.0 or Runtime Fabric if the asset was previously soft-deleted in Exchange.
## [](#deploy-app-private-space)Deploy an App to a Private Space 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click **Deploy application**. 3. On the **Deploy Application** page: 1. Enter the [name](#app-name-reqs) of the application.
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.
2. Select an application file: - To upload a Mule app JAR file from your system, select **Choose file > Upload file**. File names can contain only letters, numbers, and underscores per guidelines on [unique package names](https://docs.oracle.com/javase/specs/jls/se6/html/packages.html#7.7). - To choose an example app from Anypoint Exchange: 1. Select **Choose file > Import file from Exchange**. 2. On the **Get from Exchange** page, enter `hello` in the **Search assets by name**: ![Get from Exchange page](/mulesoft/current/en-us/cloudhub-2/_images/rtm-get-from-exchange.png) 3. Click **Hello World** and then click **Select**. 3. Select the name of the private or shared space from the **Deployment Target** list. 4. Configure options for deployment: - [Specify runtime options](#specify-runtime-options). - [Configure endpoints and paths for the app](#configure-endpoint-path). - [Change app behavior with properties](#app-properties). - [Configure logging for the app](#configure-logging). 4. Click **Deploy Application**. ### [](#specify-runtime-options)Specify Runtime Options Click the **Runtime** tab and specify the following options: Runtime version Specifies the Mule runtime engine version. Versions 4.3.x, 4.4.x, 4.5.x, and 4,6.x are supported. 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 and latest 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.
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). Replica size Specifies the number of vCores in the replica to run your application. For information on replica sizes, memory, and storage, see [CloudHub 2.0 Replicas](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#cloudhub-2-replicas). CloudHub 2.0 limits the replica size per deployment to four vCores. Replica Count Specifies the number of replicas, or instances, of the application to deploy. A minimum of two replicas is required for high availability. Run in Runtime Cluster Mode Enables [Mule clustering](https://docs.mulesoft.com/cloudhub-2/ch2-clustering) across each replica of the application. This option requires at least two replicas. Use Object Store V2 You can select [Object Store v2](https://docs.mulesoft.com/object-store/) as the implementation by checking the **Use Object Store V2** checkbox. Deployment model - **Rolling update**: - Maintains availability by incrementally updating replicas. - **Recreate**: - Terminates replicas before redeployment. - Redeployment is faster and doesn’t require additional resources. ## [](#configure-endpoint-path)Configure Endpoints and Paths for the App For more information, see [Configuring Endpoints and Paths for Apps Deployed to a Private Space](https://docs.mulesoft.com/cloudhub-2/ch2-config-endpoints-paths). To configure endpoints for the app to enable access from the internet: 1. Click the **Ingress** tab and specify the following options: Endpoint - **Host**: Select the domain, such as `cloudhub.io`, for the app from the drop-down list.
If you select cloudhub.io (the default domain), you can’t select a subdomain or path.
The administrator configures the domains and certificates (TLS context) for the private space. See [Configuring Domains and Certificates (TLS Context) for a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains). After you select the domain for a private space, you can view the corresponding TLS context by clicking **View TLS Context**: - **Subdomain**: If the domain you selected includes a wildcard, you can configure the subdomain. Subdomains must start and end with an alphanumeric character and can contain only alphanumeric characters (a-z, A-Z, 0-9), hyphens (-), underscores (-), and periods (.). Subdomains support [placeholders](#placeholder-table). The default subdomain is `app-name`, which resolves to the name of the app that you specified in the **Application Name** field when you deploy the app. - **Path**: specifies the URL path to the application endpoint. Paths must start and end with an alphanumeric character and can contain only alphanumeric characters, hyphens, and underscores. Paths support [placeholders](#placeholder-table). - To add an endpoint, click **Add Endpoint** and specify options. - To remove an endpoint, click the **X** in the endpoint row.
Depending on the control plane you’re deploying to, the endpoint URL format requires the region suffix before cloudhub.io or not. For applications deployed to the US control plane, don’t add the region suffix, for example: https://.10u6w7.usa-e1.cloudhub.io. For applications deployed to any of the other control planes, add the corresponding region suffix, for example: https://.10u6w7.usa-e1.eu1.cloudhub.io.
Path Rewrite If the HTTP Listener in your app listens on a different path than the path defined in **Endpoints**: 1. Enable the **Rewrite Request Paths** option. 2. Enter the target path expected by your app. Requests sent to your app use the path that you specify here. Check these examples to see how the private space rewrites the path: **Application endpoint 1:** ```console https://sapi-one-o4azsf.2x9yyp.usa-e2.cloudhub.io/acct ``` **Path rewrite 1:** ```console /version1 ``` **Application endpoint 2:** ```console https://sapi-one-o4azsf.2x9yyp.usa-e2.cloudhub.io/acct/moreInfo ``` **Path rewrite 2:** ```console /version1/moreInfo ``` TLS Options - **Forward SSL Session** Enables SSL forwarding during a session. SSL forwarding is mostly used with client authentication. See [Enable Client Authentication](https://docs.mulesoft.com/anypoint-security/enable-client-authentication). SSL forwarding forwards client certificate details in HTTP request headers so they are available to the application. These fields can identify an authenticated client and allow an application to determine and use the identity. The following headers are available:
Header Name Value

x-ssl-client-verify

SUCCESS/FAIL

x-ssl-issuer

Client certificate issuer

x-ssl-client-serial

Client certificate serial number

x-ssl-client-dn

Contents of the client certificate DN field

x-ssl-client-cert

Contents of the client certificate
- **Last-Mile Security** Specifies that TLS termination and decryption for the forwarded HTTPS connections occurs in the application. This option requires that the Mule application include an SSL certificate and also requires more CPU resources. 2. Click **Deploy Application** to create a new configuration for your application. ### [](#app-name-reqs)Application Names The application name you specify can contain between 3 and 42 alphanumeric characters (a-z, A-Z, 0-9) and dashes (-). They cannot contain spaces or other characters. The application name must start with a letter (a-z or A-Z). It cannot start with a number or dash and it cannot end with a dash. To ensure that names are unique and avoid domain conflicts, CloudHub 2.0 adds a six-character `_unique-id_` to the application name that you specify in the public endpoint URL. The application name identifies your application not only in Runtime Manager but also in the public `cloudhub.io` domain. For example, an application named `myapp` is accessible at `http://myapp-_unique-id_._shard_.usa-w2.cloudhub.io`. You must have unique application names for each deployment target. To further customize your app names, you can create a naming convention. For example, you could prepend your company name and department to all application names, such as `mycompany-mydept-myapp`. You can then add DNS records to hide the complex application name. For example, you might route requests to `myapp.mycompany.com` to `mycompany-mydept-myapp-_unique-id_._shard_._region_.cloudhub.io`. Make application file names as unique as possible. An app cannot be deployed if it shares the same name as an asset in Exchange. ### [](#placeholder-table)Placeholders The subdomain and path support the following optional lowercase placeholders:
Placeholder Resolves to

app-name

Name of the app that you specified in the Application Name field when you deploy the app

business-group-id

Business group ID associated with the app

environment-id

Environment that you deploy the app to
## [](#app-properties)Change App Behavior with Properties You can configure property values, such as specifying the environment or setting passwords and usernames, during app deployment. For information about configuring app properties, see: - [Changing App Behavior with Properties](https://docs.mulesoft.com/cloudhub-2/ch2-manage-props) - [Protecting App Property Values](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props) ## [](#configure-logging)Configure Logging for the App Logging is enabled by default for apps deployed to CloudHub 2.0. ### [](#disable-or-enable-logging)Disable or Enable Logging To disable or reenable logging for the app: 1. Click the **Monitoring** tab. 2. Deselect or select the **Forward application logs to Anypoint Platform** option. 3. Click **Apply Changes**. If you disable logging, the **Logs** heading still appears in the Runtime Manager navigation menu, but application logs are not collected. ### [](#configure-log-levels-and-categories)Configure Log Levels and Categories To configure additional log levels and categories to include in logs: 1. Click the **Monitoring** tab. 2. Select the log level: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 3. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 4. Click **Apply Changes**.
Changing the log level and clicking Apply Changes restarts the application.
## [](#enable-trace-data-collection)Enable Trace Data Collection
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 documentation.
Traces enable you to understand the path of a transaction in the MuleSoft ecosystem by providing full visibility into the execution path of API calls or application transactions. When you enable trace data collection for an app, Anypoint Platform collects and exposes tracing information from Mule runtime engine in the OpenTelemetry standard, enabling you to export it using the Anypoint Monitoring [Telemetry Exporter](https://docs.mulesoft.com/monitoring/telemetry-exporter). You can enable trace data collection for your CloudHub 2.0 applications running on Mule version 4.6 or later. You can’t enable trace data collection using the Mule Maven plugin, Anypoint CLI, or Anypoint Studio. You can enable trace data collection using only the UI and API. To enable trace data collection for an app: 1. Click the **Monitoring** tab. 2. Select the **Enable tracing** checkbox. 3. Click **Deploy Application** if you are enabling the feature for a new deployment, or **Apply Changes** if you are editing an existing application. Once you enable tracing, and redeploy your application, the Runtime Manager backend starts instrumenting traces for your application. ## [](#see-also)See Also - [Downloading Test Apps from Exchange](https://docs.mulesoft.com/cloudhub-2/ch2-download-test-app) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) on Exchange - [Configuring Endpoints and Paths for Apps Deployed to a Private Space](https://docs.mulesoft.com/cloudhub-2/ch2-config-endpoints-paths) - [Configuring Domains and Certificates (TLS Context) for a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains) - [Integrating with Your Logging System Using Log4j](https://docs.mulesoft.com/cloudhub-2/ch2-integrate-log-system) --- product: CloudHub 2.0 --- # Deploying Apps to Shared Spaces > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You deploy apps to a shared space using Runtime Manager. > [!IMPORTANT] CloudHub 2.0 supports Mule runtime engine versions 4.3.x and later. > [!NOTE] Runtime Manager doesn’t support deploying an application to CloudHub 2.0 or Runtime Fabric > if the asset was previously [soft-deleted](https://docs.mulesoft.com/exchange/to-delete-asset) in Exchange. ## Deploy an App to a Shared Space 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click **Deploy application**. 3. On the **Deploy Application** page: 1. Enter the [name](#app-name-reqs) of the application. > [!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. 2. Select an application file: - To upload a Mule app JAR file from your system, select **Choose file > Upload file**. - To choose an example app from Anypoint Exchange: 1. Select **Choose File > Import file from Exchange**. 2. In the **Get from Exchange** page, enter `hello` in the **Search assets by name**: ![Get from Exchange page](/mulesoft/current/en-us/cloudhub-2/_images/rtm-get-from-exchange.png) 3. Click **Hello World** and then click **Select**. 3. Select **CloudHub 2.0**, and then **Shared Space** for the region from the **Deployment Target** list. For the list of regions, see [Shared Global Regions](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#shared-global-regions). If you have the global deployment entitlement, all regions are available. If you have region restrictions based on your subscription, only regions that are available to your organization appear. 4. Configure options for deployment: - [Specify runtime options](#specify-runtime-options). - [Change app behavior with properties](#app-properties). - [Configure logging for the app](#configure-logging). 4. Click **Deploy Application**. ### Specify Runtime Options Click the **Runtime** tab and specify the following options: Runtime version Specifies the Mule runtime engine version. Versions 4.3.x, 4.4.x, 4.5.x, and 4,6.x are supported. 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 and latest 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. > [!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). Replica size Specifies the number of vCores in the replica to run your application. For information on replica sizes, memory, and storage, see [CloudHub 2.0 Replicas](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#cloudhub-2-replicas). CloudHub 2.0 limits the replica size per deployment to four vCores. Replica Count Specifies the number of replicas, or instances, of the application to deploy. A minimum of two replicas is required for high availability. Run in Runtime Cluster Mode Enables [Mule clustering](https://docs.mulesoft.com/cloudhub-2/ch2-clustering) across each replica of the application. This option requires at least two replicas. Use Object Store V2 You can select [Object Store v2](https://docs.mulesoft.com/object-store/) as the implementation by checking the **Use Object Store V2** checkbox. Deployment model - **Rolling update**: - Maintains availability by incrementally updating replicas. - **Recreate**: - Terminates replicas before redeployment. - Redeployment is faster and doesn’t require additional resources. ### Application Names The application name you specify can contain between 3 and 42 alphanumeric characters (a-z, A-Z, 0-9) and dashes (-). They cannot contain spaces or other characters. The application name must start with a letter (a-z or A-Z). It cannot start with a number or dash and it cannot end with a dash. To ensure that names are unique and avoid domain conflicts, CloudHub 2.0 adds a six-character `_unique-id_` to the application name that you specify in the public endpoint URL. The application name identifies your application not only in Runtime Manager but also in the public `cloudhub.io` domain. For example, an application named `myapp` is accessible at `http://myapp-_unique-id_._shard_.usa-w2.cloudhub.io`. You must have unique application names for each deployment target. To further customize your app names, you can create a naming convention. For example, you could prepend your company name and department to all application names, such as `mycompany-mydept-myapp`. You can then add DNS records to hide the complex application name. For example, you might route requests to `myapp.mycompany.com` to `mycompany-mydept-myapp-_unique-id_._shard_._region_.cloudhub.io`. Make application file names as unique as possible. An app cannot be deployed if it shares the same name as an asset in Exchange. ## Change App Behavior with Properties You can configure property values, such as specifying the environment or setting passwords and usernames, during app deployment. For information about configuring app properties, see: - [Changing App Behavior with Properties](https://docs.mulesoft.com/cloudhub-2/ch2-manage-props) - [Protecting App Property Values](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props) ## Configure Logging for the App Logging is enabled by default for apps deployed to CloudHub 2.0. ### Disable or Enable Logging To disable or reenable logging for the app: 1. Click the **Monitoring** tab. 2. Deselect or select the **Forward application logs to Anypoint Platform** option. 3. Click **Apply Changes**. If you disable logging, the **Logs** heading still appears in the Runtime Manager navigation menu, but application logs are not collected. ### Configure Log Levels and Categories To configure additional log levels and categories to include in logs: 1. Click the **Monitoring** tab. 2. Select the log level: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 3. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 4. Click **Apply Changes**. > [!NOTE] Changing the log level and clicking **Apply Changes** restarts the application. ## Enable Trace Data Collection > [!NOTE] 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. Traces enable you to understand the path of a transaction in the MuleSoft ecosystem by providing full visibility into the execution path of API calls or application transactions. When you enable trace data collection for an app, Anypoint Platform collects and exposes tracing information from Mule runtime engine in the OpenTelemetry standard, enabling you to export it using the Anypoint Monitoring [Telemetry Exporter](https://docs.mulesoft.com/monitoring/telemetry-exporter). You can enable trace data collection for your CloudHub 2.0 applications running on Mule version 4.6 or later. You can’t enable trace data collection using the Mule Maven plugin, Anypoint CLI, or Anypoint Studio. You can enable trace data collection using only the UI and API. To enable trace data collection for an app: 1. Click the **Monitoring** tab. 2. Select the **Enable tracing** checkbox. 3. Click **Deploy Application** if you are enabling the feature for a new deployment, or **Apply Changes** if you are editing an existing application. Once you enable tracing, and redeploy your application, the Runtime Manager backend starts instrumenting traces for your application. ## See Also - [Downloading Test Apps from Exchange](https://docs.mulesoft.com/cloudhub-2/ch2-download-test-app) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) on Exchange - [Integrating with Your Logging System Using Log4j](https://docs.mulesoft.com/cloudhub-2/ch2-integrate-log-system) --- product: CloudHub 2.0 --- # Deploying Apps with Anypoint CLI > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use these commands for deploying and managing apps in Cloudhub 2.0.
CommandDescription

Deletes an application

Describes an application

Deploys an application to a specified target using an Exchange application and runs the specified runtime version

Downloads logs of an application from a specification to a specified directory

Lists all applications in an organization

Modifies a deployed application

Starts a stopped application

Stops running an application

Tails an application’s logs from a specification

## runtime-mgr:application:delete \> runtime-mgr:application:delete \[flags\] Deletes the running application specified in ``. To get this ID, run the `runtime-mgr application list` command. > [!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-2/#default-options). ## runtime-mgr:application:describe \> runtime-mgr:application:describe \[flags\] Displays information about the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command has the `--output` flag. 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-2/#default-options). ## runtime-mgr:application:deploy \> runtime-mgr:application:deploy \[flags\] Deploys the application specified in `` to the deployment target specified using the following options: > [!NOTE] To deploy applications using a connected app, the connected app must have CloudHub and > Runtime Manager permission accordingly.
ValueDescriptionExample

--artifactId

Artifact ID of the application retrieved from Exchange.

--artifactId mule-test-plugin

--deploymentTargetId

ID of the deployment target.
You can get this ID directly from Runtime Manager.

--deploymentTargetId cloudhub-ap-northeast-1

--instanceType

Instance type
Only UBP organizations can use this flag. Non-UBP organizations use the --replicaSize flag

--instanceType mule.micro

--name

Name of the application to deploy.

--name testcloudhub2app

--replicaSize

Size of replicas in Vcores.
Default: 0.1

--replicaSize 0.5

--runtimeVersion

Runtime version of the deployment target.

--runtimeVersion 4.4.0

--secureProperty

Sets an encrypted property.

--secureProperty secureTestProperty:true

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

--assetVersion

Version of the Exchange application to use.

--assetVersion 2.0.4

--[no-]clustered

Enables clustered nodes, which requires at least two replicas.
Default:.disabled

--no-clustered

--[no-]disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled

--disableAmLogForwarding

--[no-]forwardSslSession

Enables SSL session forwarding.
Default: disabled

--no-forwardSslSession

--groupId

Group ID of the asset to deploy.
Default: selected organization ID

--groupId org.mule.test

--[no-]lastMileSecurity

Enables Last Mile Security.
Default: disabled

--no-lastMileSecurity

--[no-]objectStoreV2

Enables Object Store v2.
Default: disabled

--no-objectStoreV2

--javaVersion

Set the name of the Java version to be used for the selected Mule version. Supported values are 8 and 17. If you do not specify a value, CloudHub API imposes the default value. The default Java version for Mule 4.6 and earlier versions is '8'. 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.

--javaVersion 8

--pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

--pathRewrite /api

--property

Replaces all existing properties with the specified property.
Format: name:value

--property testproperty:true

--propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

--propertiesFile /Users/mule/Documents/properties.txt

--publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

--releaseChannel

Set the name of the release channel to be used for the selected Mule version. Supported values are NONE, EDGE, and LTS. If you do not specify a value, CloudHub API imposes the default value. The default release channel is EDGE. 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.

--releaseChannel LTS

--replicas

Number of replicas. Must be above 0.
Default: 1

--replicas 2

--replicaSize

Size of replicas in Vcores.
Default: 0.1

--replicaSize 0.5

--scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

--scopeLoggingConfig testscope1:WARN,testscope2:DEBUG

--scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: one tuple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

--scopeLoggingConfigFile /Users/mule/Documents/cert.txt

--updateStrategy

Updates the strategy used.
Default: rolling

--updateStrategy recreate

> [!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:application:download-logs \> runtime-mgr:application:download-logs \[flags\] Downloads logs for the application specified in `` from the specification specified in `` to the selected directory. To get the ``, run the `runtime-mgr application list` command. To get the `` run the `runtime-mgr application describe` command. This command accepts the [default flags](https://docs.mulesoft.com/cloudhub-2/#default-options). ## runtime-mgr:application:list \> runtime-mgr:application:list \[flags\] Lists all applications in your organization. This command has the `--output` flag. 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-2/#default-options). ## runtime-mgr:application:modify \> runtime-mgr:application:modify \[flags\] Updates the settings of an existing application specified in ``. To get the ``, run the `runtime-mgr application list` command. In addition to the [default flags](https://docs.mulesoft.com/cloudhub-2/#default-options), this command accepts the following flags:
FlagDescriptionExample

--artifactId

ID of the application retrieved from Exchange.

--artifactId mule-maven-plugin

--assetVersion

Version of the Exchange application to use.

--assetVersion 2.0.4

--[no-]clustered

Enables clustered nodes, which requires at least two replicas.
Default: disabled

--no-clustered

--[no-]disableAmLogForwarding

Disables forwarding applications logs to Anypoint Monitoring.
Default: enabled

--disableAmLogForwarding

--[no-]forwardSslSession

Enables SSL session forwarding.
Default: disabled

--no-forwardSslSession

--groupId

Group ID of the asset to deploy.
Default: selected organization ID.

--groupId org.mule.testgroup

--instanceType

Instance type
Only UBP organizations can use this flag. Non-UBP organizations use the --replicaSize flag

--instanceType mule.nano

--[no-]lastMileSecurity

Enables Last Mile Security.
Default: disabled

--no-lastMileSecurity

--[no-]objectStoreV2

Enables object store v2.
Default: disabled

--no-objectStoreV2

--pathRewrite

Supplies the base path expected by the HTTP listener in your application.
Format: must begin with /

--pathRewrite /api

--property

Replaces all existing properties with the specified property.
Format: name:value

--property testproperty:true

--propertiesFile

Replaces all properties with values from a selected file.
Format: one or more lines in name: value style

--propertiesFile /Users/mule/Documents/properties.txt

--publicEndpoints

Supplies endpoints to reach via the public internet.
Format: separated by commas, no spaces

--replicas

Number of replicas. Must be above 0.
Default: 1

--replicas 2

--replicaSize

Size of replicas in Vcores.
Default: 0.1

--replicaSize 0.5

--runtimeVersion

Runtime version of the deployment target.

--runtimeVersion 4.4.0

--secureProperty

Sets an encripted property.

--secureProperty secureTestProperty:true

--scopeLoggingConfig

Defines scope logging.
Format: scopeName: logLevel, separated by commas, no spaces

--scopeLoggingConfig testscope1:WARN,testscope2:DEBUG

--scopeLoggingConfigFile

Uploads a file to define scope logging.
Format: 1 tuple per line, style: {scope: scopeName, logLevel: logLevelType} enclosed with {} () or []

--scopeLoggingConfigFile /Users/mule/Documents/cert.txt

--updateStrategy

Updates the strategy used.
Default: rolling

--updateStrategy recreate

> [!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:application:start \> runtime-mgr:application:start \[flags\] Starts running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts the [default flags](https://docs.mulesoft.com/cloudhub-2/#default-options). ## runtime-mgr:application:stop \> runtime-mgr:application:stop \[flags\] Stops running the application specified in ``. To get this ID, run the `runtime-mgr application list` command. This command accepts the [default flags](https://docs.mulesoft.com/cloudhub-2/#default-options). ## runtime-mgr:application:logs \> runtime-mgr:application:logs \[flags\] Tails application logs for the application specificied in `` from the specification specified in ``. To get the ``, run the `runtime-mgr application list` command. To get the ``, run the `runtime-mgr application describe` command. This command accepts the [default flags](https://docs.mulesoft.com/cloudhub-2/#default-options). --- product: CloudHub 2.0 --- # Deploying Apps with the Mule Maven Plugin > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!WARNING] Mule Maven plugin versions 3.0.0, 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.1.6, > 3.1.7, and 3.8.3 are deprecated. > [!NOTE] Where possible, we changed noninclusive terms to align with our company value of Equality. > We maintained certain terms to avoid any effect on customer implementations. In addition to using Anypoint Runtime Manager, to deploy applications to CloudHub 2.0, you can also deploy applications by using the Mule Maven plugin. To do so, you must meet certain prerequisites, and configure your CloudHub 2.0 deployment strategy in your project’s `pom.xml` file. ## Before You Begin - Ensure that the Mule Maven Plugin is added to your project See [Add the Mule Maven Plugin to a Mule Project](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept#add-mmp) for instructions. - The application is already published in Exchange See [Publish and Deploy Exchange Assets Using Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven). - The Mule Maven Facade API (v3) is added as a repository in the distribution management section of your project’s POM file. For example: ```xml Repository Corporate Repository https://maven.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION_ID/maven default ``` See [The Mule Maven Facade API documentation](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/exchange-maven-facade-api-http/) for more information. ## Configure the CloudHub 2.0 Deployment Strategy Inside the `plugin` element, add a configuration for your CloudHub 2.0 deployment, replacing the following placeholder values with your CloudHub 2.0 information: ```xml org.mule.tools.maven mule-maven-plugin 3.7.1 true https://anypoint.mulesoft.com MC ${environment} ${targetName} ${muleVersion} ${user} ${pass} ${appName} 1 1 ${publicUrl} true true ``` ## Deploy to CloudHub 2.0 From the command line in your project’s folder, package the application and execute the deploy goal: ```bash mvn clean deploy -DmuleDeploy ``` To deploy the artifact without rebuilding it, run: ```bash mvn mule:deploy ``` ### Exchange Snapshot Assets You can also deploy Exchange snapshot assets into CloudHub 2.0. By using `SNAPSHOT` version assets in Anypoint Exchange during the development and testing phase, you can avoid incrementing your application’s version number for small changes. After your `SNAPSHOT` version application has been overwritten in Anypoint Exchange, you can redeploy your `SNAPSHOT` version application to CloudHub 2.0 via the Mule Maven plugin to deploy the latest changes. To learn more about publishing snapshot assets to Anypoint Exchange, see [Asset Lifecycle State](https://docs.mulesoft.com/exchange/to-publish-assets-maven#asset-lifecycle-state). > [!NOTE] Each time you update your application’s snapshot, redeploy the application to refresh it > with the latest snapshot binaries. > > Because snapshot assets can change after deployment, avoid deploying them into your production > environment. ## Redeploy to CloudHub 2.0 To redeploy the application, run the same command as you did to deploy. CloudHub 2.0 rewrites the application you had deployed. ## Authentication Methods When you deploy applications using Mule Maven plugin, you can use different methods to provide your credentials to authenticate against the deployment platform. Depending on the authentication method you use, the parameters to set in the deployment configuration differ:
Authentication MethodDescriptionConfiguration Parameters

Username and password

Use a CloudHub 2.0 username and password to authenticate.

  • username

  • password

Server

Use credentials stored in a Maven server, configured inside the Maven settings.xml file.

  • server

Authorization Token

Use an authorization token to access the platform.
See Identity Management for a list of supported single sign-on (SSO) types.

  • authToken

Connected Apps

Use a Connected App to perform the authentication programmatically by communicating with Anypoint Platform.
Note that the Connected App credentials must have the Design Center Developer access scope.
See Connected Apps for Developers for instructions about creating Connected Apps.

  • connectedAppClientId

  • connectedAppClientSecret

  • connectedAppGrantType

For a detailed description of the configuration parameters, see the [CloudHub 2.0 Deployment Parameters Reference](#cloudhub2-deploy-reference). ## CloudHub 2.0 Deployment Parameters Reference
ParameterDescriptionRequired

cloudhub2Deployment

Top-Level Element

Yes

uri

Your Anypoint Platform URI.
If not set, defaults to https://anypoint.mulesoft.com.

No

muleVersion

The Mule runtime engine version to run in your CloudHub 2.0 instance.
Ensure that this value is equal to or higher than the earliest required Mule version of your application. By default, the latest available Mule version is selected.
Example values: 4.6.0 selects the last build where it defaults to Edge channel and Java 8. If you want to select a different LTS or Edge selection or Java version, specify the full Mule version name as in 4.6.0:1e-java17.
When using Mule Maven plugin versions 3.8.0 and 4.0.0 for deployments, the muleVersion property doesn’t allow you to specify releaseChannel and javaVersion. To specify these properties, upgrade the plugin to version 4.1.1 or later.
Because Mule runtime 4.4 Standard Support ends in October 2024, new Mule apps can be deployed on either Mule 4.6 LTS or Mule 4.8 Edge. As LTS channel isn’t supported for customers using a Mule Maven plugin version 4.1.0 or earlier, upgrade the plugin to version 4.1.1 or later.

No

releaseChannel

Set the name of the release channel used to select the Mule image. Supported values are NONE, EDGE, and LTS. By default, the value is set to EDGE. If the selected release channel doesn’t exist, an error occurs.

No

javaVersion

Set the Java version used in the deploy. Supported values are 8 and 17. By default, the value is set to 8. If the selected Java version doesn’t exist, an error occurs.

No

username

Your Anypoint Platform username

Only when using Anypoint Platform credentials to login.

password

Your Anypoint Platform password

Only when using Anypoint Platform credentials to login.

applicationName

The application name displayed in Runtime Manager after the app deploys.

Yes

scopeLoggingConfigurations

scopeLoggingConfiguration

scope

The package of the logging library to use.

logLevel

The log level. Accepted values: INFO, DEBUG, WARN, ERROR, FATAL.

Configuration example:

<scopeLoggingConfigurations>
  <scopeLoggingConfiguration>
    <scope>com.pkg.warning</scope>
    <logLevel>WARN</logLevel>
  </scopeLoggingConfiguration>
  <scopeLoggingConfiguration>
    <scope>com.pkg.debug</scope>
    <logLevel>DEBUG</logLevel>
  </scopeLoggingConfiguration>
</scopeLoggingConfigurations>

No

target

The CloudHub 2.0 target name to deploy the app to.
Specify either a shared space or a private space available in your Deployment Target values in CloudHub 2.0. See Features of CloudHub 2.0 for a detailed description on shared and private spaces. Use a target name value from the list of regions. For example, Cloudhub-US-East-1.

Yes

provider

Provider MC (MuleSoft Control Plane) indicates that the deployment is managed through Anypoint Runtime Manager. Set to MC for CloudHub 2.0.

Yes

environment

Target Anypoint Platform environment.
This value must match an environment configured in your Anypoint Platform account, as shown here:

<environment>Sandbox</environment>

Yes

replicas

Specifies the number of replicas, or instances, of the Mule application to deploy.

Only when autoscaling is set to false.

vCores

The size of each replica specified in vCores. Accepted values: 0.1, 0.2, 0.5, 1, 1.5, 2, 2.5, 3, 3.5, 4. See CloudHub 2.0 Replicas for a detailed description of available vCore sizes and their assigned hardware resources.
This parameter cannot be used if you configure instanceType.

Yes (Only when instanceType isn’t configured.)

businessGroup

The Business group path of the deployment
Specify the full hierarchical path from the parent organization to the target Business group, for example:

<businessGroup>ParentOrg\SubOrg1\myBusinessGroup</businessGroup>

This value is omitted if businessGroupId is set. If businessGroup and businessGroupId are not set, the value defaults to the main business group of the user.

No

businessGroupId

The Business group ID of the deployment
Instead of specifying the Business group path, you can specify the Business group ID to deploy your application. If businessGroupId and businessGroup are not set, the value defaults to the main business group of the user.
The Business group ID is a mandatory parameter when you have access only to a specific Business group but not to the parent organization.
This parameter is available in plugin version 3.2.7 and later.

No

deploymentTimeout

The allowed elapsed time, in milliseconds, between the start of the deployment process and the confirmation that the artifact has been deployed

The default value is 600000.

No

server

Maven server with Anypoint Platform credentials
This is only needed if you want to use your credentials stored in your Maven settings.xml file. This is not the Mule server name.

No

properties

Top-Level element
If you need to set properties for the Mule application you are deploying, you can use the <properties> top-level element:

<properties>
  <key>value</key>
</properties>

For example:

<properties>
  <http.port>8081</http.port>
</properties>

If you redeploy the application and neither the properties nor the secureProperties element is configured in the deployment POM file, CloudHub 2.0 preserves the existing properties configured in your CloudHub 2.0 environment. If either element is present, CloudHub 2.0 deploys the application using only the properties and secure properties defined in the POM. It doesn’t merge them with values configured in Runtime Manager. Any existing properties that aren’t included in the deployment configuration are removed. To keep existing values, omit both elements, or send the full set of properties and secure properties on every redeploy.

No

propertiesFile

Top-level element
Specifies a file that contains properties for the Mule application being deployed. Use this parameter as an alternative to defining properties inline with <properties>. The file must use the Java properties format, with one key=value pair per line.

No

secureProperties

Top-Level element
Use the secureProperties top-level element to set properties for the Mule application and instruct CloudHub 2.0 to encrypt the values before storing them:

<secureProperties>
  <key>value</key>
</secureProperties>

For example:

<secureProperties>
  <http.port>8081</http.port>
</secureProperties>

If you redeploy the application and neither the secureProperties nor the properties element is configured in the deployment POM file, CloudHub 2.0 preserves the existing secure properties configured in your CloudHub 2.0 environment. If either element is present, CloudHub 2.0 deploys the application using only the properties and secure properties defined in the POM. It doesn’t merge them with values configured in Runtime Manager. Any existing secure properties that aren’t included in the deployment configuration are removed. To keep existing values, omit both elements, or send the full set of properties and secure properties on every redeploy.

No

skip

When set to true, skips the plugin deployment goal.
Its default value is false.

No

skipDeploymentVerification

When set to true, skips the status verification of your deployed app.
Its default value is false.

No

authToken

Specifies the authorization token to access the platform. You can use this authentication method instead of setting username and password.
See Identity Management for a list of supported single sign-on (SSO) types.

Only when using an Authorization token to login.

connectedAppClientId

Specifies the Connected App clientID value.

Only when using Connected Apps credentials to login.

connectedAppClientSecret

Specifies the Connected App secret key.

Only when using Connected Apps credentials to login.

connectedAppGrantType

Specifies the only supported connection type: client_credentials.

Only when using Connected Apps credentials to login.

deploymentSettings

Any of the parameters documented in deploymentSettings Reference.

No

integrations

services

objectStoreV2

enabled

When set to true, instructs the deployment to use Object Store v2.

Configuration example:

<integrations>
  <services>
    <objectStoreV2>
      <enabled>true</enabled>
    </objectStoreV2>
  </services>
</integrations>

No

### deploymentSettings Parameters Reference
ParameterDescription

enforceDeployingReplicasAcrossNodes

Enforces the deployment of replicas across different nodes. The default value is false.
For high availability, set this value to true.

Configuration example:

<deploymentSettings>
  <enforceDeployingReplicasAcrossNodes>false</enforceDeployingReplicasAcrossNodes>
</deploymentSettings>

updateStrategy

Accepted valuesDescription

rolling

Maintains availability by updating replicas incrementally. Requires one additional replica’s worth of resources to succeed.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is one less than the total number of nodes.

recreate

Terminates replicas before re-deployment. Re-deployment is quicker than rolling and doesn’t require additional resources.
If enforceDeployingReplicasAcrossNodes is enabled, the maximum number of replicas you can configure is equal to the number of nodes.

The default value is rolling.

Configuration example:

<deploymentSettings>
  <updateStrategy>recreate</updateStrategy>
</deploymentSettings>

clustered

Enables clustering across two or more replicas of the application. The default value is false.

Configuration example:

<deploymentSettings>
    <clustered>true</clustered>
</deploymentSettings>

http

inbound

publicUrl

URL of the deployed application. You can add multiple comma-separated values.

endpoint

Defines application endpoints by specifying the url, pathRewrite, and access attributes. Accepted values for access are internal and external.

pathRewrite

Supplies the base path expected by the HTTP listener in your application. This value must begin with /. This parameter is used only for applications that are deployed to private space.

lastMileSecurity

Enable Last-Mile security to perform TLS termination and decryption for forwarded HTTPS connections directly within the Mule application. This requires the Mule application to include an SSL certificate and consumes additional CPU resources. The default value is false.

forwardSslSession

Enables SSL forwarding during a session. The default value is false.

Mule Maven Plugin supports both publicUrl and endpoint for configuring application endpoints. Configure either publicUrl or endpoints, but not both in the same deployment configuration.

Configuration example:

<deploymentSettings>
  <http>
    <inbound>
      <publicUrl>https://myapp.anypoint.com</publicUrl>
      <pathRewrite>/api</pathRewrite>
      <lastMileSecurity>true</lastMileSecurity>
      <forwardSslSession>true</forwardSslSession>
    </inbound>
  </http>
</deploymentSettings>

Example using endpoint:

<deploymentSettings>
  <http>
    <inbound>
      <endpoints>
        <endpoint>
          <url>https://test1.com/ch2testapp1</url>
          <pathRewrite>/</pathRewrite>
          <access>external</access>
        </endpoint>
      </endpoints>
    </inbound>
  </http>
</deploymentSettings>

generateDefaultPublicUrl

When set to true, CloudHub 2.0 generates a public URL for the deployed application.
This parameter is used only for applications that are deployed to private space. Applications that are deployed to shared space always get a generated public URL.

disableAmLogForwarding

Disables the application-level log forwarding to Anypoint Monitoring. The default value is false.

tracingEnabled

Exposes tracing information in OpenTelemetry standard from Mule runtime into all APM solutions. See Enable Trace Data Collection.

autoscaling

Provides CPU based horizontal autoscaling configuration for deployment and redeployment operations. If autoscaling is disabled and the fields minReplicas and maxReplicas are provided, they must match the value of the target.replicas field. See Enable Trace Data Collection. Configuration example:

<deploymentSettings>
  <autoscaling>
    <enabled>true</enabled>
    <minReplicas>1</minReplicas>
    <maxReplicas>2</maxReplicas>
  </autoscaling>
</deploymentSettings>

instanceType

Specifies the capacity of the replica for application deployment. This flag is available only for organizations using a usage-based pricing (UBP) package. Non-UBP organizations use the vCores parameter instead. See Anypoint Platform Pricing.

## Encrypt Credentials To use encrypted credentials when deploying, you need to set up your Maven master encrypted password and your `settings-security.xml` file. 1. Create a master password for your Maven configuration. mvn --encrypt-master-password Maven returns your master password encrypted: {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} 2. Create a `settings-security.xml` file in your ~/.m2 repository and add your encrypted master password: ```xml {l9vZ2uM5SdgHy+H12z4pX7LEOZn3Kbnqmt3kIquLjnQ=} ``` 3. Encrypt your Anypoint platform password: mvn --encrypt-password Maven returns your Anypoint platform password encrypted: {HTWFGH5BG9QmvJ1B=} 4. Add your encrypted Anypoint Platform password to your `settings.xml` file in the section: ```xml ... ... my.anypoint.credentials my.anypoint.username {HTWFGH5BG9QmvJ1B=} ... ... ``` 5. In your configuration deployment, reference the credentials injecting the server ID configured in your `settings.xml` file: ```xml ... ... ... my.anypoint.credentials ... ... ... ``` > [!NOTE] Make sure that the username and password aren’t set in the deployment configuration, > or they will overwrite the defined server ID. ## See Also - [Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) --- product: CloudHub 2.0 --- # Downloading Test Apps from Exchange > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you don’t have a Mule app to test with, you can download an example app from Anypoint Exchange. > [!NOTE] You must be logged into your Anypoint Platform account to see the example assets on > Exchange. 1. From Anypoint Platform, select **Exchange**. 2. From the **All assets** list, select **Provided by MuleSoft**. 3. From the **All types** menu, select **Examples**. 4. Click an app to download, for example, **Hello World**. CloudHub 2.0 supports Mule runtime engine versions 4.3.x and later. 5. Click **Download**: ![Download button in Exchange](/mulesoft/current/en-us/cloudhub-2/_images/exchange-app-download.png) Exchange downloads the app JAR file to your local system. ## See Also - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) on Exchange --- product: CloudHub 2.0 --- # Extending Your Network to Anypoint Platform with Private Spaces > For the full documentation index, see: https://docs.mulesoft.com/llms.txt ## Before You Begin - [Assign permissions](https://docs.mulesoft.com/cloudhub-2/ps-assign-permissions). - [Gather required setup information](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info). ## Workflow 1. [Create the private space](https://docs.mulesoft.com/cloudhub-2/ps-create-configure). 2. [Create the private network](https://docs.mulesoft.com/cloudhub-2/ps-create-configure#create-private-network). 1. [Test the private network by deploying an app](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space). 2. [Configure internal DNS servers, if necessary](https://docs.mulesoft.com/cloudhub-2/ps-create-configure#resolve-private-domains). 3. [Create a connection to an external network](https://docs.mulesoft.com/cloudhub-2/ps-create-configure#create-connection-to-external-network). - [Create a VPN connection](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-vpn). - [Connect to a transit gateway](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-tgw). 4. [Customize the private space](https://docs.mulesoft.com/cloudhub-2/ps-configure): 1. [Configure domains and certificates (TLS context) for the private space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains). 2. [Configure firewall rules to manage traffic to the private space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules). 3. [Associate environments and business groups with the private space](https://docs.mulesoft.com/cloudhub-2/ps-config-env). 4. [Configure advanced settings](https://docs.mulesoft.com/cloudhub-2/ps-config-advanced), including HTTP request handling and ingress load balancer log levels. ## See Also - [Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure) - [Configuring Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-configure) --- product: CloudHub 2.0 --- # Features of CloudHub 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt CloudHub 2.0 includes many of the features from CloudHub 1.0 and Anypoint Runtime Fabric on Self-Managed Kubernetes. ## CloudHub 2.0 Feature Comparison This table compares the features and support for CloudHub 2.0, CloudHub 1.0, and Anypoint Runtime Fabric on Self-Managed Kubernetes.
Table 1. Feature Comparison
CapabilityCloudHub 2.0CloudHub 1.0Runtime Fabric

VM Management

Provisioning/scaling

Fully managed

Fully managed

Self-managed

OS patching

Fully managed

Fully managed

Self-managed

VM self-healing

Fully managed

Fully managed

Supported (managed nodes)

Persistent VM Queues

Not supported

Supported

Not supported

Load Balancing and Ingress

Default endpoints

Fully managed

Fully managed

Not supported

URL rewriting

Supported

(app-level)

Supported

(DLB)

Supported

Provisioning/updating

Fully-managed

Fully-managed

Supported

Certificate management

Supported

Supported

Supported

Multiple truststores

(client certificates for mutual TLS)

Supported

Not supported

Supported

Custom endpoints

Supported

Supported

Supported

Multiple custom endpoints

per app

Supported

Partially supported

Supported

TLS 1.0

Not supported

Supported

Supported

TLS 1.1

Not supported

Supported

Supported

TLS 1.2

Supported

Supported

Supported

TLS 1.3

Supported

Supported

Supported

Private endpoints

Supported

Supported

Supported

Load balancer logs

Supported

(download)

Not supported

Supported

Ingress logs

Supported

Not supported

Not supported

Network

Deployment regions

12 geographical regions

12 geographical regions

Supported

(manual)

Virtual Private Cloud

Fully managed

(private space)

Fully managed (Anypoint VPC)

Supported

(manual)

Virtual Private Network

Fully managed

(private space)

Fully managed

(Anypoint VPN)

Supported

(manual)

AWS Transit Gateway

Supported

(private space)

Supported

Supported

Direct Connect

Not supported

Supported

(not self-serve)

Supported

VPC Peering

Not supported

Supported

(not self-serve)

Supported

DNS

Fully managed

Fully managed

Supported

Inbound firewall rules

Supported

Supported

Supported

Outbound firewall rules

Supported

(private space)

Not supported

Supported

Static IP addresses

Supported

(private space)

Supported

(per app)

Supported

App Capabilities

Schedule management

Supported

Supported

Not supported

TLS certificates

for API Gateway deployments

Supported

Supported

Not supported

DataGraph

Not supported

Supported

Not supported

Mule patch updates

Automated

Automated

Requires redeployment

Cluster

management

Fully managed

Fully managed

Self-managed

Object store

Fully managed

(Object Store v2)

Fully managed

(Object Store v2)

Supported

High availability

across AZs

Fully managed

(with two or more replicas)

Fully managed

(with two or more workers)

Supported

(with two or more replicas)

Secure properties

Supported

Supported

Partially supported

Log tailing

Fully managed

Fully managed

Supported outside Anypoint Platform

Continuous integration deployments

Supported

(via API and Maven plugin, Anypoint CLI)

Supported

(via API, Maven plugin, Anypoint CLI)

Supported

(via API and Maven plugin)

Built-in notifications

Not supported

Supported

Supported

Custom notifications

(CloudHub Connector)

Not supported

Supported

Not supported

Log forwarding

Manual

Supported

(per app)

Manual

Message broker

Fully managed

(Anypoint MQ)

Fully managed

(Anypoint MQ)

Fully managed

(Anypoint MQ)

App monitoring

Fully managed

(Anypoint Monitoring)

Fully managed

(Anypoint Monitoring)

Fully managed

(Anypoint Monitoring)

Application isolation

Supported

Supported

Supported

Auto-recovery

Fully managed

Fully managed

Supported

Mule clustering

Supported

Not supported

Supported

Autoscaling

Supported

Supported

Supported

Support

VM management

MuleSoft

MuleSoft

Infrastructure provider/

public cloud

Network

MuleSoft

MuleSoft

Infrastructure provider/

public cloud

App capabilities

MuleSoft

MuleSoft

MuleSoft/

infrastructure provider/

public cloud

Load balancing and ingress

MuleSoft

MuleSoft

Self-managed

Backup and restore

Fully managed

Fully managed

Self-managed

Fully managed MuleSoft provides and manages the feature. Self-managed MuleSoft provides the feature, but the customer manages the feature. Supported MuleSoft does not provide the feature, but it is available on supported partner platforms. The feature is managed by the vendor, platform, or customer. Not supported MuleSoft does not provide the feature, and the customer cannot configure it. --- product: CloudHub 2.0 --- # Gathering Required Setup Information > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the following sections to gather the information you’ll need to set up your private space. For information about private spaces, see [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about). You might need to collaborate with your network administrator if you don’t have access to this information. In this case, share this setup checklist with them. ## Organization Entitlements and CloudHub 2.0 Based on your organization’s entitlements, Anypoint Platform enforces limits for vCore consumption, network connections (VPNs and transit gateway attachments), and private spaces. CloudHub 1.0 and CloudHub 2.0 share entitlement quotas. If your organization uses both CloudHub 1.0 and CloudHub 2.0, you must budget your consumption with both in mind. For example, if your organization is entitled to four network connections, it can support one transit gateway connection in CloudHub 1.0, one transit gateway connection in CloudHub 2.0, and two VPNs (or some combination therein). In other words, if the network connection entitlement is four, you do not get four network connections for each version of CloudHub. To ensure your organization has sufficient entitlements to meet your needs, you must understand how resources map to entitlements: - Private cloud quotas include both VPCs (virtual private clouds) in CloudHub 1.0 and private spaces in CloudHub 2.0. - Network connection quotas include VPNs and transit gateway attachments in both CloudHub 1.0 and CloudHub 2.0. - vCore usage quotas apply to apps deployed in CloudHub 1.0 and CloudHub 2.0. Anypoint Platform prevents you from consuming resources that exceed your organization’s limits. Anypoint Platform also prevents you from modifying existing resources if you are exceeding that resource’s limit. Note that failed application deployments and unsuccessful private space creation in CloudHub 2.0 still count toward limits. ## Information Required to Set Up a Private Space The following list summarizes the information required to set up a private space. For details about each requirement, see the sections that follow. **Private Network Setup** - [Private space name](#private-space-name) - [Private network region](#private-network-region) - [CIDR block](#cidr-block) - [Internal DNS servers](#internal-dns-server) (optional) - [IP addresses](#server-ip-addresses) - [Domains](#domains) **VPN Connection Type** - [VPN name](#vpn-name) - [Remote IP](#remote-ip-address) - **[Dynamic Routing Type](#dynamic-vpn-routing)** - [Local ASN](#local-asn) - [Remote ASN](#remote-asn) - **[Static Routing Type](#static-vpn-routing)** - [Local ASN](#local-asn) (_first VPN only_) - [Static IP prefixes](#static-ip-prefixes) - **[Advanced Tunnel Configuration](#advanced-tunnel-configuration)** (_optional_) - Tunnel 1 - [Inside IP CIDRs](#inside-ip-cidrs) - [Pre-shared keys](#preshared-keys) - Tunnel 2 - [Inside IP CIDRs](#inside-ip-cidrs) - [Pre-shared keys](#preshared-keys) - [Automatic Tunnel Initiation](#auto-tunnel-initiation) (_first VPN only_) - [**Supported Gateway Devices**](#supported-gateway-devices) - Device vendor - Device platform - Device software **Redundant VPN Connection** (_optional_) - **[Dynamic Routing Type](#dynamic-vpn-routing)** - [Remote IP](#remote-ip-address) - [Remote ASN](#remote-asn) - **[Static Routing Type](#static-vpn-routing)** - [Static IP prefixes](#static-ip-prefixes) - **[Advanced Tunnel Configuration](#advanced-tunnel-configuration)** (_optional_) - Tunnel 1 - [Inside IP CIDRs](#inside-ip-cidrs) - [Pre-shared keys](#preshared-keys) - Tunnel 2 - [Inside IP CIDRs](#inside-ip-cidrs) - [Pre-shared keys](#preshared-keys) - [**Supported Gateway Devices**](#supported-gateway-devices) - Device vendor - Device platform - Device software **Transit Gateway Attachment Connection Type** - [Transit gateway name](#transit-gateway-name) - [Transit gateway region](#transit-gateway-region) - [Transit gateway routing](#transit-gateway-routing) - [MuleSoft AWS account ID](#mulesoft-aws-account-id) - [Resource share ID](#resource-share-id-owner) - [Resource share owner](#resource-share-id-owner) ## Private Network Requirements - [Private Space Name](#private-space-name) - [Private Network Region](#private-network-region) - [CIDR Block](#cidr-block) - [Connection Type](#connection-type) - [Internal DNS Servers (Optional)](#internal-dns-server) ### Private Space Name Private space names can contain between 1 and 36 alphanumeric characters (a-z, A-Z, 0-9) and hyphens (-). Runtime Manager supports Unicode characters in private space names. The private space name appears in the list when you select a deployment target for your apps. You cannot rename a private space. ### Private Network Region The _region_ is the Amazon region to deploy your apps to, such as `usa-e1`. The complete list of supported regions is: US East (Northern Virginia) US East (Ohio) US West (Northern California) US West (Oregon) Canada (Central) South America (Sao Paulo) Europe (Ireland) Europe (Frankfurt) Europe (London) Asia Pacific (Singapore) Asia Pacific (Sydney) Asia Pacific (Tokyo) #### Canada (Central) Private Space Subnet Availability Only the MuleSoft Government Cloud control plane supports three subnets in Canada (Central) for increased high availability. The Commercial control plane doesn’t support three subnets in this region. > [!IMPORTANT] Control plane discrepancy: Subnet count for a private space in Canada (Central) > depends on your control plane. MuleSoft Government Cloud supports three subnets. The Commercial > control plane provisions private spaces with only two subnets. > > Existing MuleSoft Government Cloud private spaces: Private spaces created in Canada (Central) > prior to three-subnet support don’t receive the update automatically. To get the three-subnet > architecture, recreate your private space. Recreating a private space causes downtime. Redeploy > applications and reconfigure VPN, transit gateway, DNS, and other connections in the new private > space. Plan the migration during a maintenance window. ### CIDR Block The _CIDR block_ is the range of IPv4 addresses, in CIDR (Classless Inter-Domain Routing) notation that the apps deployed in your private space use. The CIDR block defines the size of the private space. For example, to grant your private network 256 IP addresses between `10.111.0.0` and `10.111.0.255`, set the CIDR block to `10.111.0.0/24`. When you create a private space, you must specify the CIDR block. You can’t resize or change the CIDR block after you create the private space. For this reason, ensure that you correctly anticipate your requirements before configuring this parameter. We recommend a `/22` block. Because some addresses are reserved for fault tolerance, infrastructure, and zero-downtime, the allowed block size that you can assign for your Anypoint VPC is between `/16` and `/24`. Note that the size of the block does not limit the number of IPs that your apps can use. When specifying CIDR blocks, ensure that the CIDR blocks: - Are from a private IP space. - Don’t overlap with any other CIDR blocks assigned to your other private spaces. - Don’t overlap with any CIDR blocks in use in your corporate network. MuleSoft recommends using subnets from standard RFC 1918 addresses, such as `10.0.0.0/8`, `172.16.0.0/12`, and `192.168.0.0/16`. #### CIDR Block Sizing CIDR block sizing depends on several factors related to how IP addresses are allocated when you deploy applications: - Number of applications in a private space - [Replica size](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#cloudhub-2-replicas) assigned to each application - [Number of replicas](https://docs.mulesoft.com/cloudhub-2/ch2-clustering#replica-scale-out) in each application, based on horizontal scaling, high availability, and fault tolerance configuration - [Rolling deployment configuration](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps#rolling-update-vs-recreate-deployment-model) - [Auto-upgrades](https://docs.mulesoft.com/cloudhub-2/ch2-patch-updates) that update multiple applications simultaneously - Platform internal operations or services that require IP headroom Use this reference table to select the appropriate CIDR block size for your private space:
CIDR Block SizeMaximum vCoresMaximum Applications

/24

Less than 100

Less than 100

/23

Less than 300

Less than 200

/22

Less than 600

Less than 500

/21

Less than 1200

Less than 1000

/20

Less than 3000

Less than 2000

> [!NOTE] These reference sizes are subject to change as the platform continues to evolve. Exceeding > the recommended thresholds for your CIDR block size can cause application deployments to fail with > errors indicating that replicas are unschedulable due to insufficient available IP addresses. #### Unusable Private Space Network CIDR You cannot use the following list of CIDR blocks: 100.64.0.0/10 198.19.0.0/16 224.0.0.0/4 169.254.0.0/16 127.0.0.0/8 172.17.0.0/16 0.0.0.0/8 #### Reserved Corporate CIDR (Optional) Optionally, when you create your private space and configure your private network, you can configure _reserved CIDR blocks_ that correspond with your reserved corporate network CIDRs. When you reserve CIDRs in a private network configuration, Anypoint Platform does not use the blocks you specify when associating IP addresses with your private space. This prevents overlap between your corporate network CIDRs and Anypoint Platform infrastructure. There are two strategies for reserving CIDRs during private space creation: 1. Provide all reserved corporate CIDRs Specify all CIDR blocks you plan to use within your corporate network. CloudHub 2.0 automatically checks for conflicts with the MuleSoft infrastructure CIDR pool and chooses options that do not overlap. This approach simplifies setup but requires providing a potentially larger list. 2. Manually identify overlapping corporate CIDRs Manually review the MuleSoft infrastructure CIDR pool. Then, specify only the CIDRs from your corporate network CIDR list that conflict with options in the MuleSoft infrastructure CIDR pool. This approach minimizes the list you provide, but you must check for overlap beforehand. Note that the MuleSoft infrastructure CIDR pool is subject to change. #### MuleSoft Infrastructure CIDR Pool Anypoint Platform has a list of CIDRs as an internal CIDR pool for provisioning private space networks. The MuleSoft infrastructure CIDR pool is subject to change. You can configure some of the following as reserved CIDR blocks, but you cannot use them as private space network CIDRs: 100.64.0.0/16 100.66.0.0/16 100.67.0.0/16 100.68.0.0/16 ### Internal DNS Servers (Optional) If your corporate network uses internal DNS servers to resolve requests to custom domains, you must configure those servers to enable apps deployed to a private space to access internal resources that are not reachable from the public internet. To configure internal DNS servers, specify the IP addresses for your internal domain servers and the domains that you want to be resolved by internal DNS. The private space resolves the domains using the specified DNS server, enabling you to use internal host names in your private network as long as your applications use the FQDN to request back-end resources. #### Server IP Addresses The _Server IP addresses_ identify the internal DNS servers that resolve requests to custom domains. To provide redundancy, you can configure multiple internal DNS servers. When configuring the IP addresses for the DNS servers, keep the following in mind: - You configure DNS servers within a private space, so the server IP addresses you configure must be reachable from the private space. If the server isn’t reachable, DNS resolution fails. - If you configure multiple servers, the private space queries any DNS server in the list for the specified domains at any time, in any order. - All name servers must present the same DNS record. - After the private space receives a valid response from any configured name server, it doesn’t retry the request. If one of the name servers doesn’t have a record for the domain, it returns the response `NXDOMAIN` (non-existent domain). Because this response is valid, the private space doesn’t send the query to the other servers. #### Domains _Domains_ identify the internal domains that must be accessible from the private space. The configured internal DNS servers resolve the specified domains, and the external DNS server resolves all other domains. To configure an internal domain, specify the IP address. The following internal private DNS domains are not supported: - `cloudhub.io` - `mulesoft.com` - `anypointdns.net` - `amazon.com` - `amazonaws.com` - `compute.internal` - `io` - `com` - `net` - `internal` - `local` - `domain.com` > [!NOTE] These restrictions also apply to the respective subdomains. You can’t add MuleSoft domains or public domains as private space internal DNS. As a workaround, create CNAME records on your own DNS servers to redirect a permitted custom domain to the restricted domain you want to add. See [Cannot add certain domains to CloudHub VPC Internal DNS](https://help.salesforce.com/s/articleView?id=001119691&type=1). > [!NOTE] Each domain can contain up to 253 characters. When configured with 10 IP addresses (IPs) > per entry, the maximum supported capacity is 1940 entries. The system supports more than 1940 > entries if you use shorter domain names or fewer IPs in entries. ### Connection Type - [Virtual Private Network (VPN)](#vpn-requirements) - [Transit Gateway Attachment](#tgw-requirements) ## VPN Requirements Review the recommendations and limitations in [Anypoint Virtual Private Network](https://docs.mulesoft.com/cloudhub-2/ps-vpn-about). - [VPN Name](#vpn-name) - [Remote IP Address](#remote-ip-address) - [Dynamic VPN Routing (BGP)](#dynamic-vpn-routing) - [Static VPN Routing](#static-vpn-routing) - [Local ASN](#local-asn) - [Remote ASN](#remote-asn) (dynamic routing only) - [Static IP Prefixes](#static-ip-prefixes) (static routing only) - [Inside IP CIDRs](#inside-ip-cidrs) (advanced tunnel configuration only) - [Pre-shared Keys](#preshared-keys) (advanced tunnel configuration only) - [Automatic Tunnel Initiation](#auto-tunnel-initiation) (advanced tunnel configuration only) - [Supported Gateway Devices](#supported-gateway-devices) > [!NOTE] Before configuring routing, consolidate networks to the fewest number possible. A maximum > of 95 route table entries is allowed per private space, regardless of the number of connections. ### VPN Name The _VPN name_ is the name of the VPN connection. ### Remote IP Address The _remote IP address_ is the public (single, static) IP address of your VPN endpoint. ### Dynamic VPN Routing (BGP) For dynamic routing, your device uses Border Gateway Protocol (BGP) to advertise routes to Anypoint VPN. If your device supports BGP, you can select dynamic routing; otherwise, select static routing. To create a dynamic VPN connection, in addition to the static VPN connection requirements, your VPN device 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 Diffie-Hellman Phase 2 groups 2, 5, 14-24. ### Static VPN Routing If your gateway device doesn’t support BGP, you must use static routing. You might also want to use static routing if you want to provide your own secrets. Static routing requires you to specify the routes (subnets) in your network that are accessible through Anypoint VPN. 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 - Use any combination of IPsec settings that Anypoint Platform supports - Fragment IP packets before encryption You must fragment packets that are too large to transmit. Your gateway device must be able to fragment packets before encapsulation. - Use one Security Association (SA) pair per tunnel Anypoint VPN supports one unique SA pair (one inbound and one outbound connection) per tunnel. 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 Anypoint Platform 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 private space through one tunnel and traffic returns from the private space through the other tunnel. The Anypoint Platform 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 Diffie-Hellman Phase 2 groups 2, 5, 14-24. ### Local ASN The _local ASN_ (Autonomous System Number) specifies a private ASN (`64512–65534`) to assign to the Anypoint Platform side of the VPN. Use a private ASN that is not already assigned to your network. The default value is `64512`. > [!NOTE] You configure the local ASN for both static and dynamic routing. Although the local ASN isn’t used for static routing, you must specify this value when you create the first VPN because it is required for any future VPN connections using BGP for this private space. For subsequent VPNs that you create in the private space, the **Local ASN** option is not available for static routing. To change the local ASN after creating the VPN, you must delete all existing connections first. ### Remote ASN The _remote ASN_ specifies a private ASN that corresponds to your backend. > [!NOTE] You configure the remote ASN only for dynamic routing. Use either 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`. ### Static IP Prefixes The _static IP prefixes_ are IP prefixes to advertise to your private network in Anypoint Platform, in CIDR notation. > [!NOTE] You configure the static IP prefixes only for static routing. A maximum of 95 route table entries is allowed per private network, regardless of the number of VPN connections. To avoid exceeding the limit, consolidate networks to the fewest number possible. ### Advanced Tunnel Configuration (Optional) You can customize the tunnel configuration if you want to specify custom values for inside IP CIDRs and pre-shared keys, or if you want to disable automatic tunnel initiation. Any values that you don’t specify are set to the default. #### Inside IP CIDRs The _inside IP CIDRs_ is the IP address range for the internal address of the VPN tunnel. > [!NOTE] You specify the inside IP CIDRs only for custom tunnel configuration. For automatic tunnel > configuration, these values are auto-generated. 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 private network connections. You cannot use the following list of 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 #### Pre-shared Keys A _pre-shared key_ (PSK) is a shared secret that was previously shared between two ends of a connection for the VPN tunnels. > [!NOTE] You specify the PSK only for custom tunnel configuration. For automatic tunnel > configuration, these values are auto-generated. For static connections, your VPN endpoint uses pre-shared keys (PSKs) to establish IKE Security Associations. For each tunnel, enter a value of between 8-64 characters that does not begin with zero (0). Use only alphanumeric characters, periods (.), and underscores (\_). #### Automatic Tunnel Initiation By default, VPN tunnels are initiated automatically. If you deselect this option, you must generate traffic from the customer gateway to establish VPN tunnels. This setting applies to all VPNs in the connection and the option isn’t available for subsequent redundant VPNs. > [!NOTE] Modifying the tunnel initiation after VPN creation causes all VPNs in this connection to > restart. ### Supported Gateway Devices A _gateway device_ is a physical or software appliance on your organization’s side of the VPN connection. Your network administrator must configure the device to work with the Anypoint VPN connection. The following gateway network devices are known to work with Anypoint VPN. If your device does not appear in the list of tested devices, check the requirements to verify that your device is suitable for use with Anypoint VPN. See [Dynamic VPN Routing (BGP)](#dynamic-vpn-routing) and [Static VPN Routing](#static-vpn-routing).
Table 1. Supported Gateway Devices
Device VendorDevice PlatformDevice Software

Check Point

Security Gateway

R77.10 or later

Cisco

ASA

ASA 8.2 or later

IOS

Cisco IOS 12.4 or later

Dell

SonicWALL

SonicOS 5.9 or later

Fortinet

Fortigate 40+ Series

FortiOS 4.0 or later

Juniper

J-Series Service Router

JunOS 9.5 or later

SRX-Series Services Gateway

JunOS 11.0 or later

SSG

ScreenOS 6.1 or 6.2 or later

ISG

ScreenOS 6.1 or 6.2 or later

Netgate

pfSense

OS 2.2.5 or later

Palo Alto Networks

PANOS 4.1.2 or later

Yamaha

RT107e

RTX1200

RTX1210

RTX1500

RTX3000

SRT100

Microsoft

Windows Server

2008 R2 or later

2012 R2 or later

Zyxel

Zywall Series

4.20 or later for statically routed Anypoint VPN connections

4.30 or later for dynamically routed Anypoint VPN connections

## Redundant VPN The default value for **Remote ASN** is inherited from the first VPN. You can change this value. ## Transit Gateway Attachment Requirements - [Transit Gateway Name](#transit-gateway-name) - [Transit Gateway Region](#transit-gateway-region) - [Transit Gateway Routing](#transit-gateway-routing) > [!NOTE] Before configuring routing, consolidate networks to the fewest number possible. A maximum > of 95 route table entries is allowed per private space, regardless of the number of connections. ### Before You Begin 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. - Purchase a Private Space offering with AWS Transit Gateway entitlements. 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. - Sign in to an Anypoint Platform account with either the CloudHub 2.0 Network Administrator or the CloudHub 2.0 Network Viewer user permission. See [Grant Permissions and Roles to Users](https://docs.mulesoft.com/access-management/users#grant-user-permissions). - Identify the subnets in your network (in CIDR notation) that you want to make accessible through the transit gateway. ### Transit Gateway Name Transit gateway attachment names can contain up to 255 alphanumeric characters (a-z, A-Z, 0-9) and hyphens (-). Runtime Manager supports Unicode characters in private space names. Use the same name for your transit gateway in AWS. You can change this name later. ### Transit Gateway Region The region corresponds to the location of your AWS Transit Gateway. Your private space and AWS Transit Gateway must be in the same region. ### Transit Gateway Routing A maximum of 95 route table entries is permitted per VPC, regardless of the number of transit gateway attachments. Consolidate networks to the fewest number possible to avoid exceeding the limit. ### MuleSoft AWS Account ID The MuleSoft AWS account ID varies depending on your control plane, for example, US Cloud or EU Cloud, and appears in **Add transit gateway** page when you select to create the transit gateway connection. When you create a resource share in AWS, you specify this ID to allow Anypoint Platform to access the resource share. If another team performs AWS configuration, share this MuleSoft AWS account ID with them. ### Resource Share ID and Owner The resource share ID and owner appear on the **Create a resource share** page on AWS. You use these values to verify the resource share in Anypoint Platform. - The resource share **ID** field contains alphanumeric characters (a-z, A-Z, 0-9) and hyphens (-). - The resource share **Owner** field contains only numbers. ## See Also - [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about) - [Anypoint Virtual Private Network](https://docs.mulesoft.com/cloudhub-2/ps-vpn-about) --- product: CloudHub 2.0 --- # Generating Apps Diagnostics and Analyzing with Einstein > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use the MuleSoft diagnostics agent to troubleshoot your Mule applications deployed to CloudHub 2.0. This feature leverages Einstein generative AI to automate diagnostics collection and provide intelligent, actionable insights. ## Before you Begin Before running the MuleSoft diagnostics agent: - 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 the MuleSoft Diagnostics Agent 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Select the app name. 3. In the navigation menu, select **Diagnostics**. 4. Select an active replica 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 If you download the generated Mule diagnostics, you receive a `.tar` archive containing two key assets: Mule Thread Dumps A thread dump is a snapshot of all the threads in a replica 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. ### Analyze with Einstein If you select **Analyze with Einstein**, the system generates the Mule diagnostics and runs the Einstein analysis simultaneously. The resulting analysis identifies root causes and recommends actions based on the DIAF file. ## 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 2.0 retains Mule diagnostics for 30 days or up to 150 MB. ## See Also - [Understanding the Diagnostic Information Analysis File (DIAF)](https://docs.mulesoft.com/mule-runtime/latest/mule-troubleshooting-plugin#understanding-diagnostic-information-analysis-file-diaf) - [Viewing Log Data for Deployed Apps](https://docs.mulesoft.com/cloudhub-2/ch2-view-logs) --- product: CloudHub 2.0 --- # Integrating with Your Logging System Using Log4j > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can stream Mule runtime logs, application logs, and tracing-module logs from CloudHub 2.0 to an external collector by configuring a custom asynchronous Log4j appender. This enables you to send logs to destinations such as Splunk, Azure Monitor, or any other external logging system that accepts Log4j output. > [!NOTE] External collectors such as Azure Monitor or a Telemetry Exporter are valid destinations > for CloudHub 2.0 logs. These are reached as generic external collectors via a custom Log4j > appender, they don’t have a dedicated built-in connector in CloudHub 2.0. ## Requirements and Restrictions - Log appenders must be asynchronous. Synchronous appenders aren’t supported. - File appenders, such as `FileAppender`, `RollingFileAppender`, `AnypointMonitoringFileAppender`, and `RandomAccessFileAppender`, are removed automatically by the platform. - MuleSoft Support doesn’t assist in implementing custom logging configurations or resolving issues caused by custom logging configurations. - MuleSoft isn’t 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 - When using custom Log4j configurations, both Mule runtime engine and application logs remain available in Runtime Manager. - You can forward tracing module logs using only third-party appenders. You can’t update the logging patterns to send them to Anypoint Monitoring. - Console logging is disabled by default in CloudHub 2.0. If you change log levels or appenders in a custom `log4j2.xml` and don’t see the changes in the logs, use an appender that CloudHub 2.0 collects, such as a third-party appender that streams to your logging system. Log output from a Console appender alone doesn’t appear in Runtime Manager. You can use any asynchronous Log4j appender. For information about configuring `log4j2.xml`, see the [Log4j Configuration Syntax](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax). ## Example: Create a Log4j Configuration Using Splunk > [!IMPORTANT] Console logging is disabled by default in CloudHub 2.0. If you rely only on a Console > appender, changes to log levels or appenders in your custom log4j2.xml might not appear in the > logs in Runtime Manager. To apply your custom Log4j configuration, use an appender that streams > logs to an external system, such as Splunk, or enable log integration for your deployment to > collect console output. For logs to be viewable in CloudHub 2.0 and flow to Splunk, configure the `SplunkHttp` Log4j appender. To enable the Log4j appender: 1. Update the `log4j2.xml` configuration file with your logger settings and include the `SplunkHttp` Log4j appender. In Anypoint Studio, the `log4j2.xml` file is located in the `src/main/resources` directory. ```xml ``` > [!NOTE] Deploying an app to CloudHub 2.0 configures `AnypointMonitoringFileAppender` > automatically, so you don’t need to configure it in `log4j2.xml`. 2. Ensure that the configuration includes the Splunk dependency: ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` For the latest version of Splunk, see [GitHub](https://github.com/splunk/splunk-library-javalogging/tags). After your application starts, logs start flowing to your custom Log4j appender, and you can view them on your target logging system. ## See Also - [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space) - [Deploying Apps to Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-shared-space) --- product: CloudHub 2.0 --- # Limits in CloudHub 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt CloudHub 2.0 imposes the following limits: Environments per business group 150 Private spaces per organization 100 Connections per private space 5\. 10 if the connections are not redundant. VPNs per private space 10 Transit gateway connections 5 per private space, depending on available network connection entitlements HTTP header length (`maxHeaderLength`) 32K Maximum HTTP request size 1 GB Maximum HTTP request timeout 300 seconds This is the read-request timeout, which is the maximum time the ingress controller waits to receive the complete request from the client. This timeout is hardcoded and applies to both shared and private spaces. > [!NOTE] In private spaces, you can configure the read-response timeout (the time CloudHub 2.0 > waits for a response from your Mule application) up to 3600 seconds. For more information, see > [Configure HTTP Requests and Read-Response Timeout](https://docs.mulesoft.com/cloudhub-2/ps-config-advanced#configure-http-requests-and-read-response-timeout). Maximum ingress URI size 4 KB Firewall rules (inbound) 300 Firewall rules (outbound) 300 Application size Up to 350 MB Application properties 300 Application property keys and values 1024 characters Custom TLS contexts per private space 50 Maximum number of Client Certificates in a TLS Context There is no limit on the number of client certificates, but there is a limit on the store file size. A TLS Context can reference one keystore and one truststore, which have their respective file size limits: - Truststore maximum file size: 40960 bytes (40 KB) - Keystore maximum file size for types JKS, JCEKS, PKCS12: 40960 bytes (40 KB). - Keystore maximum file size for type PEM: - Certificate File: 4096 bytes (4 KB). - CA Path Certificate File: 28672 bytes (28 KB). Ingress controller `content-length` in POST requests 0 or greater. `content-length` must be included in the POST request, even if the value is 0. Anypoint Platform CloudHub 2.0 API rate limit 15 requests per second per remote IP address. For information about limits in Exchange, see [Asset Limits](https://docs.mulesoft.com/exchange/asset-versions#asset-limits). > [!NOTE] Limits are subject to change. --- product: CloudHub 2.0 --- # 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.
Boolean OperatorDescriptionExample

AND

The AND operator matches documents where both terms exist anywhere in the text of a single document. This is equivalent to an intersection using sets.

To search for documents that contain "anypoint monitoring" use the query: "anypoint monitoring" AND "results"

OR

The OR operator is used by default if there is no Boolean operator inserted between two terms. The OR 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 | | can be used in place of the word OR.

To search for documents that contain either "monitoring anypoint" or just "monitoring" use the query:

"monitoring anypoint" monitoring

or

"monitoring anypoint" OR monitoring

NOT

The NOT operator excludes documents that contain the term after NOT. This is equivalent to a difference using sets. The symbol ! can be used in place of the word NOT.

To search for documents that contain "anypoint monitoring" but not "functional", use the query: "anypoint monitoring" NOT "functional"

The NOT operator can’t be used with just one term. For example, the following search returns no results:
NOT "functional"

+

Requires that the term after the + symbol exists somewhere in the field of a single document.

To search for documents that must contain "anypoint" and may contain "monitoring" use the query:

+anypoint monitoring

-

Excludes documents that contain the term after the - symbol.

To search for documents that contain "anypoint monitoring" but not "results" use the query:

"anypoint monitoring" -"results"

## 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. --- product: CloudHub 2.0 --- # Managing App Logs > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Logging is available for apps deployed to both shared and private spaces. If your organization has a Titanium subscription, you can use Anypoint Monitoring for more advanced searching and log management. For more information, see [Anypoint Monitoring Overview](https://docs.mulesoft.com/monitoring/). ## Configure Logging for the App Logging is enabled by default for apps deployed to CloudHub 2.0. ### Disable or Enable Logging To disable or reenable logging for the app: 1. Click the **Monitoring** tab. 2. Deselect or select the **Forward application logs to Anypoint Platform** option. 3. Click **Apply Changes**. If you disable logging, the **Logs** heading still appears in the Runtime Manager navigation menu, but application logs are not collected. ### Configure Log Levels and Categories To configure additional log levels and categories to include in logs: 1. Click the **Monitoring** tab. 2. Select the log level: - **INFO**: Informative messages - **DEBUG**: Debugging messages - **WARNING**: Warning messages - **ERROR**: Error messages, such as when an exception occurs - **FATAL**: Fatal messages for when an application fails 3. Optionally, set the log level for specific a Java package class by selecting the log level, entering the `package.name`, and pressing the Enter key. 4. Click **Apply Changes**. > [!NOTE] Changing the log level and clicking **Apply Changes** restarts the application. ## See Also - [Integrating with Your Logging System Using Log4j](https://docs.mulesoft.com/cloudhub-2/ch2-integrate-log-system) - [Viewing Log Data for Deployed Apps](https://docs.mulesoft.com/cloudhub-2/ch2-view-logs) - [Anypoint Monitoring Overview](https://docs.mulesoft.com/monitoring/) --- product: CloudHub 2.0 --- # Managing App 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, all without changing the running application. For example, you might want to disable a scheduled job while one of the applications is undergoing maintenance. On the **Schedules** tab, you can: - View the schedules in your running application. - Change the schedules in your application. - Run the scheduled job immediately, without changing the schedule. - Disable or enable the schedule for a flow. > [!NOTE] The CloudHub schedules REST API doesn’t expose scheduler or domain details for CloudHub > 2.0 applications. Manage CloudHub 2.0 schedulers only through the CloudHub 2.0 APIs or the Runtime > Manager **Schedules** tab. You configure Scheduler component types as either _fixed frequency_ to trigger at a regular interval or _cron_ to trigger at a date and time based on a specified cron expression. > [!IMPORTANT] To change a schedule type (between fixed frequency and cron or vice versa), you must > update and redeploy the app. You can’t change the schedule type on a deployed application. > [!IMPORTANT] To view the application schedules, you must have the **Exchange Viewer** permission, > in addition to the **Read Applications** permission. ## Schedule Design Considerations When designing the schedule, consider the following: - Plan for high availability during network failures. The CloudHub 2.0 infrastructure restarts due to hardware issues or scheduled maintenance, and security updates. During service updates or security patching, CloudHub 2.0 waits five minutes for existing schedules to complete. After a new replica is launched, the schedule runs at its next scheduled time. For more information, see the `shutdownTimeout` attribute in [Global Configurations Reference](https://docs.mulesoft.com/mule-runtime/latest/global-settings-configuration#global-configurations-reference). - After a security patching, the custom configuration via Runtime Manager takes precedence over the application configuration file. You can reset the schedulers and delete the custom configuration via API: ```curl DELETE /organizations/{organizationId}/environments/{environmentId}/deployments/{deploymentId}/schedulers/{flowName} ``` - Because schedules can be triggered more than once, design them to prevent duplicate data processing. If clustering is enabled, CloudHub 2.0 executes the schedule on a single replica, regardless of how many replicas are running. Subsequent schedule executions can occur on a different replica. CloudHub 2.0 distributes multiple concurrent schedules across replicas. - For clustered applications, CloudHub 2.0 triggers the schedule exclusively on the primary node. - If clustering isn’t enabled, schedules run individually on all replicas. - For a fixed-frequency scheduler, the minimum recommended start delay is five seconds. For more information, see [Disable or Enable a Scheduler Element](#disable-enable-scheduler). - If a schedule isn’t executed because the application isn’t running, CloudHub 2.0 doesn’t trigger it immediately when the application starts. The schedule is executed at its next scheduled time. - The CloudHub 2.0 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. - Changing the schedule redeploys your application. - If you scheduled a job for a time that is in the past while your app isn’t running, the job doesn’t execute when your app is started. - Schedules are based in the scheduler’s defined time zone. - For multi-replica apps, CloudHub 2.0 runs scheduled jobs on all replicas. If you run the scheduled job immediately by clicking **Run**, the scheduler runs on a single replica. CloudHub 2.0 distributes multiple concurrent schedulers across replicas. - You can’t manage CloudHub 2.0 schedules using scripts. Use the **Schedules** tab or the CloudHub 2.0 API to manage CloudHub 2.0 schedules. - Flow names can contain only upper and lower case letters, numbers, hyphens (`-`), underscores (`_`), and periods (`.`). The following characters are invalid: `/`, `[`, `]`, `{`, `}`, and `#`. - CloudHub 2.0 schedules run concurrently by default. The Scheduler triggers the execution of a schedule flow while a previously-triggered execution is still running. To run schedules sequentially, set the `disallowConcurrentExecution` property as `true` in the [scheduler](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#props_scheduler) configuration file. - By default, schedulers use the same time zone as the machine on which Mule is running. You can change it by adding the time zone you want. For more information, see [Cron Expressions](https://docs.mulesoft.com/anypoint-code-builder/acb-component-scheduler#cron-expressions). ### Fixed Frequency Schedules in Cluster Mode During Rolling Restart These transition behaviors apply to fixed-frequency schedules when the application runs in cluster mode and undergoes a rolling restart. Polling node transition and first trigger During a rolling restart, CloudHub 2.0 starts new nodes before it removes old nodes. The cluster elects a new polling node only after it decommissions the previous polling node. The new node then triggers the schedule. Until this election completes, no node polls the schedule. As a result, the first trigger that would otherwise occur right after a new node starts doesn’t fire. The schedule runs at the next calculated time after the cluster elects the new polling node. Schedule timing after restart Fixed-frequency schedules don’t retain the original schedule anchor after a rolling restart. The scheduler calculates the next run time relative to when the cluster elects the new polling node, not the pre-restart cadence. CloudHub 2.0 doesn’t support retaining the original schedule timing for fixed-frequency schedules. ## Before You Begin To use the scheduling feature in Runtime Manager, deploy an application that includes one or more Scheduler elements using Anypoint Studio 7.13 or later. ![Scheduler component in the Anypoint Studio canvas](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-studio.png) After you deploy the app, you can manage the schedule in Runtime Manager. The app doesn’t need to be running. ## View and Manage Application Schedules in Runtime Manager After deploying an app to CloudHub 2.0, view and manage the Scheduler elements in Runtime Manager: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. Runtime Manager lists the Scheduler elements in the order they appear in your app: ![(1) Flow name and (2) the frequency link on the Schedulers page.](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-rtm.png) - The **Name** column shows the name of the flow (1) that contains the Scheduler element. - The frequency link (2) in the **Schedule** column shows the schedule for the element. 4. If you want to see more information about when the jobs started and ended, click **Logs** in the navigation menu: ![Logs option in the navigation menu.](/mulesoft/current/en-us/cloudhub-2/_images/ch2-logs-rtm.png) 5. Click the frequency link for an element to open the schedule editor. The schedule editor you see depends on the schedule type: - [Fixed frequency](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule. 7. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Fixed Frequency Schedule 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![Fixed frequency schedule type](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-fixed-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** to disable the schedule: ![Fixed-frequency schedule configuration](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-editor-fixed.png) You can specify milliseconds, seconds, minutes, hours, or days for the frequency. The minimum recommended frequency between calls is 10 seconds. > [!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. > [!NOTE] The `startDelay` property is not visible or configurable in the Runtime Manager UI. To > change the `startDelay` value after deployment, use the Schedulers API. See > [Override Scheduler Properties Using the Schedulers API](#override-scheduler-api). 6. Click **Update** to save changed settings or click **Cancel** to exit without saving. ### Change a Cron Schedule With cron expressions, you can create more complex schedule frequencies, such as every 5 minutes between 9:00 am and 10:00 am on Fridays. To change the frequency of a cron schedule type: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. The **Schedule** column shows the schedule for the element: ![cron schedule type](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-cron-rtm.png) 4. Click the frequency link for an element to open the schedule editor. 5. In the schedule editor, change the schedule or deselect **Enabled** (1) to disable the schedule: ![cron schedule configuration with (1) Enabled option and (2) Quick Reference link](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-editor-cron.png) 6. In the schedule editor, select the time zone for your schedule from the **Time Zone** (3) dropdown menu. 7. In the schedule editor, click **Quick Reference** (3) to expand or collapse the table that lists required fields and allowed values. The cron expression in this example sets the schedule to every 10 seconds. For information about building cron triggers: 1. View the [Quartz documentation](https://www.quartz-scheduler.org/documentation/). 2. Select a version, click **Documentation > User’s Guide > Tutorial**, and then click the **CronTrigger** lesson. 8. Click **Update** to save changed settings or click **Cancel** to exit without saving. ## Override Scheduler Properties Using the Schedulers API The Schedulers API enables you to override scheduler configuration properties for a deployed application without redeploying it. This is useful for properties that are not configurable in the Runtime Manager UI, such as `startDelay` for fixed-frequency schedules. ### Overridable Properties Depending on the schedule type, you can override these properties:
Schedule TypeOverridable Properties

Fixed Frequency

  • frequency - The interval between schedule executions.

  • startDelay - The initial delay before the first execution.

  • timeUnit - The time unit for frequency and startDelay (for example, MILLISECONDS, SECONDS, MINUTES, HOURS, DAYS).

Cron

  • expression - The cron expression that defines the schedule.

  • timeZone - The time zone for the cron schedule.

### Update Scheduler Properties To update scheduler properties, send a `PUT` request to the Schedulers API endpoint: ```curl curl -X PUT \ https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{orgId}/environments/{envId}/deployments/{deploymentId}/schedulers/{flowName} \ -H 'Authorization: bearer {token}' \ -H 'Content-Type: application/json' \ -d '{ "startDelay": "10", "frequency": "60000", "timeUnit": "MINUTES" }' ``` Replace these placeholders in the request: - `{orgId}` - Your Anypoint Platform organization ID. - `{envId}` - The environment ID where the application is deployed. - `{deploymentId}` - The deployment ID of your application. - `{flowName}` - The name of the flow that contains the Scheduler element. - `{token}` - A valid Anypoint Platform access token. For cron schedules, use the `expression` and `timeZone` properties in the request body instead: ```curl curl -X PUT \ https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{orgId}/environments/{envId}/deployments/{deploymentId}/schedulers/{flowName} \ -H 'Authorization: bearer {token}' \ -H 'Content-Type: application/json' \ -d '{ "expression": "0 0/5 * * * ?", "timeZone": "America/Los_Angeles" }' ``` ## Run a Scheduled Job Immediately If a job 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. When you trigger the job in between instances of the scheduler running, the timer for the indicated time period resets. > [!NOTE] If you run the scheduled job immediately, the scheduler runs on a single replica even for > multi-replica apps. To override the schedule and run the job immediately: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Run**. ## Disable or Enable a Scheduler Element You might want to disable a scheduled job if an application you are connecting to is undergoing maintenance and then reenable it after maintenance is complete. CloudHub 2.0 doesn’t run the scheduled job until you reenable the Scheduler. Even after you disable a scheduler, it can still run once. The condition that triggers a disabled scheduler, and the way to prevent an unwanted run, depend on the schedule type:
Schedule TypeWhen a Disabled Scheduler Can Still Run OnceHow to Prevent It

Fixed frequency

The scheduler can trigger once when the application starts.

Set the startDelay property to at least five seconds. Configure startDelay in your app in Anypoint Studio, or change it after deployment using the Schedulers API.

Cron

Changing any schedule redeploys the application, and a redeployment that occurs close to the cron trigger time can let a disabled scheduler run once. Because enabling or disabling any scheduler redeploys the app, running several enable or disable actions near a cron trigger time can trigger a disabled scheduler.

The startDelay property applies only to fixed-frequency schedulers and has no effect on cron schedulers. Avoid enabling or disabling schedulers close to a cron trigger time, and confirm the scheduler state on the Schedules tab afterward.

> [!NOTE] A disabled scheduler can revert to enabled after an application restart, rolling restart, > or maintenance, so it can run again even though you disabled it. This behavior isn’t limited to > first startup. After a restart, check the scheduler state on the **Schedules** tab and disable it > again if you need it to stay off. To disable the Scheduler element: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Schedules**. 4. Select the elements to manage and then click **Disable**. You can also disable or enable the schedule by deselecting or selecting **Enabled** in the schedule editor. ![Enabled toggle in the schedule editor](/mulesoft/current/en-us/cloudhub-2/_images/ch2-scheduler-enable.png) ## Schedule Behavior with Rolling Update vs. Recreate Deployment Model For fixed-frequency schedules in cluster mode, see [Fixed Frequency Schedules in Cluster Mode During Rolling Restart](#cluster-mode-fixed-frequency) for transition behavior during rolling restarts, including the first trigger after node start and schedule timing. During the initial deployment of an application with cluster mode and rolling update deployment model enabled, the application’s fixed-frequency scheduler runs alongside the application startup. If you switch from [rolling update to recreate deployment model](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps#rolling-update-vs-recreate-deployment-model), the scheduler is triggered again with the application startup. But if you switch from recreate back to rolling update deployment model, the scheduler no longer runs at startup and instead triggers based on the configured frequency. This happens because the recreate deployment model turns off the previous instances of the application and starts them again in a new cluster. The previous record of the last run of the scheduler isn’t saved. In this case, Mule runs the scheduler unless it’s a fixed-date frequency. However, the rolling update deployment model saves the previous configuration. ## See Also - [Deploying Apps to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-deploy) - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz documentation](https://www.quartz-scheduler.org/documentation/) - [Example Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) --- product: CloudHub 2.0 --- # Managing Apps Deployed to CloudHub 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - [Updating Apps Deployed to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps) - [Managing App Schedules](https://docs.mulesoft.com/cloudhub-2/ch2-manage-schedules) - [Changing App Behavior with Properties](https://docs.mulesoft.com/cloudhub-2/ch2-manage-props) - [Protecting App Property Values](https://docs.mulesoft.com/cloudhub-2/ch2-protect-app-props) - [Managing App Logs](https://docs.mulesoft.com/cloudhub-2/ch2-manage-app-logs) - [Automatic App Restarts](https://docs.mulesoft.com/cloudhub-2/ch2-understand-app-restart) --- product: CloudHub 2.0 --- # Managing Private Spaces > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use Anypoint Runtime Manager to manage private spaces, such as adding and removing a route from the route table or detaching a transit gateway from the private space. ## Add or Remove a Route from the Route Table Routes determine how to direct traffic from your private space, for example, to the public internet or through a connection (VPN or transit gateway). You might want to add a route to enable a new subnet to be accessible or remove a route if you no longer want a subnet to be accessible through the transit gateway. When you create a new private space, you can remove the default routes that MuleSoft provides. However, when you change the default route, your private space might experience downtime. If the **X** icon doesn’t appear for a route, you can’t remove it. You cannot remove the MuleSoft-defined routes for existing private spaces created before March 9, 2023. You must create and configure a new private space to remove the default routes that MuleSoft defines. MuleSoft defines other routes, such as control plane traffic routes, that you cannot view or remove from the route table. Note that Anypoint MQ, ObjectStore v2, and API Manager require internet access from your network. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Private Network** section, click **Route Table**: The route table shows all routes for the private space. - Add a route by entering the subnet in CIDR notation, selecting the connection, and clicking **Add Route**: You can’t add a route that matches a priority route (a route that’s used by your private network). Routes can be used by only one connection at a time. If you enter a non-local/Internet Gateway (IGW) route, CloudHub 2.0 warns that the route is being used by another connection. Routes should not overlap with existing routes. CloudHub 2.0 warns if you enter a route that overlaps with another route in the route table. - Remove a route by clicking the **X** icon for a row in the table and then clicking **Delete** to confirm. If the **X** icon doesn’t appear for a route, you can’t remove it. You can remove routes for static VPN connections. 4. Click **Done** to close the route table. Anypoint Platform submits the new route to AWS. > [!NOTE] You cannot add 169.254.168.0/22 (reserved by AWS) as a route destination. ## Rename a Connection 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, click the Connections menu (**…​**) and select **Rename**: 4. Enter the new name and click **Save**. ## Create Redundant VPN 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, click the VPN menu (**…​**) and select **Create Redundant VPN**: 4. Follow the steps in [Create a Redundant VPN](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-vpn#create-redundant-vpn). ## Rename a VPN 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, click the VPN menu (**…​**) and select **Rename**: 4. Enter the new name and click **Save**. ## Change VPN Connection Settings You can change the tunnel initiation behavior after configuring the VPN connection. This setting applies to all VPNs in this connection and is enabled by default. > [!IMPORTANT] Modifying the tunnel initiation after VPN creation causes all VPNs in this connection > to restart. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, click the VPN menu (**…​**) and select **Connection Settings**: 4. On the **Connection Settings** page, you can: - Enter a new name for the VPN connection. - Expand **Advanced Options** to change the **Automatic Tunnel Initiation** option. Enable this option to specify that VPN starts up automatically. If you deselect this option, you must generate traffic from the customer gateway to establish VPN tunnels. 5. Click **Save** or **Cancel** to close the **Connection Settings** window. Modifying the **Automatic Tunnel Initiation** option restarts all VPNs in the connection. ## View VPN Status 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, click the VPN menu (**…​**) and select **View Details**: 4. Click **X** to close the **VPN Details** window. ## Enable VPN logs You can enable VPN logs to be directly accessible by MuleSoft support engineers. This shortens the process for obtaining the logs from AWS. 1. For VPN connections created after March 8, 2023, VPN logs are enabled by default upon creation. 2. For existing VPN connections: 1. You can enable VPN logs via PATCH call to the following existing endpoint: `[https://anypoint.mulesoft.com/runtimefabric/api/organizations/{{org-id}}/privatespaces/{{ps-id}}/connections/{{connection-id}}/vpns/{{vpn-id}}](https://anypoint.mulesoft.com/runtimefabric/api/organizations/{{org-id}}/privatespaces/{{ps-id}}/connections/{{connection-id}}/vpns/{{vpn-id}})`. The payload to enable logs for VPNs with two tunnels without making other changes is `{"vpnTunnels":[{"isLogsEnabled": true}, {"isLogsEnabled": true}]}`. The `isLogsEnabled` flag can only be set to `true`; otherwise, the API returns a 400 error. 2. Any updates you make to an existing VPN after March 8, 2023 enables the VPN logs to be directly accessible by MuleSoft Support Engineers. > [!NOTE] Enabling this feature speeds up the process for obtaining VPN logs from AWS, as the > MuleSoft support team can download them directly, with no need to raise an AWS support ticket. ## Delete a VPN Deleting the last VPN in a connection removes the entire connection. > [!IMPORTANT] You can’t undo this action. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, click the VPN menu (**…​**) and select **Delete**: 4. Click **Delete** to confirm the deletion or **Cancel**. ## 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. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, click the transit gateway menu (**…​**) and select **Rename**: 4. Enter the new name and click **Save**. ## Detach a Transit Gateway from the Private Space You might want to detach a transit gateway attachment for the following reasons: - If you reject an attachment in AWS, the transit gateway attachment appears as `Rejected` in Anypoint Platform. In this case, you must remove the attachment before trying to attach it again. - If an attachment is deleted on AWS, you can remove the attachment from Anypoint Platform. Removing a transit gateway attachment also deletes any associate routes. The resource share on AWS remains unaffected so you can readd the transit gateway without creating a new one. However, detaching a transit gateway from a private space also deletes the attachment in AWS. The transit gateway appears under **Add a transit gateway** if you only detach it and do not delete it from your organization. Any apps deployed to the private space continue to run, but they are no longer connected to your Amazon VPCs and VPNs. To detach the transit gateway: 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, in the **Connections** section, click the transit gateway menu (**…​**) and select **Detach**: 4. At the confirmation prompt, click **Detach**. Detaching a transit gateway might take several minutes. ## Delete a Transit Gateway To completely remove the transit gateway from your Anypoint Platform organization, use the [delete transit gateway API call](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/minor/1.0/console/method/%234136/) (`DELETE <>/organizations/:orgId/transitgateways/:tgw-id`) and delete the resources share on AWS. For information, see [Deleting a resource share](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-delete.html) in the AWS documentation. ## Delete a Private Network You can’t delete a private network if any apps are deployed to it or if any connections exist. > [!IMPORTANT] You can’t undo this action. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. On the **Network** tab, click the Private Network menu (**…​**) and select **Delete**: 4. Click **Delete** to confirm the deletion. ## Delete a Private Space You can’t delete a private space if it has any related private network, VPNs, or transit gateway attachments. > [!IMPORTANT] You can’t undo this action. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the Private Space menu (**…​**) and select **Delete**. ![Delete option in the Private Space menu](/mulesoft/current/en-us/cloudhub-2/_images/ps-delete.png) 4. Click **Delete private space** to confirm the deletion or **Cancel**. ## See Also - [Deleting a resource share](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-delete.html) in the AWS documentation --- product: CloudHub 2.0 --- # Monitoring Apps Deployed to CloudHub 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - [Viewing Log Data for Deployed Apps](https://docs.mulesoft.com/cloudhub-2/ch2-view-logs) - [Generating Apps Diagnostics and Analyzing with Einstein](https://docs.mulesoft.com/cloudhub-2/ch2-view-diag) - [Configuring Application Alerts](https://docs.mulesoft.com/cloudhub-2/ch2-config-app-alerts) --- product: CloudHub 2.0 --- # Private Spaces > For the full documentation index, see: https://docs.mulesoft.com/llms.txt A _private space_ is a virtual, private, and isolated logical space in CloudHub 2.0 in which to run your apps. You can create multiple private spaces, either in the same or different regions. You connect your private intranet to your private space to function as a single, private network. In each private space, you define: - A _private network_, which is a virtual cloud where apps deployed to this private space run. - One or more connections from the private network to your external network, either via Anypoint VPN or a transit gateway. - TLS contexts, which define the domains that are available when deploying apps to the private spaces, and optionally enable mutual TLS. - Firewall rules to allow and block inbound and outbound traffic to your private space. - The environments and business groups to allow to deploy to the private space. When you create a private space, your license for Mule runtime is automatically injected and managed by MuleSoft. ## Private Network When you create the private network, you associate a range of IP addresses for the apps in your private space to use, the region in which they run, and optionally, any internal DNS servers to resolve requests to custom domains. You can configure multiple private spaces in a single region, enabling you to set up separate isolated networks for your production and non-production environments, such as dev or staging. For information about regions, see [Private Network Region](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#private-network-region). ## Private Network Connections You can connect a private space to your private network using the following methods: - [Anypoint Virtual Private Network](https://docs.mulesoft.com/cloudhub-2/ps-vpn-about) - [Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub-2/ps-tgw-about) ## TLS Contexts Using Transport Layer Security (TLS) contexts, CloudHub 2.0 enables clients to use custom domains and paths to reach apps deployed to private spaces. When setting up a private space, you configure Transport Layer Security (TLS) contexts that define the domains that are available when deploying apps to the private spaces, and optionally enable mutual TLS. When deploying an app to the private space, you can use the domains from the TLS contexts to configure multiple endpoints, which clients use to reach the app from the internet. If the domains in the TLS context include a wildcard, you can configure an optional subdomain, such as the app name or an organization. You can create as many endpoints as you need. ## Path Rewriting You can configure the app to be accessible from a different path from the base path where the app is listening. ## Firewall Rules You control the traffic to and from your private spaces. Inbound By default, CloudHub 2.0 allows traffic to the private space on ports 80 (HTTP) and 443 (HTTPS) from anywhere (0.0.0.0/0). Configure firewall rules to allow connections through specified ports, remove ports, or use ports 80 and 443 to control traffic to your private space. The private space provides load balancing to balance inbound traffic to apps across multiple replicas. Outbound By default, CloudHub 2.0 allows all traffic from the private space to destinations outside the private space. Configure firewall rules to remove this rule and allow traffic only on specified ports. By combining firewall rules and TLS context configuration, you can fine-tune the ingress and egress of your application traffic. Private space 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 - [Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure) - [Creating VPN Connections](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-vpn) - [Creating Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-tgw) - [Configuring Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-configure) - [Configuring Domains and Certificates (TLS Context) for a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains) - [Configuring Firewall Rules to Manage Traffic to and from a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules) - [Associating Business Groups and Environments with a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-env) - [Configuring Endpoints and Paths for Apps Deployed to a Private Space](https://docs.mulesoft.com/cloudhub-2/ch2-config-endpoints-paths) --- product: CloudHub 2.0 --- # Private Spaces > For the full documentation index, see: https://docs.mulesoft.com/llms.txt A _private space_ is a virtual, private, and isolated area in CloudHub 2.0 in which to run your apps. You can create multiple private spaces, either in the same or different regions. You connect your private intranet to your private space to function as a single, private network. In each private space, you define: - A _private network_, which is a virtual cloud where apps deployed to this private space run. - A connection from the private network to your external network, either via Anypoint VPN or a transit gateway connection. - TLS contexts, which define the domains that are available when deploying apps to the private spaces. - Firewall rules to allow and block inbound and outbound traffic to your private space. - The environments and business groups to allow to deploy to the private space. - Where to forward logs, either Anypoint Monitoring or an external service such as Splunk. ## Private Network When you create the private network, you associate a range of IP addresses for the apps in your private space to use, the region in which they run, and optionally, any internal DNS servers to resolve requests to custom domain. Private spaces support Amazon regions. You can configure multiple private spaces in a single Amazon region, enabling you to set up separate isolated networks for your production and non-production environments, such as QA or staging. ## Private Network Connections You can connect a private space to your private network using the following methods: - [Anypoint Virtual Private Network](https://docs.mulesoft.com/cloudhub-2/ps-vpn-about) - [Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub-2/ps-tgw-about) > [!NOTE] Before configuring routing, consolidate networks to the fewest number possible. A maximum > of 95 route table entries is allowed per private space, regardless of the number of connections. ## TLS Contexts Using Transport Layer Security (TLS) contexts, CloudHub 2.0 enables clients to use custom domains to reach apps deployed to private spaces. When setting up a private space, you configure Transport Layer Security (TLS) contexts that define the domains that are available when deploying apps to the private spaces. When deploying an app to the private space, you use the domains from the TLS contexts to configure multiple endpoints, which clients use to reach the app from the internet. If the domains in the TLS context include a wildcard, you can configure an optional subdomain, such as the app name or an organization. You can create as many endpoints as you need. In addition to custom domains, you can configure the app to be accessible from a different path from the base path where the app is listening. ## Firewall Rules You control the traffic to and from your private spaces. By default, CloudHub 2.0 blocks all traffic to the private space and provides firewall rules to allow connections through specified ports. You can configure additional firewall rules to control traffic to your private space, expose or block your custom ports, and block requests to your apps. The private space provides load balancing to balance inbound traffic to apps across multiple replicas. By combining firewall rules and TLS context configuration, you can fine-tune how external services reach your applications. ## See Also - [Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure) - [Creating VPN Connections](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-vpn) - [Creating Transit Gateway Attachments](https://docs.mulesoft.com/cloudhub-2/ps-create-configure-tgw) - [Configuring Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-configure) - [Configuring Domains and Certificates (TLS Context) for a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains) - [Configuring Firewall Rules to Manage Traffic to and from a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules) - [Associating Business Groups and Environments with a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-env) - [Configuring Endpoints and Paths for Apps Deployed to a Private Space](https://docs.mulesoft.com/cloudhub-2/ch2-config-endpoints-paths) --- product: CloudHub 2.0 --- # Protecting App Property Values > For the full documentation index, see: https://docs.mulesoft.com/llms.txt CloudHub 2.0 enables you to protect application property values by displaying the property name but not its value, in Anypoint Runtime Manager. Additionally, the value isn’t viewable or retrievable by any user. CloudHub 2.0 resolves the property internally at runtime. These protected application values are encrypted and stored in the Anypoint Security secrets manager, which, in turn, is encrypted per user organization. Because the values are encrypted, you can’t view them in Anypoint Security secrets manager or Anypoint Runtime Manager. > [!NOTE] On CloudHub 2.0, secure-property masking is configured in Anypoint Runtime Manager on the > **Properties** tab (property protection). > > If you’re migrating from CloudHub 1.0, the `secureProperties` setting in `mule-artifact.json` > doesn’t mask values on CloudHub 2.0. To mask values, set property protection on the **Properties** > tab, as described in the following sections. Runtime Manager properties override archive-bundled > properties of the same name. > [!IMPORTANT] Protected property values are separate from the encrypted Mule application properties > stored in secure configuration files. See > [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties). ## Protect Property Values in Runtime Manager Set protected properties via the table view for granular control over each property and value. Although you can attempt to protect a single property more than once, Runtime Manager issues a warning and protects only the final instance of that property. 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Settings**. 4. On the **Settings** page, click the **Properties** tab. 5. Depending on how many properties you want to protect, choose either: - To protect properties one at a time, click **Table view**. - To protect multiple properties, use **Text view** to add the key-value pairs, switch to **Table view**, and continue to Step 8 to protect the properties. 6. In the **New Key** field, enter the property name to protect. 7. In the **New Value** field, enter the property value. 8. In the value field, click **Protect** and then click **Protect value** to confirm. ![Protect button on the Properties tab](/mulesoft/current/en-us/cloudhub-2/_images/ch2-protected-props-protect.png) 9. Depending on the deployment status, choose either: - If this application is deployed, click **Apply Changes**. - If you’re ready to deploy the application, click **Deploy Application**. On the **Properties** tab, the values for properties that you just protected are now no longer visible to you or any other user. In the following example, the values for `birthdate` and `password` are protected, but the value for `username` is not: ![Protected values on the Properties tab on the application Settings page](/mulesoft/current/en-us/cloudhub-2/_images/ch2-protected-props.png) After you commit the values and deploy the app, the protected property values don’t appear in the console and aren’t sent and received between the console and CloudHub. ## Replace a Protected Property Value After you set the property value, you can’t retrieve it. However, you can replace the protected property value with a new protected value: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Settings**. 4. On the **Settings** page, click the **Properties** tab. 5. Click **Table view**. 6. Click **…​** > **Replace protected value**: ![Replace protected value option](/mulesoft/current/en-us/cloudhub-2/_images/ch2-protected-props-replace.png) 7. Enter a new value in the field. 8. Click **Apply**, then **Apply Changes**. ## See Also - [Secure Configuration Properties](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties) - [Changing App Behavior with Properties](https://docs.mulesoft.com/cloudhub-2/ch2-manage-props) - [Deploying Apps to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-deploy) --- product: CloudHub 2.0 --- # 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: - 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 - [CloudHub 2.0 Overview](https://docs.mulesoft.com/cloudhub-2/) - [Deploying Apps to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-deploy) - [Managing Apps Deployed to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-manage-apps) - [Deployment Options](https://docs.mulesoft.com/runtime-manager/deployment-strategies) --- product: CloudHub 2.0 --- # Setting Up an Outbound Private Link Connection > For the full documentation index, see: https://docs.mulesoft.com/llms.txt AWS Private Link provides private connectivity between a CloudHub 2.0 private space and services hosted on AWS and supported AWS services. CloudHub 2.0 supports two private connectivity options: Virtual Private Network (VPN) and Transit Gateway (TGW). Both operate at Open Systems Interconnection (OSI) layer 3, the network layer. Private Link operates at OSI layer 4 and offers better isolation. The virtual service appears inside the same network, but the CloudHub 2.0 private space network and your on-prem network aren’t interconnected. Private Link is also service specific. Each service must be explicitly defined in the private space to prevent accidental exposure of sensitive applications. The advantages of Private Link are: - Secure access to services without going through the internet - Better isolation between your network and CloudHub 2.0 - Smaller blast radius if something goes wrong - Service level control on what services available to CloudHub 2.0 Common use cases for Private Link are: - Private Link from CloudHub 2.0 private space to a service hosted in AWS by your organization - Private Link from CloudHub 2.0 private space to a supported AWS service (for example, S3 and Kinesis) - Private Link from CloudHub 2.0 private space to third-party services hosted in AWS - For example, [Private Connect](https://help.salesforce.com/s/articleView?id=xcloud.private_connect_overview.htm&type=5), which enables private connectivity between CloudHub 2.0 and Salesforce ## Limitations Outbound Private Link from a CloudHub 2.0 private space to Amazon MSK (Managed Streaming for Apache Kafka) isn’t covered by the setup procedures in this topic. MSK clusters expose multiple brokers. Private Link endpoint services commonly front a single load-balanced target, such as a network load balancer. Aligning MSK broker topology with Private Link endpoint service requirements generally requires additional design and configuration in your AWS environment. For alternatives, work with your AWS account team or consider other connectivity options (for example, [Transit Gateway](https://docs.mulesoft.com/cloudhub-2/ps-tgw-about) or [Anypoint VPN](https://docs.mulesoft.com/cloudhub-2/ps-vpn-about)) depending on your architecture and security requirements. ## Before You Begin 1. Provision a [private space](https://docs.mulesoft.com/cloudhub-2/ps-create-configure) in CloudHub 2.0. 2. Obtain a bearer token for calling APIs. Follow the instructions from [Anypoint identity](https://docs.mulesoft.com/access-management/saml-bearer-token) or [external identity](https://help.salesforce.com/s/articleView?id=001115323&type=1) to get a bearer access token for your Anypoint organization. The token owner must have permissions to manage private spaces. ## Configure the Outbound Connections Follow these steps to set up an outbound Private Link connection from your CloudHub 2.0 private space: 1. Gather private space availability zones (AZs) and AWS Account ID. 1. Retrieve information about availability zones for your private space. ```curl curl -XGET https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/azs -H "Authorization:$AUTHTOKEN" ``` Example output: ```json ["use1-az1", "use1-az2", "use1-az5"] ``` 2. Retrieve information about accounts associated with your private space. ```curl curl -XGET https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/accounts -H "Authorization:$AUTHTOKEN" ``` Example output: ```text 328752079326 ``` 2. Make your services Private Link ready. Verify that your services are properly configured for Private Link connectivity before establishing connections: AWS S3 Service AWS S3 service is already Private Link ready with regional VPC endpoints and a global access endpoint. For cross-region connections, use the global access endpoint. ```text Regional Endpoint: com.amazonaws.{region}.s3 Global Access Endpoint: com.amazonaws.s3-global.accesspoint ``` For a complete list of AWS services ready for private link, see [AWS PrivateLink-supported services](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html). Salesforce Private Connect Salesforce Private Connect requires activation as an add-on. After activation: 1. In Salesforce, go to **Setup**, enter **Private Connect** in the **Quick Find** box, and select **Private Connect**. 2. On the **Private Connect** page, click **AWS Regions** to reveal available regions. 3. Select the AWS region that matches your private space region. 4. Copy the service name for later use. Custom Services (Self-Hosted) To prepare custom services: 1. Deploy your service in at least one private space AZ. For high availability, configure 2 AZs. 2. Expose the service via a network load balancer or application load balancer. 3. [Create an endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) following AWS guidance. 4. Set **Acceptance required** to **Yes** to prevent unauthorized connections. 5. Add the private space CIDR range to the inbound rules of the AWS security group attached to your endpoint service (for example, the security group for your network load balancer or application load balancer). Traffic from the CloudHub 2.0 private space originates from this CIDR; allowing it is required for Private Link connectivity. You can find your private space CIDR in the private space configuration (the [CIDR block](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#cidr-block) you specified when creating the private space). 6. Optionally, configure a private DNS name for your service. CloudHub 2.0 private space automatically picks up the private DNS and makes it available to Mule applications. > [!NOTE] If the service is hosted in the same region as the private space, set up the > services in the same availability zone as the private space obtained in > [Configure the Outbound Connections](#configure-the-outbound-connections). For > cross-region services, you don’t need AZ alignment. Validation for cross-region > connectivity isn’t yet complete; its success depends on the configuration. 3. Share the VPC endpoint services with your CloudHub 2.0 private space: 1. [Configure an endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html). 2. From VPC **Endpoint services**, select **Allow principals**. Add `arn:aws:iam::{accountId}:root` as principal. The `{accountId}` is the account ID obtained in [Configure the Outbound Connections](#configure-the-outbound-connections). 4. Gather this information for the API: 1. Service Name: The endpoint service name, for example: 1. Customer-hosted endpoint service: `com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxxxxxxxxxx` 2. AWS hosted service: `com.amazonaws.us-west-2.s3` 2. Service Region: The region where the VPC endpoint service is located. 3. Service Owner: The owner of the VPC endpoint service. 1. Account ID of the endpoint service. For services like Salesforce Private Connect, you can acquire the service owner account ID using the AWS CLI command: ```bash aws ec2 describe-vpc-endpoint-services --service-names {your-service-name} --region {your-service-region} ``` The account ID is in the **Owner** field. 2. `amazon`, if it’s an Amazon service. 4. Availability Zone IDs: The IDs of the availability zones where you want to establish the private link. Check that the AZ IDs match those obtained in [Configure the Outbound Connections](#configure-the-outbound-connections), and verify the VPC endpoint service uses those AZs. Alternatively, specify `countOfAzs` with an integer value (1 or 2) to have CloudHub 2.0 automatically assign the required number of availability zones. Provide either `azIds` or `countOfAzs`, not both. 5. Create a VPC endpoint in CloudHub 2.0 via API: See these specific examples for different service types: AWS S3 Endpoint To configure an S3 endpoint for your private space, the `serviceOwner` is `amazon`. Configure at least two AZs. Because AWS services are available in all its AZs, you can pick any AZs from your private space. ```curl curl -XPOST https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces -H "Authorization:bearer {your-token}" -H "Content-Type:application/json" -d '{ "name": "S3-Global", "serviceName": "com.amazonaws.s3-global.accesspoint", "serviceRegion": "us-east-1", "serviceOwner": "amazon", "azIds": ["use1-az1", "use1-az2"] }' ``` Alternatively, use `countOfAzs` to let CloudHub 2.0 select the availability zones automatically: ```curl curl -XPOST https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces -H "Authorization:bearer {your-token}" -H "Content-Type:application/json" -d '{ "name": "S3-Global", "serviceName": "com.amazonaws.s3-global.accesspoint", "serviceRegion": "us-east-1", "serviceOwner": "amazon", "countOfAzs": 2 }' ``` ### Salesforce Private Connect Endpoint To create a Private Connect endpoint, provide the `serviceName`, `serviceRegion`, and the account ID hosting the VPC endpoint service. - ```curl curl -XPOST https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces -H "Authorization:bearer {your-token}" -H "Content-Type:application/json" -d '{ "name": "Private Connect", "serviceName": "{your-service-name-for-salesforce-private-connect}", "serviceRegion": "{your-salesforce-region}", "serviceOwner": "{your-salesforce-service-account-id}", "azIds": ["use1-az1", "use1-az2"] }' ``` Custom Service Endpoint For custom services, if you didn’t create your service in the same AZs as the CloudHub 2.0 private space, make sure that the chosen AZs exist in both your service network and the private space. ```curl curl -XPOST https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces -H "Authorization:bearer {your-token}" -H "Content-Type:application/json" -d '{ "name": "Custom Service", "serviceName": "{your-service-name}", "serviceRegion": "{your-service-region}", "serviceOwner": "{your-service-account-id}", "azIds": ["use1-az1", "use1-az2"] }' ``` If the VPC endpoint is successfully created, the API returns a `vpceId`. Get the VPC endpoint status in CloudHub 2.0 using the API: ```curl curl -XGET https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces/{vpceid} -H "Authorization:$AUTHTOKEN" ``` If successful, it returns the DNS names of the VPC endpoint. It also returns the provisioning status: - `Invalid`: VPCE creation failed - `Valid`: VPCE is being provisioned - `Available` - `PendingAcceptance` Use this command to update a VPC endpoint: ```curl curl -XPATCH https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces/{vpceId} -H "Authorization:$AUTHTOKEN" -H "Content-Type:application/json" -d '{ "name": "{any name}", "serviceName": "{service name}", "serviceRegion": "{service region}", "serviceOwner": "{service owner}", "azIds": [{aws-az-id1}, {aws-az-id2}] }' ``` You can use `"countOfAzs": 2` (valid values: 1 or 2) instead of the `azIds` array. When you specify `countOfAzs`, CloudHub 2.0 automatically selects which availability zones to use. Provide either `azIds` or `countOfAzs`, not both. Use this command to delete a VPC endpoint: ```curl curl -XDELETE https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces/{vpceid} -H "Authorization:$AUTHTOKEN" ``` ## Establish the Private Link Connection After creating the endpoints, establish the connection. List all configured endpoints. ```curl curl -XGET https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces -H "Authorization:bearer {your-token}" ``` Example output: ```json [ { "name": "S3-Global", "vpceId": "ec6a2988-5529-4fac-9262-9b9962ce0b50", "serviceName": "com.amazonaws.s3-global.accesspoint", "serviceRegion": "us-east-1", "serviceOwner": "amazon", "azIds": ["use1-az1", "use1-az2"] }, { "name": "Private Connect", "vpceId": "b7e73b1c-b0ba-489d-b525-8c29a1702186", "serviceName": "com.amazonaws.vpce.us-east-1.vpce-svc-03fa74d9c231a52aa", "serviceRegion": "us-east-1", "serviceOwner": "784556874502", "azIds": ["use1-az1", "use1-az2"] }, { "name": "Custom Service", "vpceId": "fc5c9c55-d943-4383-88ac-cc2b51446d54", "serviceName": "com.amazonaws.vpce.us-east-1.vpce-svc-03cef49533264d928", "serviceRegion": "us-east-1", "serviceOwner": "055970264539", "azIds": ["use1-az1"] } ] ``` AWS S3 Service Because AWS manages these services, it establishes the connection automatically. Salesforce Private Connect To establish the Private Connect connection, retrieve the endpoint ID using this API command: ```curl curl -XGET https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces/{vpce-id} -H "Authorization:bearer {your-token}" ``` Example output: ```json { "name": "Private Connect", "vpceId": "b7e73b1c-b0ba-489d-b525-8c29a1702186", "serviceName": "com.amazonaws.vpce.us-east-1.vpce-svc-03fa74d9c231a52aa", "serviceRegion": "us-east-1", "serviceOwner": "784556874502", "azIds": ["use1-az1", "use1-az2"], "status": "pendingAcceptance", "provisioningMessage": "", "awsId": "vpce-06b4ba2047c41be17", "dnsEntries": [ "vpce-06b4ba2047c41be17-1lnhhl4b.vpce-svc-03fa74d9c231a52aa.us-east-1.vpce.amazonaws.com", "vpce-06b4ba2047c41be17-1lnhhl4b-us-east-1d.vpce-svc-03fa74d9c231a52aa.us-east-1.vpce.amazonaws.com", "vpce-06b4ba2047c41be17-1lnhhl4b-us-east-1a.vpce-svc-03fa74d9c231a52aa.us-east-1.vpce.amazonaws.com" ] } ``` The endpoint status shows **Pending Acceptance**. Complete the connection: 1. Note the `awsId` from the endpoint. 2. Go to Private Connect and click **create inbound connections**. 3. Select **AWS** and configure the connection using the `awsId` (VPC Endpoint ID). 4. Click **Save**. Within a few minutes, the endpoints sync and the status changes to **Ready** in Private Connect and **Available** in CloudHub 2.0. Custom Services Fetch the endpoint information: ```curl curl -XGET https://anypoint.mulesoft.com/runtimefabric/api/organizations/{orgId}/privatespaces/{spaceId}/vpces/{vpce-id} -H "Authorization:bearer {your-token}" ``` Example output: ```json { "name": "Custom Service", "vpceId": "fc5c9c55-d943-4383-88ac-cc2b51446d54", "serviceName": "com.amazonaws.vpce.us-east-1.vpce-svc-03cef49533264d928", "serviceRegion": "us-east-1", "serviceOwner": "055970264539", "azIds": ["use1-az1"], "status": "pendingAcceptance", "provisioningMessage": "", "awsId": "vpce-0d971d98cb910b3b1", "dnsEntries": [ "vpce-0d971d98cb910b3b1-oyattu6z.vpce-svc-03cef49533264d928.us-east-1.vpce.amazonaws.com", "vpce-0d971d98cb910b3b1-oyattu6z-us-east-1d.vpce-svc-03cef49533264d928.us-east-1.vpce.amazonaws.com" ] } ``` The custom service VPC endpoint status shows **Pending Acceptance**. Accept the connection: 1. In the AWS console go to **VPC** > **Endpoint Services**. 2. Select your service and open the **Endpoint Connection** tab. 3. Verify the **Endpoint ID** and **Owner** match your private space in CloudHub 2.0. 4. Accept the connection. > [!NOTE] If you experience connectivity issues after accepting the connection, verify that the > private space CIDR range is included in the inbound rules of the AWS security group attached > to your endpoint service (for example, your load balancer or target instances). See the Custom > Services steps in [Configure the Outbound Connections](#configure-the-outbound-connections). ## Use the Private Link After establishing Private Link connections with **Available** status, the VPC endpoint API returns DNS entries for the service. To talk to the S3 endpoint, use this DNS entry: ```json "dnsEntries": [ "*.vpce-0bb8410c774666218-yajqbur2.accesspoint.s3-global.us-east-1.vpce.amazonaws.com", "*.vpce-0bb8410c774666218-yajqbur2-us-east-1d.accesspoint.s3-global.us-east-1.vpce.amazonaws.com", "*.vpce-0bb8410c774666218-yajqbur2-us-east-1a.accesspoint.s3-global.us-east-1.vpce.amazonaws.com", "accesspoint.s3-global.amazonaws.com", "*.accesspoint.s3-global.amazonaws.com" ] ``` To talk to the private connect, use this DNS entry: ```json "dnsEntries": [ "vpce-06b4ba2047c41be17-1lnhhl4b.vpce-svc-03fa74d9c231a52aa.us-east-1.vpce.amazonaws.com", "vpce-06b4ba2047c41be17-1lnhhl4b-us-east-1d.vpce-svc-03fa74d9c231a52aa.us-east-1.vpce.amazonaws.com", "vpce-06b4ba2047c41be17-1lnhhl4b-us-east-1a.vpce-svc-03fa74d9c231a52aa.us-east-1.vpce.amazonaws.com" ] ``` To talk to the custom service, use this DNS entry: ```json "dnsEntries": [ "vpce-0d971d98cb910b3b1-oyattu6z.vpce-svc-03cef49533264d928.us-east-1.vpce.amazonaws.com", "vpce-0d971d98cb910b3b1-oyattu6z-us-east-1d.vpce-svc-03cef49533264d928.us-east-1.vpce.amazonaws.com" ] ``` ## Entitlements Each VPC endpoint consumes one network connection entitlement per AZ. > [!NOTE] To configure high availability, set up the Private Link connection with at least two > availability zones. This consumes two network connection entitlements. ## Limitations - Outbound connections have a contractual limit of 56.48 GB of data transferred per root organization per hour. - This configuration supports [interface VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html#vpce-interface) only (PrivateLink to AWS services or to a [VPC endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html), for example a service you expose behind a load balancer). It does not support [resource VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/use-resource-endpoint.html) (the **Resources** endpoint type that uses resource configurations instead of a service name). - This configuration doesn’t support CloudHub VPCs. - This configuration doesn’t support CloudHub 2.0 private spaces that are [upgraded from CloudHub VPCs](https://docs.mulesoft.com/cloudhub/vpc-upgrade). - Network connections are subject to these limits: - VPNs per private space: 10 - TGW per private space: 5 - VPC endpoints per private space: 20 ## See Also - [Obtaining an API Bearer Token Using a SAML Assertion](https://docs.mulesoft.com/access-management/saml-bearer-token) - [How to generate your Authorization Bearer token for Anypoint Platform](https://help.salesforce.com/s/articleView?id=001115323&type=1) --- product: CloudHub 2.0 --- # Shared Spaces > For the full documentation index, see: https://docs.mulesoft.com/llms.txt A _shared space_ is an elastic cloud of resources that includes Mule instances running in a multi-tenant environment. CloudHub 2.0 provides one shared space in each supported [region](https://docs.mulesoft.com/cloudhub-2/ps-gather-setup-info#private-network-region), to which you deploy your integration applications. Deploying to a shared space requires no setup or maintenance of the underlying infrastructure. You can deploy apps to the shared space in a region if: - You don’t require isolation from the public cloud. - Your apps don’t need to connect to an on-premises data center. - Your apps can use the `cloudhub.io` domain name (rather than a vanity domain name). - You don’t need to configure custom certificates. Any of the following features and functionality requires a private space: - Single-tenancy for your apps - Network connection (VPN or transit gateway attachment) to a data center - Vanity domain names - Custom certificates - Private endpoints - Static application source IP addresses ## See Also - [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about) --- product: CloudHub 2.0 --- # 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 private spaces, 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 2.0, you can take advantage of this network simplification by securely attaching your private space 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. To use transit gateway attachments, your private space and AWS Transit Gateway must be in the same region. ![Transit Gateway Overview](/mulesoft/current/en-us/cloudhub-2/_images/ps-overview-tgw.png) To attach your private space to your transit gateway, see [Create a Connection to an External Network](https://docs.mulesoft.com/cloudhub-2/ps-create-configure#create-connection-to-external-network). ## Limitations The following limits 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 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. ## See Also - [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 --- product: CloudHub 2.0 --- # Updating Apps Deployed to CloudHub 2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When deploying an application to CloudHub 2.0, Runtime Manager automatically versions and creates a new _configuration_. Application configurations enable you to: - View the configuration change history of the application. - Roll back the configurations to an earlier version if the currently applied configuration has issues or is unstable. - View the application status. Possible values are: Running At least one replica is receiving traffic (Started state). Not running None of the replicas are receiving traffic. Unknown The target is disconnected. When this value appears, there is a MuleSoft-related outage or incident. - Make updates to a deployed application’s configuration, including: - Application file - Application deployment package version - Deployment target settings, such as runtime version, number of replicas, and whether the application is running in cluster mode - Endpoint and TLS settings - Resource allocations, including CPU and memory - App property values - View logs and diagnostics associated with a configuration. ## Update App Settings 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Settings**. 4. Click **Configuration** to display the app configuration history: Config changes tab Shows the changes to the successfully deployed application configuration and includes the last 10 configuration deployments in order by configuration creation date. A unique hash identifies each configuration in the history. All changes tab Shows a history of versions created from the configuration deployment and the actions performed on each version. 5. Depending on the deployment target (shared or private space), change the deployed configuration: - Specify runtime options, such as uploading a new application file or changing the deployment target and resource allocation. - View the app’s current version. - Change the endpoint for the app. - Change app behavior with properties. - Disable or enable app logs and specify log levels. 6. Click **Apply Changes**. A message appears at the top of the page indicating the configuration is in progress. 7. Click **View status** to view the [status](#replica-statuses) for each replica in the deployment. When the configuration is successfully applied and deployed, a message appears at the top of the page, with application status, configuration identifier, completed date, and replica status. The new configuration appears in the **Config changes** list. If the configuration updates fail to deploy, the message indicates that CloudHub 2.0 didn’t apply the configuration, the configuration status is `Update failed`, and the configuration appears in the **Config changes** history without a label. In failure cases, the deployment attempts to roll back to the last successful version of the configuration. In some situations, the rollback might not succeed, and the configuration status is `Update failed`. ## Replica Statuses Started The replica is receiving traffic. Pending The replica is waiting to start. Starting The replica is starting. Deleting The deletion of the replica is in progress. Deleted The replica was deleted. Stopping The replica is stopping. Stopped The replica has stopped (it is not receiving traffic). Failed The configuration failed to deploy. Recovering: The replica is attempting to restart after terminating. The last successfully deployed configuration is retained until the new (desired) configuration is successfully deployed. Applying The previous configuration of the replica is running, and new configuration settings are in the process of being implemented. You can configure a _desired state_ that indicates your ideal state of the replica. For example, if you expect the replica to be running, you can set the desired state to `running`. ## Rolling Update vs. Recreate Deployment Model Depending on the deployment model, CloudHub 2.0 applies new configurations as either: - Rolling updates Maintain availability by incrementally updating replicas. This model means zero downtime while CloudHub 2.0 applies updates to the application. Because CloudHub 2.0 applies updates as rolling updates, different application versions run simultaneously until the update completes. For this reason, ensure that your applications can run multiple versions in parallel. - Recreate Terminate replicas before redeployment. Redeployment is quicker and doesn’t require additional resources. ## Roll Back to a Previous Successful Configuration If a deployed configuration has issues, you can roll back to a previous successful version of the configuration. > [!NOTE] If this is the first deployment of the application, the rollback version isn’t defined. In > case of a failed deployment, the application remains in the failed status. 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Settings**. 4. Click **Configuration** to display the app configuration history. 5. Select the version to which to roll back from the **Config changes** history. To change the runtime version of a previously used configuration, select the desired version from the **Runtime Version** dropdown list. You can change any other configuration before deploying. 6. Click **Deploy**. The configuration moves to the top of the **Config changes** history list and displays the new deployment date, and it retains its original identifying hash. > [!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. ## See Also - [Deploying Apps to Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-shared-space) - [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space) - [Changing App Behavior with Properties](https://docs.mulesoft.com/cloudhub-2/ch2-manage-props) - [Viewing Log Data for Deployed Apps](https://docs.mulesoft.com/cloudhub-2/ch2-view-logs) - [Generating Apps Diagnostics and Analyzing with Einstein](https://docs.mulesoft.com/cloudhub-2/ch2-view-diag) - [Managing App Schedules](https://docs.mulesoft.com/cloudhub-2/ch2-manage-schedules) --- product: CloudHub 2.0 --- # Viewing Log Data for Deployed Apps > For the full documentation index, see: https://docs.mulesoft.com/llms.txt CloudHub 2.0 provides access to log data that includes deployment messages and events for each replica and Mule runtime engine logs. For more advanced searching and log management, you can use Anypoint Monitoring (requires Titanium subscription). See [Anypoint Monitoring Overview](https://docs.mulesoft.com/monitoring/). CloudHub 2.0 stores up to 100 MB of log data per config, or up to 30 days, whichever limit is reached first. Logs are stored in the same region to which the corresponding cluster is deployed. > [!NOTE] CloudHub 2.0 stores log data in Universal Time (UTC); however, the console displays the > log using your computer’s local time zone. ## View Logs To view logs for applications deployed to a private space: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Logs**. The logs page displays all logs for all replicas for the selected config, with the latest messages at the bottom. The config represents the deployment since the last update. > [!NOTE] When you update an application, a new configuration is created. In this case, the logs > page might be empty. The page streams log messages as they occur, unless the last deployed section is closed. Logs from before the last updated time appear in a drop-down containing previous deployments. Each message includes the severity, time (relative and absolute), and replica name. To view logs for a different config, click the **Config** drop-down list and select the config. The config label indicates the relative time of deployment, such as 10 hours ago. ## Search Logs To search within the currently displayed config: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Logs**. 4. Enter the search term in the **Search** field. The results display includes the currently selected config, replica, and log levels. You can search with queries. For more information, see [Log Search Query Syntax](https://docs.mulesoft.com/cloudhub-2/ch2-log-search-syntax). ## Filter Logs To filter the log results: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Logs**. 4. Select filter options: - Filter logs by config ID Click the **Config** drop-down menu and select the config to view. - **Filter log by replica** In a log message for the desired replica, click the name of the replica. Only the logs for the selected replica appear. To clear the replica filter and display logs for all replicas, click the **X** button for the selected replica. - **Filter logs by time date and time range** Click **Time Range**, select the date range, and optionally time, and click **Apply**. The **Time range** button label changes to show the selected date and time range. - **Filter logs by log level** Click **Log Levels** and check the log levels to display: - **Fatal**: Fatal messages for when an application fails - **Error**: Error messages, such as when an exception occurs - **Warn**: Warning messages - **Info**: Informative messages - **Debug**: Debugging messages > [!NOTE] Some log levels might not be available depending on the dynamic log level setting > for the deployment. The **Log Levels** button label changes to show the selected number of log levels. ## Download Logs To download logs based on the current filters: 1. From Anypoint Platform, select **Runtime Manager** > **Applications**. 2. Click the app name. 3. In the navigation menu, click **Logs**. 4. Click the download button. CloudHub 2.0 downloads the log output, using the current filters, using a hexadecimal naming convention and the `log` format, for example: `c6c671_462ccf_2022-07-21T20-08-32X.log`. Use a text editor to view the log file. ## See Also - [Generating Apps Diagnostics and Analyzing with Einstein](https://docs.mulesoft.com/cloudhub-2/ch2-view-diag) - [Updating Apps Deployed to CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps)