Contact Us 1-800-664-9073

CloudHub 2.0 for CloudHub 1.0 Users

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.

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 public and private endpoints by default. You can also configure multiple public 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 1.0, application names had to be unique, globally, per region. In CloudHub 2.0, the same application name can be used in different deployments in the same private space as long as they are in different environments or organizations.

  • Custom log4j.xml is supported by default to enable streaming logs 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 private endpoint. Note that 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.

CloudHub 2.0 does not support the following infrastructure features or functions that CloudHub 1.0 supports:

Application Considerations

CloudHub 2.0 application behavior deviates from CloudHub 1.0 in the following ways:

  • Only Mule 4.3.0 through 4.4.x 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 for persistent queues and other queue management. Persistent queues are not supported.

  • HTTP and HTTPS inbound protocols are supported. Inbound protocols that are not HTTP-based are not supported.

  • Private endpoints do not offer mTLS capabilities as internet-facing public endpoints.

  • In Anypoint Monitoring, you must set alerts for apps individually. Setting alerts for all apps simultaneously is not supported.

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

View on GitHub