Compare CloudHub and CloudHub 2.0

The CloudHub architecture includes two major components: Anypoint Platform services and a multitenant cloud of virtual machines distributed across global regions where your applications run. Individual instances of an application are called workers. CloudHub uses a VM-based infrastructure.

The CloudHub 2.0 architecture includes two major components: Anypoint Platform services and a multitenant cloud of containerized replicas distributed across global regions where your applications run. Individual instances of an application are called replicas. CloudHub 2.0 uses a container-based infrastructure.

A Virtual Private Cloud (VPC) is a virtual, private, and isolated cloud network segment for hosting CloudHub workers.

A private space is a virtual, private, and isolated logical space in CloudHub 2.0 for running Mule apps.

Static IPs are managed per application, not at the VPC level. Turn on Static IPs for individual apps to receive their own set of egress static IPs.

Static IPs are provisioned at the private space level. All applications in the same private space share these outbound static IPs.

CloudHub provides a Shared Load Balancer (SLB) by default for all apps. The Dedicated Load Balancer (DLB) is optional, and you create and configure it within the VPC.

CloudHub 2.0 automatically provisions a fully managed ingress load balancer for the private space.

TLS/SSL certificates require manual configuration. The SLB uses the platform’s wildcard certificate. For custom domains, create a DLB and upload PEM-encoded certificates and private keys.

CloudHub 2.0 automatically creates a default TLS context for the private space with wildcard certificates for both internal and public endpoints. You can configure custom vanity domains with your own TLS context for both internal and external endpoints.

A VPC is associated with a single environment.

A private space can be associated with multiple environments based on the environment type (sandbox or production). You can choose which environment types and individual business groups share a private space.

To move an application to a different region, redeploy it to a VPC in the target region.

To move an application to a different region, redeploy it to a shared space or private space in the target region. You cannot move an application to a different region once deployed.

VPCs support VPN connections, VPC peering, and static IPs.

Shared spaces don’t support VPN connections, transit gateway attachments, static IPs, or HTTP traffic on port 80. To use these features, deploy to a private space.

Contact the MuleSoft Support team to enable VPC peering and AWS Direct Connect.

CloudHub 2.0 supports Transit Gateway or VPN tunnel.

When upgrading a VPC to a private space, VPN and TGW connections transfer to the private space, but VPC peering is not migrated and can’t be reused. CloudHub 2.0 apps can’t use CloudHub VPC peering — migrate peering connections to Transit Gateway or VPN before upgrading.

Ping tests are supported by the Network Tools application.

CloudHub adds firewall rules automatically when you create a VPC.

CloudHub 2.0 adds firewall rules automatically when you create a private space.

By default, all traffic to a VPC is blocked unless explicitly allowed by a firewall rule. However, CloudHub automatically creates four default inbound firewall rules when you create a VPC.

By default, inbound traffic is blocked unless explicitly allowed by a firewall rule. However, CloudHub 2.0 automatically creates default rules allowing HTTP (80) and HTTPS (443) from 0.0.0.0/0, and a default rule allowing all outbound egress traffic.

CloudHub supports HTTP, HTTPS, and TCP protocols. The Dedicated Load Balancer (DLB) also supports WebSockets (ws and wss).

CloudHub 2.0 supports HTTP, HTTPS, and TCP protocols. The upgrade tooling does not support TCP traffic migration yet.

The maximum number of firewall rules is approximately 35 per VPC, depending on the number of rules CloudHub requires.

The maximum number of inbound firewall rules is 300.

CloudHub doesn’t support egress firewall rules. It allows all outbound traffic by default.

CloudHub supports static IP addresses at the application level.

CloudHub 2.0 supports static IP addresses at the private space level.

If you turn on Static IPs for an application, CloudHub provides outbound static IPs.

CloudHub 2.0 provides inbound and outbound static IPs at the private space level.

