Demystifying CloudHub 2.0 Networking

CloudHub 2.0 is the latest version of MuleSoft’s powerful managed runtime platform, designed for seamless deployment of APIs and integrations. Unlike the original CloudHub 1.0, which relied on shared runtime workers within a single AWS region, CloudHub 2.0 offered a better upgrade. It provides a dedicated, isolated infrastructure with more granular control over networking, security, and scalability.

The blog post breaks down the networking intricacies of CloudHub 2.0. Continue reading to understand how it provides enhanced control and scalability for API and integration deployment.

Terminology Changes in CloudHub 2.0

Before moving ahead with the features of MuleSoft CloudHub 2.0 it is important to learn about the terminology changes to better understand the advanced features and architecture. Here are the following updates:

Key features of CloudHub 2.0

To enhance resource management and user experience, MuleSoft’s CloudHub 2.0 has introduced several exciting features. Here’s what’s new:

1. HTTP Load Balancer (Ingress)

The HTTP Load Balancer, now known as the “Ingress Controller”, is the entry point for external traffic to your application. Here’s how it works:

• Intelligent Traffic Distribution: With an NGINX-based HTTP ingress controller, external requests are efficiently routed to your application replicas. It uses a weighted round‑robin algorithm to balance load and ensure zero‑downtime deployments.
• Efficient Connection Lifecycles : For each incoming client request, two TCP connections are maintained: one between the client and ingress, and another between ingress and the Mule runtime. Idle timeouts are set to a default 300 seconds but can be tuned in the Runtime Manager or via application properties.
• Flexible Protocols & Ports:
  • 443 (HTTPS): This is a standard port for secure public traffic termination with TLS offload, ensuring encrypted communication.
  • 80 (HTTP): This port is allowed only in Private Spaces for handling legacy or non-encrypted traffic within your isolated network.
• Customizable TLS Contexts: Gain granular control over TLS configuration at the Private Space level. Administrators can upload certificates, define trusted Cerificate Authorities (CAs), and enforce mutual TLS (mTLS) for last‑mile encryption.
• Simplified Custom Domains: This allows you to easily map your own domain (for e.g. api.example.com) to Mule application. This is done by creating a DNS CNAME record pointing to <app>.<space>.<region>.cloudhub.io and configuring the custom endpoint within your Private Space settings.

2. DNS Record Management

CloudHub 2.0 automates the generation and management of DNS records, simplifying public and internal assessment of your applications.

• Automated Generation: Upon deployment, CloudHub 2.0 automatically issues two essential DNS entries:
  • Public: <app>.<space-id>.<region>.cloudhub.io. This is the address used for external access to your application.
  • Internal: <app>.internal-<space-id>.<region>.cloudhub.io . This is available only within Private Spaces). This address provides secure internal communication between applications within the same private network.
• Resolution Flow:
  • Public DNS records intelligently resolve to the appropriate ingress IP addresses, whether it’s a shared ingress in a Shared Space or a dedicated private ingress in a Private Space.
  • Internal DNS points to the cluster’s service IP, keeping traffic within the VPC.

• TTL & Caching: The default Time-To-Live (TTL) for DNS records is 60 seconds, allowing for quick updates. However, you have the flexibility to override this using custom DNS providers if you have specific legacy caching requirements.

3. Shared Spaces vs. Private Spaces 

CloudHub 2.0 offers two primary deployment environments: Shared Spaces and Private Spaces. Each environment has distinct networking configurations that govern how applications handle inbound (incoming) and outbound (outgoing) traffic.

3.1 Inbound Traffic Flow

Understanding how incoming traffic reaches your applications is crucial for security and accessibility.

Shared Spaces:

• The client sends an HTTPS request to an address like myapp.us-east-1.cloudhub.io.
• “>The first request terminates at the shared ingress pool.
• Ingress controller then forwards the request over HTTP to the appropriate Mule application pods.

Private Spaces:

