Runtime Manager
Runtime Manager in MuleSoft Anypoint Platform is the cloud-based console that handles deployment, monitoring, scaling, and lifecycle management for Mule applications across every runtime target: CloudHub (MuleSoft own hosted runtime), Runtime Fabric (Kubernetes-based hybrid runtime), on-premises Mule servers, and bring-your-own-cloud setups.
Definition
Runtime Manager in MuleSoft Anypoint Platform is the cloud-based console that handles deployment, monitoring, scaling, and lifecycle management for Mule applications across every runtime target: CloudHub (MuleSoft own hosted runtime), Runtime Fabric (Kubernetes-based hybrid runtime), on-premises Mule servers, and bring-your-own-cloud setups. It is the operational nerve center for an Anypoint platform, the place where developers push deployment artifacts and where ops engineers watch what is actually running.
The product is one tier inside the broader Anypoint Platform alongside Anypoint Studio (the design IDE), Anypoint Exchange (the API catalog), API Manager (the policy engine), and Anypoint Monitoring (the deep observability tier). Runtime Manager is what people mean when they say where the Mule apps live. Salesforce acquired MuleSoft in 2018, so the platform is now part of the Salesforce ecosystem, but it retains its own console at anypoint.mulesoft.com and its own user identity model alongside Salesforce identity.
Runtime Manager in 2026: targets, environments, secrets, observability, and CI/CD
What Runtime Manager actually manages
Runtime Manager handles three things across every deployment target. First, deployment: it accepts the Mule application artifact (a .jar file produced by Anypoint Studio or a Maven build), pushes it to the chosen target, and records the deployment in the catalog. Second, configuration: it manages environment-specific properties (database URLs, API keys, feature flags) through Secure Properties, with values encrypted at rest. Third, runtime lifecycle: start, stop, restart, scale up, scale down, and log streaming. Behind the scenes, each target has different mechanics. CloudHub uses Mule own workers. Runtime Fabric deploys Mule applications as Kubernetes pods. On-premises Mule servers register with the cloud console and execute deployments locally. The Runtime Manager UI abstracts the differences.
Deployment targets and when to pick each
Anypoint Platform supports four deployment targets through Runtime Manager. CloudHub is the simplest: MuleSoft hosts the Mule workers, you pick a region and a worker size, and the platform handles infrastructure. Best for low-to-medium volume and where MuleSoft hosting is acceptable. Runtime Fabric is the Kubernetes-based option that runs on your own AWS, Azure, GCP, or on-prem Kubernetes cluster. Best for high volume, regulated industries, or when you need to colocate with other services. On-premises Mule is a standalone Mule server you install and manage yourself; Runtime Manager controls it remotely. Best for legacy data center constraints. CloudHub 2.0 is the next-generation hosted option built on Runtime Fabric primitives and is the strategic direction for most new customers.
Environments, organizations, and the Anypoint identity model
Anypoint Platform organizes resources into Organizations and Environments. An Organization is a top-level customer account. Environments inside it (Design, Development, QA, Staging, Production, Sandbox) hold the actual deployed apps and the policies that govern them. Each Mule application is deployed to exactly one environment at a time. Runtime Manager filters by environment, so what shows up in the console depends on which environment you have selected. User permissions are per-environment too. A developer might have full access in Development, read-only in QA, and no access in Production. Mapping Anypoint user identity to Salesforce SSO is supported but optional; many MuleSoft installations still use separate Anypoint credentials even after the Salesforce acquisition. Plan the identity model upfront to avoid permission sprawl later.
Secure Properties and how secrets get into Mule applications
Mule applications read configuration values from properties files at startup. Runtime Manager supports Secure Properties, which encrypt sensitive values (passwords, API keys, OAuth credentials) at rest in the Anypoint platform and decrypt them only at runtime inside the Mule worker. Secure Properties are environment-specific: the QA value is different from the Production value, and a developer with only QA permissions cannot read the Production value. Configuration is done either through the Runtime Manager UI per application, or through a CI/CD pipeline that injects properties at deploy time using the Anypoint CLI. Mature MuleSoft setups never put production secrets in the Mule application code; everything flows through Secure Properties. The pattern is the equivalent of Kubernetes Secrets or AWS Parameter Store for Mule.
Monitoring, logging, and alerting through Runtime Manager
Runtime Manager provides basic monitoring (CPU, memory, throughput, error rate per application) and basic logging (the last 10 MB or so of application log, viewable in the UI). Anypoint Monitoring is the deeper observability tier that adds dashboards, alerting, and long-term log retention. For production workloads, the recommendation is to enable Anypoint Monitoring and connect it to your own observability stack (Splunk, Datadog, New Relic, or just S3 for log archive). Runtime Manager alerts cover the basics: application down, error rate above threshold, deployment failed. For business-specific alerting (a Mule flow that processes orders is running slow), you need either Anypoint Monitoring custom dashboards or a downstream tool ingesting the Mule logs. Plan the observability story before you go live; retrofitting it after an outage is painful.
CI/CD, the Anypoint CLI, and automating deployments
Runtime Manager exposes a REST API and a command-line tool (the Anypoint CLI) that let CI/CD pipelines drive deployments without anyone clicking the UI. The standard pipeline pattern is: developer pushes Mule application code to Git, the CI server runs Maven to build the .jar artifact, the pipeline calls the Anypoint CLI to deploy the .jar to the right environment, the deployment script reads the environment-specific Secure Properties from a secret manager and passes them to Runtime Manager, and the pipeline reports success or failure back to the developer. Treating Runtime Manager as a click-driven console is fine for development but breaks down at production scale. Adopt CI/CD from day one and the platform scales with you; retrofit it later and every deploy is a manual ceremony.
Operating Runtime Manager well from setup to production CI/CD
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.
Trust & references
Straight from the source - Salesforce's reference material on Runtime Manager.
- Runtime Fabric DocumentationMuleSoft Docs
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Runtime Manager?
Q2. What environments does it support?
Q3. What can you do with it?
Discussion
Loading discussion…