Applications deployed to the same VPC don’t automatically share static IPs. If you turn on Static IPs for an application, it receives its own set of outbound static IPs. Inbound static IPs are available only through a DLB, and all applications behind the same DLB share them.

Applications deployed to the same private space use the same set of inbound and outbound static IPs. To have unique static IPs per application, use a different private space.

CloudHub 2.0 automatically provides a fully managed ingress load balancer for each private space with a simplified architecture that removes the need to select or create load balancers.

CloudHub load balancers provide round-robin load distribution across workers.

CloudHub 2.0 provides a fully managed ingress load balancer for each private space that automatically balances inbound traffic across multiple application replicas. The ingress load balancer auto-scales to accommodate traffic. You can configure this load balancer to meet your specific requirements.

CloudHub doesn’t support load balancer logs for the DLB. The SLB has no log access.

Download ingress traffic logs from Runtime Manager for full visibility into ingress traffic and troubleshooting.

You can assign up to four load balancer units to a Dedicated Load Balancer (DLB) for high availability and load distribution. The Shared Load Balancer (SLB) provides fully managed high availability with no customer configuration required.

CloudHub 2.0 automatically distributes application replicas across two or more availability zones (AZs) for built-in high availability and fault tolerance. If you use the VPC upgrade tool, the private space inherits the same number of AZs as the original CloudHub VPC.

SSL/TLS termination

SSL termination happens at the DLB layer.

SSL termination happens at the ingress load balancer layer.

Certificate management

Upload PEM-encoded certificates and private keys manually. Limited CA certificate support.

Default TLS context with wildcard certificates created automatically. Custom vanity domains supported with your own TLS context. Dynamic certificate management with in-place updates without redeployment.

URL rewriting

Configured at the DLB level using mapping rules.

Configured at the application level using domains and endpoints for per-app configuration.

Mutual TLS (mTLS)

DLB handles mTLS at the infrastructure level, performing client certificate validation and forwarding certificate information to apps through HTTP headers. An optional mode performs client certificate validation but still passes the request through if the check fails. Accepts certificate files in PEM format only.

Native mTLS with TLS contexts and truststores. Configure mTLS at the private space level with centralized management. Supports forward SSL. Upload truststore files in PEM and JKS formats. Optional mTLS mode is not supported — client certificate validation either passes or the request is rejected.

Protocols

HTTP, HTTPS, TCP, WebSockets (ws and wss)

HTTP, HTTPS, TCP. TCP traffic is supported only on newly created private spaces. Upgraded private spaces do not support TCP traffic. If you require TCP, create a new private space.

Logging

No DLB log support.

Download ingress traffic logs from Runtime Manager.

High availability

Up to four load balancer units.

Auto-scales to accommodate traffic. Replicas are automatically distributed across two or more availability zones (AZs).

Path-based routing

Mapping rules define an Input Path (supports patterns with {variables}), a Target App, and an Output Path (literal only). The first matching rule wins (priority-ordered). Example: /api/v1/ → my-app with output /.

Each application configures its own endpoints with a Path (where clients reach the app) and a Path Rewrite (the base path the HTTP Listener expects). Configured per-app in the Ingress tab. No global priority ordering needed — each app owns its endpoint.

Host-based routing

DLB uses certificate endpoints (CN or SANs) to match hosts. A wildcard certificate (*.example.com) combined with a {subdomain} variable in the mapping rule routes api.example.com to the api app.

CloudHub 2.0 uses Domains configured via TLS contexts at the private space level. Each app selects its domain from a dropdown and specifies a subdomain. Supports the app-name placeholder to auto-resolve. Multiple endpoints per app are supported.

URL rewriting

Configured at DLB level. Input Path defines the client-facing path; Output Path defines what is passed to the app. Patterns only in Input Path; Output Path is always literal.

Configured at app level via Path and Path Rewrite fields. Path is the client-facing URL; Path Rewrite is the internal path for the HTTP Listener.

Multi-app routing on one domain

