Deploying and Managing API Implementations
Targets and mechanics
Implementations run on CloudHub (1.0 or 2.0), a standalone Mule runtime or cluster, or Runtime Fabric. CloudHub 1.0 scales with workers of a chosen vCore size; CloudHub 2.0 scales with replicas inside a target space. You can deploy from Runtime Manager (upload the JAR), from Design Center, with the Mule Maven plugin, or through a CI/CD pipeline calling the platform APIs.
Governance with API Manager
An app becomes a managed API through autodiscovery: the global configuration carries api.id (the API instance ID created in API Manager) and the environment, and the runtime registers itself on startup. Policies - rate limiting, SLA tiers, OAuth 2.0 token enforcement, client-ID enforcement, JSON threat protection, CORS - are attached in API Manager, not in flow code, and enforce in front of the app, so adding a policy needs no redeploy. Breaking autodiscovery silently drops every policy.
Configuration and secrets
Application properties are set per environment. Values prefixed secure:: are decrypted at startup with the environment's encryption key, which must exist in every environment where you deploy. Never hard-code credentials in the JAR.
Observability
Anypoint Monitoring gathers logs and metrics; alerts fire on conditions such as error rate or JVM memory; log levels can be changed per logger at runtime without a full rebuild.
Traps
- A policy attached in API Manager is invisible in the Mule flow; it cannot be "found" in XML.
- CloudHub 2.0 has no workers, and inbound traffic uses a private space plus a dedicated load balancer rather than a legacy
*.cloudhub.iohost. - Redeploying with the same
api.idpreserves the API instance and its policy history; a new ID creates a new registration.