Operating Runtime Manager well is mostly about getting the configuration right once and then automating everything around it. The setup work is a four-piece configuration: register the deployment target with the platform, configure environments and user permissions, set up Secure Properties for each environment, and wire CI/CD against the Anypoint CLI. Get these four right and the day-to-day operation is straightforward. Skip any of them and the cost shows up later as permission sprawl, leaked secrets, or every deploy being a manual ceremony.
- Register your deployment target
In Anypoint Platform, decide which deployment target fits your workload (CloudHub, CloudHub 2.0, Runtime Fabric, or on-premises). For CloudHub, no setup is needed; the platform is ready. For Runtime Fabric, follow the install guide to provision a Kubernetes cluster (EKS, AKS, GKE, or self-managed), install the Runtime Fabric agent, and register it with Anypoint. For on-premises, install Mule Enterprise on the target servers, register each server with Anypoint by running the registration command with your organization token. Confirm the target shows up under Runtime Manager and accepts a smoke-test deployment before pointing real applications at it.
- Configure environments and user permissions
Open Anypoint Platform, go to Access Management, and review the Environments configured for your Organization (Design, Development, QA, Production at minimum). Add or rename environments to match your release process. Grant per-environment permissions to each user or group: developers get Read and Deploy on Development and QA, ops engineers get Read on all environments and Deploy on Production. Use Anypoint user groups (or SSO-mapped groups if you have set up Salesforce SSO) to manage permissions in bulk. Document the permission matrix in the platform runbook so audit and IT can review it without guessing.
- Set up Secure Properties for each environment
For each environment, go to Runtime Manager, pick a placeholder Mule application, and configure the Secure Properties values per environment. Production values should differ from QA values (different database URL, different API keys). Encrypt the values at rest using the Anypoint platform key. Never put production secrets in the Mule application code or in a Git repository. Document which Secure Properties each application requires in the project README. Confirm the values are accessible at runtime by deploying a smoke-test app that reads each property and writes the value (masked) to the log.
- Wire CI/CD with the Anypoint CLI
Set up a CI pipeline (Jenkins, GitHub Actions, GitLab CI, CircleCI, Azure DevOps) that builds the Mule application Maven project on every commit and produces a .jar artifact. Use the Anypoint CLI in the pipeline to deploy the artifact to the right environment using the Anypoint platform credentials stored in the CI secret store. Configure the pipeline to deploy to Development on every commit, to QA on every merged PR, and to Production only after manual approval and successful QA testing. Add deploy notifications to a Slack channel so the team sees deploys in real time. The pipeline is the operational backbone; treat it as production-critical infrastructure.
- Runtime Manager UI deploys are fine for development but break down at production scale. Every production deploy should run through CI/CD; manual UI deploys leave no audit trail and no rollback path.
- Secure Properties are environment-specific. A property added to QA is not automatically present in Production. CI/CD pipelines have to handle property promotion explicitly or production deploys fail at startup.
- Anypoint user identity is separate from Salesforce identity by default. After acquisition, SSO mapping is supported but optional; without it, you maintain two user directories. Set up SSO early to avoid drift.
- Runtime Manager built-in monitoring is shallow. For production workloads, enable Anypoint Monitoring and connect it to your observability stack. The basic UI metrics are not enough to debug a real outage.
- CloudHub workers have a memory cap (variable by tier). Mule applications that exceed the cap OOM-crash without an obvious cause. Monitor heap usage and right-size workers based on actual peak load.