Single DLB can route to multiple apps via ordered mapping rules on the same SSL endpoint. Pattern variables ({app}, {layera}, {domaina}) enable dynamic routing.

Each app registers its own endpoint(s) on shared domains. No global rule list — each app’s endpoint is independent. Use unique paths or subdomains to differentiate.

Protocol selection

Mapping rules specify upstream protocol per rule: http (port 8091), https (port 8092), ws (8091), wss (8092).

CloudHub 2.0 apps listen on port 8081 for both HTTP and HTTPS. Protocol is determined by TLS context configuration, not per-rule. WebSocket support via HTTP/HTTPS endpoints.

Wildcard matching

Pattern variables ({variable}) in Input Path match a-z0-9.&?-_ (no slashes). Priority order controls which rule matches.

Subdomain placeholders (app-name, business-group-id, environment-id) provide dynamic matching. No regex or custom variable patterns.

Access logs

No DLB access log support. Logging limited to application-level logs.

Ingress traffic logs available for download from Runtime Manager. Logs include request source IP, response codes, and latency data.

Log access

N/A

In Runtime Manager, go to your private space > Logs to download ingress traffic logs.

Application logs

Available via Runtime Manager or Log4j integration.

Available via Runtime Manager or Log4j integration. See Integrating with Your Logging System Using Log4j.

Monitoring

Custom alerts based on application metrics.

Anypoint Monitoring with built-in dashboards. Custom alerts on ingress-level and application-level metrics.

Internet ingress

External clients send HTTPS traffic on port 443 to the Dedicated Load Balancer (DLB).

External clients send HTTPS traffic on port 443 to the ingress load balancer.

Load balancing and routing

The DLB terminates TLS and applies ordered mapping rules.

The ingress load balancer terminates TLS and routes requests by domain and path.

Application runtime

Workers receive HTTP or HTTPS traffic on ports 8091 and 8092.

Replicas receive traffic on port 8081.

Connectivity during migration

Workers accept inbound calls from CloudHub 2.0 over the 100.64.0.0/16, 100.66.0.0/16, 100.67.0.0/16, and 100.68.0.0/16 ranges, provided those ranges are added to the DLB allowlist.

Replicas can call CloudHub 1.0 workers through the DLB using those same ranges, and connect to on-premises or AWS systems through the Transit Gateway using the private space CIDR.

Outbound traffic

Workers reach backend systems through the VPC network and Transit Gateway.

Replicas use the NAT Gateway when backend systems require outbound static IP addresses.

Backend connectivity

Both environments connect to backend systems, such as databases and SaaS APIs, through the Transit Gateway.

DNS resolution

The client requests myapp.example.com, which resolves to [lb-name].lb.anypointdns.net.

The client requests myapp.example.com, which resolves to [space-id].[region].cloudhub.io.

TLS and routing

The DLB terminates TLS and evaluates its mapping rules.

The ingress load balancer terminates TLS and matches the configured domain and path.

Application request

The DLB sends HTTP traffic to the CloudHub worker on port 8091.

The ingress load balancer sends HTTP traffic to the CloudHub 2.0 replica on port 8081.

Idle connection timeout

300 seconds (default). If no data is sent or received within this duration, the DLB closes the connection.

15 seconds (hardcoded, not configurable). For each request, the load balancer maintains two connections (client→LB and LB→app). If no data is sent or received on either connection within this duration, the load balancer closes both connections.

Keep-alive timeout

60 seconds. Connections are closed after new workers come online and the DNS TTL (30 seconds) expires.

Not separately configurable. Governed by the idle connection timeout.

Read-request timeout

Included in the 300-second idle timeout window.

300 seconds (hardcoded, not configurable). The maximum time the ingress controller waits to receive the complete request from the client. Applies to both shared and private spaces.

Read-response timeout

Included in the 300-second idle timeout window.

