MuleSoft Runtime Fabric Overview

Anypoint Runtime Fabric (RTF) is MuleSoft's container-based deployment solution that runs the Mule Runtime on your own Kubernetes cluster. You bring the infrastructure — AWS EKS, Azure AKS, Google GKE, Red Hat OpenShift, or bare-metal Kubernetes — and MuleSoft provides the runtime software and the Anypoint Platform control plane. RTF gives you full infrastructure control while keeping the familiar Anypoint deployment and monitoring experience.

Why Runtime Fabric

RTF solves problems that CloudHub cannot address for some enterprises:

• Data residency: Data never leaves your cloud account or data center.
• Cost optimization: Leverage existing Kubernetes clusters and cloud commitments instead of paying per CloudHub vCore.
• Kubernetes standardization: Use the same deployment tooling your company uses for all other containerized applications.
• Custom networking: Full control over VPCs, security groups, and network policies.
• Air-gapped environments: RTF can run with no internet connectivity using a private image registry.

RTF Architecture

Component Diagram

Anypoint Platform (MuleSoft Cloud — Control Plane)
  ├── Runtime Manager  ← you deploy applications here
  ├── Anypoint Monitoring ← collects metrics from RTF
  └── API Manager      ← applies policies
         │ (secure outbound connection only — no inbound)
         │
         ▼
Your Kubernetes Cluster (Your Infrastructure — Data Plane)
  ├── RTF Agent        ← communicates with Anypoint Platform
  ├── Mule Runtime Containers
  │     ├── orders-api (2 pods)
  │     ├── customer-sync (1 pod)
  │     └── inventory-batch (1 pod)
  ├── Ingress Controller ← routes external traffic to pods
  └── Persistence Layer  ← Object Store, queue data

Key RTF Components

RTF Agent

The RTF Agent is a Kubernetes component installed on your cluster. It maintains a secure outbound-only connection to Anypoint Platform. Through this connection, it receives deployment instructions, reports metrics and logs back, and stays synchronized with the control plane. The agent never requires inbound internet connections — a major security advantage for enterprises with strict firewall rules.

Mule Runtime Containers

Each Mule application runs as one or more Kubernetes pods. Each pod contains the Mule Runtime Engine and your application JAR. Kubernetes manages pod scheduling, restarts on failure, and rolling updates. You define CPU and memory requests/limits per application when deploying.

Ingress

External traffic enters the cluster through a Kubernetes Ingress controller. You configure TLS termination, custom domains, and routing rules at the Ingress level using your organization's standard Kubernetes tooling.

Installing Runtime Fabric

RTF installation follows these main steps:

Installation Steps

Step 1: Create RTF Instance in Anypoint Platform
  Runtime Manager → Runtime Fabrics → Create Runtime Fabric
  Name: production-rtf-us-east
  Download: activation-data (base64 string)

Step 2: Prepare Kubernetes cluster
  Minimum requirements:
  - Kubernetes 1.22+
  - 3 worker nodes (for HA)
  - Each node: 4 vCPU, 16GB RAM minimum
  - Container runtime: containerd or CRI-O
  - Persistent storage class available

Step 3: Install RTF components via Helm
  helm repo add rtf https://rtf-charts.anypoint.mulesoft.com
  helm install runtime-fabric rtf/runtime-fabric \
    --namespace rtf \
    --set activationData="[paste activation data]" \
    --set muleLicense="[MuleSoft license key]"

Step 4: Verify installation
  kubectl get pods -n rtf
  → All RTF pods should be Running
  In Anypoint Platform → Runtime Manager → Runtime Fabrics:
  → Status shows "Active"

Deploying to Runtime Fabric

Deploying to RTF from Runtime Manager is similar to deploying to CloudHub, but you select your RTF instance as the target.

RTF Deployment Settings

Runtime Manager → Deploy Application:
  Application Name:  orders-api-production
  Deployment Target: production-rtf-us-east   ← select your RTF
  Runtime Version:   4.6.x
  
  Resources per replica:
    CPU:    500m (0.5 vCPU)    ← CPU request
    Memory: 700Mi              ← Memory request
    
  Replicas: 2  ← number of pods (for HA)
  
  Public Endpoint:
    Internal: orders-api.internal.company.com
    External: via your Ingress controller at api.company.com/orders

Namespace Isolation

RTF uses Kubernetes namespaces to isolate applications from different environments. Production apps run in the prod namespace. Staging apps run in the staging namespace. Each namespace has its own resource quotas and network policies, preventing apps from different environments from interfering with each other.

Namespace Structure

Kubernetes Cluster
  │
  ├── Namespace: rtf          ← RTF system components
  ├── Namespace: mulesoft-prod ← Production Mule apps
  │     [orders-api pods]
  │     [customer-api pods]
  │
  └── Namespace: mulesoft-staging ← Staging Mule apps
        [orders-api pods]          (isolated from prod)

Autoscaling on RTF

RTF supports Kubernetes Horizontal Pod Autoscaler (HPA). Configure HPA to automatically add more pods when CPU usage is high and remove them when load drops.

HPA Configuration for orders-api:
  apiVersion: autoscaling/v2
  kind: HorizontalPodAutoscaler
  metadata:
    name: orders-api-hpa
  spec:
    minReplicas: 2
    maxReplicas: 10
    metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            averageUtilization: 70  ← scale up if CPU > 70%

Behavior:
  Normal load (CPU 40%):   2 pods running
  Traffic spike (CPU 85%): HPA adds pods → 4 pods
  Load returns to normal:  HPA removes pods → back to 2

RTF vs CloudHub Decision

When to Choose RTF over CloudHub

Choose RTF when:                    Choose CloudHub when:
───────────────────────────────     ───────────────────────────────
Own Kubernetes infra exists         No Kubernetes team or expertise
Data sovereignty required           No strict data location needs
Need to control networking          MuleSoft managing infra is fine
Cost optimization from K8s          Time-to-market is top priority
Integrating with K8s ecosystem      Small team, low operational overhead
Air-gapped environment needed       Standard cloud deployment is enough