CloudHub 2.0 signifies a major advancement in MuleSoft’s cloud integration platform by introducing a container-based architecture built on Kubernetes.
This modern approach offers increased scalability, stronger security, and improved management capabilities compared to CloudHub 1.0. Although CloudHub 1.0 is still fully supported, CloudHub 2.0 now serves as the standard deployment choice for new applications.
Key Benefits of CloudHub 2.0
- Seamless Mule clustering for deployments with more than one replica
- Container-based application deployment to regulate resource consumption, ensure application availability, and enable scalability
- More granular vCore allocation options
- Outbound firewall rule configuration
Architectural Comparison
CloudHub 1.0 Architecture
CloudHub 1.0 uses a VM-based infrastructure with two major components: Anypoint platform services and the worker cloud. Applications run on dedicated virtual machines called workers.
CloudHub 2.0 Architecture
CloudHub 2.0 leverages an orchestrated container platform and service-oriented architecture based on Kubernetes, with two major components: Anypoint Platform services and shared global regions.
Applications run as replicas - dedicated instances of Mule runtime engine that run in separate containers.
Key Feature Differences
1. Application Deployment Model
| Feature | CH 1.0 | CH 2.0 |
| Deployment Unit | Workers (VMs) | Replicas (Containers) |
| Clustering | Not supported - only HA via load balancer | Fully managed Mule clustering |
| Deployment Time | 2-3 minutes | 30 seconds |
| Update Strategy | Rolling updates only | Recreate or rolling update |
2. Resource Allocation
| Feature | CH 1.0 | CH 2.0 |
| vCore Options |
0.1, 0.2, 1, 2, 4, 8, 16 vCores |
0.1, 0.2, 0.5, 1, 1.5, 2, 2.5, 3, 3.5, 4+ vCores |
|
Memory for 0.2 vCore |
1 GB |
2 GB |
|
Memory for 0.1 vCore |
~480 MB |
480 MB (heap) |
|
Resource Management |
Fixed allocation |
Fractional vCore allocation with greater precision |
3. Networking and Connectivity
| Feature | CH 1.0 | CH 2.0 |
| Network Isolation |
VPC (Virtual Private Cloud) |
Private Spaces (evolution of VPC) |
|
Load Balancer |
Dedicated Load Balancer (DLB) |
Ingress Controller with auto-scaling |
|
Static IPs |
Per application |
Per private space (shared across apps) |
|
Connectivity Options |
VPC Peering, Direct Connect, VPN |
Transit Gateway, VPN (Direct Connect and VPC Peering deprecated) |
|
Firewall Rules |
Inbound only |
Inbound and outbound firewall rules |
|
HTTP/HTTPS Ports |
Configurable |
Port 8081 only |
4. Security and Monitoring
| Feature | CH 1.0 | CH 2.0 |
|
TLS Support |
TLS 1.0, 1.1, 1.2, 1.3 |
TLS 1.2, 1.3 only (1.0 and 1.1 not supported) |
|
Secure Properties |
Viewable by users |
Stored in encrypted private vaults, not viewable by users or MuleSoft staff |
|
Load Balancer Logs |
Not supported |
Supported (download) |
|
Application Insights |
Supported |
Not supported - use Anypoint Monitoring instead |
|
Custom Notifications |
Supported |
Not supported |
5. Application Management
| Feature | CH 1.0 | CH 2.0 |
|
Application Naming |
Unique per control plane |
Unique per private space |
|
Grace Period |
2 minutes |
5 minutes |
|
Mule Version Support |
Mule 3.x and 4.x |
Mule 4.3.0 and later only |
|
Persistent Queues |
Supported |
Not supported - use Anypoint MQ instead |
|
Log Streaming |
Manual configuration |
Custom log4j.xml supported by default |
|
Scheduler Management |
UTC timezone only, changes on the fly |
Configurable timezone, requires restart for changes |
Deployment Spaces Comparison
CloudHub 1.0
- Single deployment model to workers
- VPC for network isolation
- Manual load balancer configuration
CloudHub 2.0
CloudHub 2.0 introduces two deployment options:
Shared Spaces:
- Multi-tenant environment for applications that don't require network isolation
- No advanced setup required
- One shared space per supported region
Private Spaces:
- Virtual, private, and isolated areas for applications requiring network connectivity
- Evolution of VPC from CloudHub 1.0
- Automatic load balancer assignment
- Support for multiple environments and business groups
Performance and Scalability
CloudHub 1.0
- No real clustering concept
- Horizontal scaling through multiple workers
- Persistent queues for load distribution
CloudHub 2.0
- True clustering with replica scale-out for horizontal scalability and reliability
- Intelligent healing and automatic application restart
- Application bursting depends on resource usage of other applications in private space
- Zero-downtime updates with rolling deployment model
Limitations and Considerations
CloudHub 2.0 Limitations
CloudHub 2.0 does not support several features available in CloudHub 1.0:
Infrastructure Limitations:
- No VPC peering or Direct Connect support
- Cannot create VPN connections between CloudHub 1.0 VPC and CloudHub 2.0 private space
- No automatic migration path from CloudHub 1.0 infrastructure
Application Limitations:
- No persistent queues support
- Only HTTP, HTTPS, and TCP inbound protocols supported
- No custom notifications or CloudHub Connector support
- No JVM parameter overwriting
- Applications consume vCore licenses even when not running
Migration Considerations
Prerequisites for Migration
For applications migrating from CloudHub 1.0 to CloudHub 2.0:
- API Specification Naming: Ensure API Specification and API Implementation have different names
- Port Configuration: Update applications to use port 8081 for HTTP/HTTPS traffic
- Infrastructure Setup: Create and configure new private spaces, set up new VPNs
- Mule Version: Ensure applications use Mule 4.3.0 or later
Migration Strategy
If you have a large network of applications, it’s helpful to move over in phases instead of all at once, so you can minimize any bumps along the way. The good news is you can run CloudHub 1.0 and 2.0 side by side and share vCore resources as you transition.
Pricing and Cost Implications
Resource Efficiency
- CloudHub 2.0 is less resource intensive than CloudHub 1.0
- Fractional vCore offerings may eliminate need to bundle multiple listeners in same application
- More granular resource allocation optimizes utilization and minimizes waste
Usage-Based Pricing
Organizations with usage-based pricing packages use replica sizing for CloudHub 2.0 deployment, showing flows, messages, and throughput entitlements instead of vCores.
Recommendations
Choose CloudHub 1.0 When:
- Applications require persistent queues
- Using Mule versions prior to 4.3.0
- Need Direct Connect or VPC peering connectivity
- Require custom notifications or CloudHub Connector
- Applications use non-HTTP/TCP inbound protocols
Choose CloudHub 2.0 When:
- Building new applications
- Need true clustering capabilities
- Require outbound firewall rules
- Want improved resource allocation granularity
- Need faster deployment times (30 seconds)
- Require enhanced security with encrypted property vaults
Migration Timeline
CloudHub 1.0 will remain fully supported for the foreseeable future with no announced end-of-life plan. Organizations can adopt a gradual migration strategy, moving applications individually as they meet CloudHub 2.0 requirements.
Conclusion
CloudHub 2.0 is like giving your applications a first-class upgrade—trading in their tired old VM seats for sleek, containerized pods with more legroom, better clustering, and top-tier security. Sure, it’s got a few quirks compared to its predecessor, but the promises of lightning-fast deployments, smoother scaling, and resource efficiency make it the VIP lounge of cloud platforms for new and adaptable apps.
It’s a good idea to take a close look at your current applications and compare them to what CloudHub 2.0 offers—along with its few limitations—so you can create a migration plan that helps you enjoy the benefits of the new platform while keeping everything running smoothly for your business.
🔊Shout out to all the muleys!🔊
I’m putting together a small mastermind group for experienced MuleSoft devs and architects—those who want to stay sharp, grow their careers, and connect with others at their level.
If you are interested to hear more, register for the waitlist.