300 seconds by default. Configurable up to 3,600 seconds (1 hour) via Read Response Timeout in the Advanced tab of your private space settings. This is the time the ingress controller waits for a response from your Mule application.

SSL termination happens at the DLB layer.

SSL termination happens at the ingress load balancer layer.

The communication between the DLB and the Mule application is internal to the VPC.

Applications inside a private space communicate using the ingress load balancer via the internal endpoint. This depends on the application protocol.

An application can have multiple endpoints, depending on the domain and TLS context configuration.

CloudHub doesn’t provide native mutual TLS (mTLS) capability. The Dedicated Load Balancer (DLB) handles mTLS at the infrastructure level, performing client certificate validation and forwarding certificate information to applications via HTTP headers.

CloudHub 2.0 provides native mTLS with TLS contexts and truststores. Configure mTLS at the private space level with centralized management. CloudHub 2.0 also supports forward SSL, which forwards client certificate information to applications via HTTP headers.

CloudHub supports limited Certificate Authority (CA) certificates through the DLB. It accepts certificate files in PEM format only.

CloudHub 2.0 provides dynamic certificate management, application-level truststore access, and in-place updates without redeployment. Upload truststore files in PEM and JKS formats.

Implement URL rewriting at the DLB level using mapping rules. Configure a DLB to use this feature.

Implement URL rewrite at the application level using domains and endpoints for a more flexible, per-app configuration.

The internal worker hostname mule-worker-internal-<app>.<region>.cloudhub.io resolves to the Mule worker’s internal IP address for VPC-internal communication.

CloudHub persistent queues store VM queue messages externally to the application. Use this feature mainly with VM components. Turn on CloudHub persistent queues on a per-application basis.

CloudHub 2.0 doesn’t support persistent VM queues. All VM queue storage is ephemeral and lost on application restart or redeploy. For persistent messaging, use Anypoint MQ, which provides persistent message storage in cloud infrastructure. Anypoint MQ provides asynchronous message processing, event-driven architectures, and cross-application communication. Configure Anypoint MQ on a per-application basis with automatic scaling and high availability.

For batch jobs that used persistent queues in CloudHub, batch jobs in CloudHub 2.0 use Object Store v2 by default with no code changes required.

During deployment, CloudHub automatically replaces the application archive’s log4j2.xml file with a predefined template. CloudHub uses the original log4j2.xml file only when you disable CloudHub logs.

CloudHub 2.0 merges the log4j2.xml configuration file from the application archive with predefined appenders. These appenders send logs directly to Runtime Manager and Anypoint Monitoring, preserving custom appenders while enabling platform integration.

Download the application and runtime logs separately.

CloudHub 2.0 merges application and runtime logs into a single log stream. To find runtime logs, download the application log and check for runtime-related messages.

CloudHub stores logs in the region where it was first deployed. If you move the app to another region, the logs remain stored in the initial deployment region. To reset this log retention configuration, delete and re-create the app.

CloudHub 2.0 stores logs in the region where the application is currently deployed. You can’t move the app to a different region once deployed. To reset this log retention configuration, delete and re-create the app.

CloudHub has limited control over log forwarding.

For more information, see CloudHub 1.0 Logging FAQ

For more information, see CloudHub 2.0 Logging FAQ

Use maven and pom.xml configuration to deploy applications to CloudHub. See Deploy Applications to CloudHub Using the Mule Maven Plugin.

The maximum size of a Mule application (ZIP or JAR) file is 200 MB.

The maximum size of a Mule application JAR file is 350 MB.

Names are unique per control plane.

The DLB supports a maximum HTTP POST (payload) size of 200 MB.

The maximum HTTP request size is 1 GB.

Use Get From Sandbox to promote an application from sandbox to production.

Get From Sandbox is not supported. Use CI/CD pipelines or the Mule Maven Plugin to promote applications between environments.

You can overwrite JVM parameters and override default JVM truststores with custom truststores.

