MuleSoft CloudHub Deployment
CloudHub is the fastest way to deploy and run Mule applications. MuleSoft manages all the infrastructure — servers, networking, security patches, and scaling. You focus on building integrations. This topic walks through deploying an application to CloudHub from Anypoint Studio and from Runtime Manager.
What CloudHub Provides
- Auto-provisioned infrastructure: No servers to configure. Workers start within minutes.
- Built-in high availability: Deploy 2 or more workers and CloudHub distributes them across availability zones automatically.
- Managed load balancing: The Shared Load Balancer routes traffic to all workers. Dedicated Load Balancers offer custom domains and SSL termination.
- Object Store: A cloud key-value store for watermarks, cached data, and session state shared across workers.
- Anypoint Monitoring: Built-in dashboards, log search, and alerts with no configuration.
- Persistent Queues: Durable message queues for async processing and guaranteed delivery.
Deploying from Anypoint Studio
The simplest deployment path goes directly from Studio to CloudHub.
- Right-click your project in the Package Explorer
- Select Anypoint Platform → Deploy to CloudHub
- Sign in with your Anypoint Platform credentials if prompted
- The Deployment dialog appears — fill in:
- Application Name:
orders-api-production(must be globally unique) - Environment: Production
- Mule Version: 4.x (latest recommended)
- Region: US East (N. Virginia) or your preferred region
- Workers: 1
- Worker Size: 1 vCore
- Application Name:
- Click Deploy Application
Studio packages the project as a deployable archive (JAR file), uploads it to CloudHub, and starts the worker. Deployment typically takes 2–5 minutes.
Deploying from Runtime Manager
For production deployments, deploy through Runtime Manager rather than from Studio. This separates development from operations and enables approval workflows.
- Package your application using Maven:
mvn clean package - The packaged JAR is at
target/orders-api-1.0.0-mule-application.jar - In Anypoint Platform, open Runtime Manager
- Click Deploy Application
- Upload the JAR file
- Configure deployment settings (same fields as Studio deploy)
- Click Deploy Application
CloudHub Worker Sizing Guide
Worker Size Reference
Worker Size │ vCores │ Memory │ Best For ─────────────┼────────┼────────┼───────────────────────────── 0.1 vCore │ 0.1 │ 500MB │ Very low traffic APIs, dev/test 0.2 vCore │ 0.2 │ 1GB │ Light integration, low volume 1 vCore │ 1.0 │ 1.5GB │ Standard production API 2 vCores │ 2.0 │ 3.5GB │ Moderate batch, medium traffic 4 vCores │ 4.0 │ 7.5GB │ Heavy batch, high concurrency 8 vCores │ 8.0 │ 15GB │ Very large batch, maximum load
Multiple Workers for High Availability
Deploy 2 or more workers to ensure the application stays up even if one worker has a problem. CloudHub places workers in different availability zones automatically. The Shared Load Balancer routes traffic across all workers.
Single Worker vs Two Workers
Single Worker (no HA): Worker 1 fails → application is DOWN until it restarts (minutes) Downtime: 2–5 minutes per failure event Two Workers (HA): Worker 1 fails → Load Balancer routes ALL traffic to Worker 2 Worker 1 automatically restarts Downtime: ZERO for end users
Environment Variables and Properties
Never hardcode environment-specific values like database URLs or API keys in your application. Pass them as properties when deploying. In Runtime Manager's deployment dialog, open the Properties tab to add key-value pairs.
CloudHub Properties Setup
Runtime Manager → Application Settings → Properties:
Key Value
─────────────────────────── ──────────────────────────────────
db.host prod-db.mycompany.com
db.port 5432
db.name orders_production
db.username mule_prod_user
db.password [masked — CloudHub encrypts this]
salesforce.username integration-prod@mycompany.com
salesforce.token [masked]
email.smtpHost smtp.mycompany.com
log.level INFO
In your Mule application, reference with:
${db.host} → prod-db.mycompany.com
${db.password} → decrypted at runtime
CloudHub URLs
Every CloudHub application gets a default URL based on the application name:
Application Name: orders-api-production
Default URL: https://orders-api-production.us-e1.cloudhub.io
Pattern: https://{app-name}.{region-code}.cloudhub.io
For production use, configure a custom domain through a Dedicated Load Balancer:
Custom domain: https://api.mycompany.com/orders → Dedicated Load Balancer routes to orders-api-production workers → SSL certificate for api.mycompany.com installed on the Load Balancer
Static IP Addresses
By default, CloudHub workers use dynamic IP addresses that can change after restarts. If your backend systems use IP allowlisting, enable Static IP in the application settings. CloudHub assigns fixed IP addresses that stay the same through restarts and redeployments.
Zero-Downtime Deployments
CloudHub supports zero-downtime deployments for applications running 2 or more workers. Enable Persistent Queues and set the update strategy to Rolling Update. CloudHub deploys the new version to workers one at a time while the other workers continue serving traffic. Once all workers are updated, the deployment completes with no downtime.
Rolling Update Sequence (2 workers): t=0: Worker 1 running v1.0, Worker 2 running v1.0 t=1: Worker 1 stops, upgrades to v1.1 (Worker 2 handles all traffic) t=2: Worker 1 starts v1.1, Worker 2 stops for upgrade t=3: Worker 2 starts v1.1 t=4: Both workers running v1.1, zero downtime achieved
Monitoring After Deployment
After deploying, watch the application in Runtime Manager for the first 10 minutes. Check the Logs tab to confirm startup succeeded. Check the Dashboard tab to see the first requests arriving. Set up an Anypoint Monitoring alert for the first 24 hours after a new deployment to catch any post-deployment issues quickly.