• An external client initiates a call to your application using the address: 400;”>myapp.<space>.<region>.cloudhub.io (port 443).
• The DNS system resolves this address to the dedicated private ingress IP address associated with the Private Space.
• Custom firewall rules (e.g., allow only 10.0.0.0/16) are evaluated to ensure only authorised traffic can proceed.
• TLS encryption can be either offloaded at the ingress controller or passed through to the application pods based on the configured TLS context.
• Finally, the Traffic is routed to the appropriate Mule application service, using internal DNS if requested.

3.2 Outbound Traffic Flow

Controlling where your applications can send traffic is vital for security and compliance. Let’s understand better by reading ahead:

Shared Spaces:

By default, ‘egress’ from applications in shared spaces is unrestricted. Applications can freely call external APIs or databases without any additional configuration.

Private Spaces

• Outbound requests from applications within Private Spaces are subject to user-defined egress rules. This gives fine-grained control over:
  • Protocol (TCP, HTTP, HTTPS)
  • Destination CIDR or hostname
  • Port or port range
• If an outbound request matches a defined egress rule, the traffic is routed through the configured NAT gateway or transit attachment (like a VPN or Transit Gateway)
• Essential MuleSoft endpoints (e.g., Anypoint Monitoring) are always reachable, ensuring the platform can function correctly.
• For secure communication between APIs within the same organisation, it’s best practice to use internal DNS names to ensure traffic stays within your Private Space and avoids public egress.

4. Region and High-Availability

CloudHub 2.0 is engineered for high availability and resilience, ensuring your integrations remain operational.

• Multi-AZ Deployment: Each CloudHub 2.0 region spans at least two Availability Zones with active-active control planes. This provides redundancy and ensures that if one AZ experiences an issue, the other can seamlessly take over.
• Self‑Healing: Leveraging Kubernetes liveness/readiness probes unhealthy application pods are automatically detected and restarted, minimizing downtime.
• Auto-Scaling:
  • Horizontal Pod Autoscaler (HPA): This feature automatically scales the number of your Mule application pods up or down based on real-time metrics such as CPU utilization, memory consumption, or custom application metrics, ensuring that the application can handle varying loads.
  • Cluster Autoscaler: When the HPA needs to spin up more pods and there isn’t sufficient capacity in the underlying infrastructure, the Cluster Autoscaler automatically adds more worker nodes to your Private Space to accommodate the growth.

5. Advanced Features

CloudHub 2.0 offers several advanced networking capabilities for organization with more complex requirements.

• Service Mesh Integration: In Private Spaces, you can opt into an Istio service mesh for fine‑grained traffic control, mTLS across services, and telemetry. 
• Network Policies: By leveraging Calico CNI policies you can implement even stricter control over pod-to-pod communication within your Private Spaces, enhancing security at a granular network level.
• Egress Controller: For organizations with stringent security or compliance requirements, you can route all outbound traffic from your Private Space through a centralized proxy for monitoring or DLP.

Here’s a detailed diagram on CloudHub 2.0’s Network Architecture:

CloudHub 2.0’s networking architecture equips enterprises with the controls needed to deploy secure, scalable integrations. By understanding ingress and egress paths, DNS resolution, and the distinctions between Shared and Private Spaces, architects can design robust connectivity patterns that align with organizational policies and compliance requirements.

Final Thoughts

CloudHub 2.0 is more than just a platform upgrade — it’s a shift toward cloud-native integration at scale. With powerful new networking capabilities, it offers enterprise-grade flexibility that finally puts IT and security teams in the driver’s seat.

If you’re planning a migration from CloudHub 1.0 or exploring new integration patterns, make networking strategy a top priority — it’s the backbone of everything you’ll build.

Need help architecting your CloudHub 2.0 environment or navigating the networking setup? Drop a comment or reach out — we’re here to talk shop.

Found this useful? Checkout for more Mulesoft Technical Guides from our Resource Centre