Overwriting JVM parameters and overriding default JVM truststores with custom truststores are not supported.

See CloudHub Workers.

See CloudHub 2.0 Replicas.

A worker in CloudHub is a dedicated Amazon Elastic Compute Cloud (EC2) virtual machine instance that runs your Mule application. It functions as a full, independent virtual server with its own operating system, memory, CPU resources, and isolated runtime environment.

A replica in CloudHub 2.0 is a dedicated, containerized instance of Mule runtime engine that runs your integration application. Each replica provides complete isolation between applications with its own isolated environment, allocated memory (heap and total), CPU resources (vCores), and storage capacity.

If you select Automatically restart application when not responding, CloudHub monitors the worker and automatically restarts the application if necessary.

CloudHub 2.0 provides self-healing capabilities that automatically recover applications from both Mule process failures and underlying infrastructure failures. If either the Mule process or the infrastructure fails, CloudHub 2.0 automatically restarts the application on healthy infrastructure without your intervention. Application crash recovery is enabled by default.

Applications have a two-minute grace period before being marked as failed during startup.

Applications have a five-minute grace period before being marked as failed during startup. For more information, see Grace Period.

Application bursting allows workers to temporarily exceed their allocated vCores during traffic spikes.

Application bursting depends on the resource usage of other applications deployed in the private space and is not guaranteed.

CloudHub doesn’t support Mule clustering. You can run multiple workers for scale and High Availability (HA), but they’re independent runtimes without cluster semantics. There’s no distributed in-memory state or cluster-aware components.

CloudHub 2.0 supports Mule clustering. Multiple replicas of the same app form a managed cluster, enabling cluster-aware runtime behavior. This includes shared memory and distributed locking across runtime replicas. Clustering is active-active — all replicas process regular application traffic — but schedulers and polling sources are primary-only: only the primary replica runs them, and a secondary replica takes over if the primary goes down. Without clustering enabled, every replica runs schedulers and polling sources independently, which causes duplicate executions.

CloudHub scales applications by deploying multiple workers (up to eight) for each application. The SLB automatically distributes traffic across these workers. For applications that need shared state, store that state externally (for example, in a database or Object Store). Workers can’t share in-memory state.

CloudHub 2.0 scales applications by deploying multiple replicas (up to sixteen) for each application. The platform’s cluster mode coordinates behavior across these replicas automatically. For applications with stateful requirements, use Mule’s native clustered features (such as clustered object stores and clustered caches) to maintain state across replicas.

CloudHub achieves HA with two or more workers. It supports availability across AZs, and the platform handles failover.

CloudHub 2.0 provides fully managed HA. The platform automatically spreads replicas across two or more AZs, with round-robin HTTP load balancing and cluster-aware recovery. If you use the VPC upgrade tool, the private space inherits the same number of AZs as the original CloudHub VPC.

CloudHub monitors workers and automatically performs restarts. Blue-green deployment at the DLB or SLB layer provides seamless cutover, but this process lacks cluster draining and coordination within the runtime.

CloudHub 2.0 provides orchestrated restarts and rolling updates across replicas. Cluster-aware coordination minimizes impact during upgrades and failures.

You manage worker counts and rely on external stores for shared state.

CloudHub 2.0 provides fully managed clustering. Select replica counts, and the platform handles cluster formation, health, placement, and recovery.

CloudHub triggers custom alerts when your application sends notifications to Runtime Manager using Anypoint Connector for CloudHub (CloudHub Connector). For more information, see Custom Application Alerts.

CloudHub 2.0 enables application deployment success and failure alerts. For custom alerting, CloudHub 2.0 leverages Anypoint Monitoring Alerts. For more information, see Configuring Application Alerts.

In Anypoint Monitoring, you can set alerts for all apps simultaneously.

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

CloudHub Insights provides basic application analytics and visibility.

Insights is not supported. Use Anypoint Monitoring instead for application performance visibility and diagnostics.