---

Deploying Your First App to CloudHub

Every flow you've built in this series so far has run locally in Anypoint Studio's embedded test server — great for development, but not meant for anyone outside your own machine to actually use. This post covers taking an app live: deploying to CloudHub, MuleSoft's own managed cloud runtime, and the one most beginners will use first.

What CloudHub Actually Is

CloudHub 2.0 is a fully managed, containerized integration platform as a service (iPaaS) — you deploy your APIs and integrations as lightweight containers in the cloud, without managing any underlying servers yourself. Under the hood, CloudHub 2.0 runs applications as containers on Kubernetes, which gives lighter isolation and more efficient resource use than the older virtual-machine-based approach, supporting faster scaling and higher application density.

The practical takeaway for a beginner: you don't provision servers, patch operating systems, or manage infrastructure. You package your Mule application and tell CloudHub to run it — MuleSoft handles the rest.

Note: CloudHub 2.0 vs CloudHub 1.0

You may see references to both "CloudHub" and "CloudHub 2.0" in documentation and job postings. CloudHub 2.0 has reached general availability and is now the platform MuleSoft steers new workloads toward, while the original CloudHub (1.0) is still supported but generally considered better suited to existing workloads nearing retirement rather than new projects. As a beginner starting fresh in 2026, default to CloudHub 2.0 unless you have a specific reason not to.

Prerequisites Before Deploying

• A working Mule application built in Anypoint Studio (any of the flows from earlier in this series work as practice — the Product API from Phase 4 is a good realistic candidate)
• An Anypoint Platform account with deployment permissions (the same account used for Anypoint Exchange, Design Center, etc., covered in the Anypoint Platform walkthrough earlier in this series)

Deploying from Anypoint Studio

The most direct path for a beginner:

1. Right-click your project in the Package Explorer
2. Select Anypoint Platform → Deploy
3. Choose your target environment (e.g., Sandbox — a safe non-production environment most orgs set up for exactly this kind of testing)
4. Select CloudHub 2.0 as the deployment target
5. Configure basic settings: application name (this becomes part of your app's URL), worker size, and number of replicas
6. Click Deploy

Studio packages your application and uploads it to CloudHub, where it builds and starts running as a container.

Deploying via Runtime Manager (the Cloud Console)

Alternatively, you can deploy directly from Anypoint Platform's web console, useful once your app already has a packaged artifact (like a .jar file from a CI/CD pipeline, rather than deploying straight from Studio):

1. Log into Anypoint Platform and navigate to Runtime Manager
2. Select Deploy Application
3. Upload your packaged application file
4. Configure the same settings as above (name, environment, worker size)
5. Deploy

This is the path you'll typically move toward as your workflow matures — Studio deployment is great for quick iteration early on, but real teams generally automate deployment through CI/CD pipelines that push to Runtime Manager rather than deploying manually from a developer's machine.

Watching It Come Up

Once deployed, Runtime Manager shows your application's status — Starting, Deployed, or Failed — along with logs you can inspect if something goes wrong (the same kind of Logger output covered in the Logging and Debugging post earlier in this series, now visible in the cloud rather than your local console).

Once status shows Deployed, your application is live at a CloudHub-provided URL, typically shaped like:

https://your-app-name.us-e1.cloudhub.io

Testing it works exactly like testing locally — hit the same paths you tested against localhost:8081 during development, just against this new live URL.

Environments: Sandbox vs Production

Anypoint Platform typically has multiple environments — commonly Sandbox (or Development/Test) and Production — configured under Access Management (mentioned briefly in the Anypoint Platform walkthrough post). Always deploy and test in Sandbox first. This isn't just caution for its own sake — Production environments in real organizations often have live customers or systems depending on them, and mistakes there have real consequences.

Worker Size and Replicas: A Brief Note

When deploying, you'll configure worker size (how much CPU/memory your app's container gets) and the number of replicas (how many copies run simultaneously, for both load distribution and high availability). As a beginner testing a simple app, the smallest worker size and a single replica is plenty — these settings become a real tuning consideration once you're running production traffic, not something to worry about while learning.

What's Next

CloudHub is the right choice for a huge share of real-world deployments — but it's not the only option, and it's not always the right one. Some organizations need more control, hybrid setups, or on-premises deployment entirely. Understanding when to reach for something other than CloudHub is exactly what we cover next.

Next up in this series: CloudHub vs Runtime Fabric vs On-Prem: Which One to Use

visit ebook site - https://techebooks.myinstamojo.com/