# mulesoft Hosting Options - Full Documentation

<!-- document id=487526101caa24147ff9af285ab62c2089a0ea25d7b6f1f3ee54e5f899d98659 url=/mulesoft/current/en-us/hosting-home/index.md -->

---
product: Hosting Options
---

# Anypoint Platform Hosting Overview

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Host the Anypoint Platform control plane and runtime plane in different locations to meet your
security, data privacy, and compliance requirements. Choose from MuleSoft-managed cloud options or
self-hosted environments to control where your data is stored and processed. The control plane
location, runtime hosting option, and runtime region are independent choices.

## Control Plane and Runtime Plane

Anypoint Platform architecture separates into two distinct planes that can be hosted independently:

![Diagram of control plane and runtime plane hosting options](/mulesoft/current/en-us/hosting-home/_images/intro-control-runtime-planes.png)

Control plane

The management layer of Anypoint Platform, where you design, deploy, and manage APIs and Mule apps.
Your organization, identity, and design-time metadata live in this plane.

Runtime plane

The components where your APIs and Mule applications are deployed and made available to your users.
The runtime plane includes the Mule runtime engine and supporting services.

## Choosing a Hosting Option

Anypoint Platform lets you host the control plane and runtime plane independently. MuleSoft names
each regional MuleSoft-managed control plane a cloud, for example US Cloud or EU Cloud. Each
Anypoint Platform organization lives in exactly one cloud. Choose a cloud (where design-time data
and metadata live) and a runtime option (who runs your applications and on what infrastructure). If
you use CloudHub or CloudHub 2.0, also choose a runtime region (where those applications execute).
After you choose a commercial cloud, see
[Anypoint Platform Control Planes Overview](https://docs.mulesoft.com/control-planes/) to sign in, create, and deploy.

Depending on your requirements, you can choose from these options:

- Use Anypoint Platform in the MuleSoft-managed control plane and runtime plane.

- Host and manage the runtime plane within your own infrastructure while connecting it with the
  MuleSoft-managed control plane.

- Host both the control plane and runtime plane locally within your infrastructure.

These sections list the available options. Use
[Control Plane and Runtime Plane Compatibility](#support-matrix-control-plane) to confirm which
combinations are supported. After you choose a runtime option, see
[High Availability and Disaster Recovery Across Deployment Models](https://docs.mulesoft.com/hosting-home/hadr-guide) for how each model
stays available and who owns failover.

## Control Plane Hosting Options

MuleSoft provides cloud-managed and self-hosted control plane options. This table summarizes each
option, including data residency and applicable compliance standards.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Control Plane</th><th>Platform URL</th><th>Data Residency</th><th>Description</th><th>Compliance / Notes</th></tr></thead><tbody><tr><td><p><a href="https://anypoint.mulesoft.com">US Cloud (default)</a></p></td><td><p><code>anypoint.mulesoft.com</code></p></td><td><p>United States</p></td><td><p>MuleSoft-managed control plane hosted in the US. Supports the widest range of runtime regions globally. See <a href="https://docs.mulesoft.com/control-planes/">Anypoint Platform Control Planes Overview</a>.</p></td><td><p>Standard commercial terms</p></td></tr><tr><td><p><a href="https://eu1.anypoint.mulesoft.com">EU Cloud</a></p></td><td><p><code>eu1.anypoint.mulesoft.com</code></p></td><td><p>European Union</p></td><td><p>MuleSoft-managed control plane hosted in the EU. Supports EU-based runtime regions. See <a href="https://docs.mulesoft.com/control-planes/">Anypoint Platform Control Planes Overview</a>.</p></td><td><p>EU data residency</p></td></tr><tr><td><p><a href="https://ca1.platform.mulesoft.com">Canada Cloud</a></p></td><td><p><code>ca1.platform.mulesoft.com</code></p></td><td><p>Canada</p></td><td rowspan="4"><p>MuleSoft-managed control plane on Salesforce Hyperforce, with one in-country runtime region. See <a href="https://docs.mulesoft.com/control-planes/">Anypoint Platform Control Planes Overview</a>.</p></td><td rowspan="4"><p>See <a href="https://docs.mulesoft.com/hyperforce/">Salesforce Hyperforce Overview</a></p></td></tr><tr><td><p><a href="https://jp1.platform.mulesoft.com">Japan Cloud</a></p></td><td><p><code>jp1.platform.mulesoft.com</code></p></td><td><p>Japan</p></td></tr><tr><td><p><a href="https://in1.platform.mulesoft.com">India Cloud</a></p></td><td><p><code>in1.platform.mulesoft.com</code></p></td><td><p>India</p></td></tr><tr><td><p><a href="https://au1.platform.mulesoft.com">Australia Cloud</a></p></td><td><p><code>au1.platform.mulesoft.com</code></p></td><td><p>Australia</p></td></tr><tr><td><p><a href="https://gb1.platform.mulesoft.com">United Kingdom Cloud</a></p></td><td><p><code>gb1.platform.mulesoft.com</code></p></td><td><p>United Kingdom</p></td><td><p>MuleSoft-managed control plane hosted in the United Kingdom. See <a href="https://docs.mulesoft.com/control-planes/creating-and-deploying-mule-apps#deploy-mule-apps-to-control-planes">Deploy Mule Apps to Control Planes</a>.</p></td><td><p>United Kingdom data residency</p></td></tr><tr><td><p><a href="https://gov.anypoint.mulesoft.com">MuleSoft Government Cloud</a></p></td><td><p><code>gov.anypoint.mulesoft.com</code></p></td><td><p>United States</p></td><td><p>Federal Risk and Authorization Management Program (FedRAMP)-compliant control plane managed by MuleSoft, suitable for US government agencies.</p></td><td><p>FedRAMP authorized. See <a href="https://docs.mulesoft.com/gov-cloud/">MuleSoft Government Cloud Overview</a>.</p></td></tr><tr><td><p>Anypoint Platform Private Cloud Edition (PCE)</p></td><td><p>N/A (self-hosted)</p></td><td><p>Customer-managed</p></td><td><p>Self-hosted control plane deployed in your own data center, virtual server, or third-party cloud (for example, Amazon Web Services (AWS)). You control where assets and metadata are stored.</p></td><td><p>Full data sovereignty. See <a href="https://docs.mulesoft.com/private-cloud/latest/">Anypoint Platform PCE</a>. Some Anypoint Platform components aren’t supported.</p></td></tr></tbody></table>

## Runtime Plane Hosting Options

MuleSoft provides different options for hosting the runtime plane:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Runtime Option</th><th>Description</th><th>Managed By</th></tr></thead><tbody><tr><td><p><a href="https://docs.mulesoft.com/cloudhub-2/">CloudHub 2.0</a></p></td><td><p>Fully managed, containerized integration platform as a service (iPaaS) for running APIs and integrations as lightweight containers in the cloud. Supports auto-scaling, high availability, and dynamic infrastructure across the runtime regions available in your control plane.</p></td><td><p>MuleSoft</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/cloudhub/">CloudHub</a></p></td><td><p>Cloud-based environment for running Mule applications in the cloud. Supports high availability, clustering, failover, and load balancing.</p></td><td><p>MuleSoft</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/runtime-fabric/latest/">Runtime Fabric</a></p></td><td><p>Container service for running Mule applications and API gateways in your data center or third-party cloud. Supports high availability, failover, clustering, and load balancing with bundled Docker and Kubernetes.</p></td><td><p>Customer (infrastructure) and MuleSoft (orchestration)</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/hybrid-standalone/">Hybrid Standalone Runtimes</a></p></td><td><p>Mule runtime engine for running applications in your environment (physical server, virtual machine (VM), or cloud such as AWS or Azure). Supports centralized management through the MuleSoft control plane while keeping deployments within your trust boundary.</p></td><td><p>Customer (infrastructure) and MuleSoft (management)</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/on-premises/latest/">On-Premises Runtimes</a></p></td><td><p>Mule runtime engine for running applications on a single instance with no required connection to the control plane. Requires you to manage high availability, failover, clustering, and load balancing, and is suited for air-gapped or disconnected environments.</p></td><td><p>Customer (fully self-managed)</p></td></tr></tbody></table>

If you use CloudHub or CloudHub 2.0, you also choose a runtime region: the geographic location where
those applications execute. A runtime region is independent of control plane data residency. For
example, deploying to Canada (Montreal) from US Cloud does not give you Canada Cloud. Runtime
Fabric, Hybrid Standalone, and On-Premises runtimes run in your infrastructure and don’t use
MuleSoft-managed runtime regions.

For CloudHub 2.0 regions, identifiers, and DNS records, see
[Runtime Plane Regions and DNS Records](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#regions-and-dns-records).

## Control Plane and Runtime Plane Compatibility

This matrix shows which runtime plane options you can deploy to from each control plane. On-premises
runtimes aren’t listed because they don’t require a control plane. You install Mule and deploy
applications to that instance. If you register the Runtime Manager agent so Anypoint Platform can
manage that instance, it becomes a Hybrid Standalone runtime. See
[Run Mule Runtime Engine On-Premises](https://docs.mulesoft.com/on-premises/latest/).

<table><colgroup><col> <col> <col> <col> <col> <col></colgroup><thead><tr><th>Runtime Plane</th><th>US Cloud</th><th>EU Cloud</th><th>Canada Cloud, Japan Cloud, India Cloud, Australia Cloud, United Kingdom Cloud</th><th>MuleSoft Government Cloud</th><th>Anypoint Platform PCE</th></tr></thead><tbody><tr><td><p>CloudHub 2.0</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>No</p></td><td><p>No</p></td></tr><tr><td><p>CloudHub</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>No</p></td><td><p>Yes</p></td><td><p>No</p></td></tr><tr><td><p>Runtime Fabric</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>No</p></td><td><p>No</p></td></tr><tr><td><p>Hybrid Standalone Runtimes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td><td><p>Yes</p></td></tr></tbody></table>

## See Also

- [High Availability and Disaster Recovery Across Deployment Models](https://docs.mulesoft.com/hosting-home/hadr-guide)

- [Anypoint Platform Control Planes Overview](https://docs.mulesoft.com/control-planes/)

- [Salesforce Hyperforce Overview](https://docs.mulesoft.com/hyperforce/)

- [MuleSoft Government Cloud](https://docs.mulesoft.com/gov-cloud/)

- [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/)

- [CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/)

- [CloudHub 2.0 Runtime Plane Regions](https://docs.mulesoft.com/cloudhub-2/ch2-architecture#regions-and-dns-records)

- [CloudHub](https://docs.mulesoft.com/cloudhub/)

- [Anypoint Runtime Fabric Overview](https://docs.mulesoft.com/runtime-fabric/latest/)

- [Hybrid Standalone Runtimes](https://docs.mulesoft.com/hybrid-standalone/)

- [Run Mule Runtime Engine On-Premises](https://docs.mulesoft.com/on-premises/latest/)

<!-- document id=aa11b90bbb0c7beb2726c2fa4c734f7ad8fd677fc37955f95a1eca65854003e4 url=/mulesoft/current/en-us/hosting-home/hadr-guide.md -->

---
product: Hosting Options
---

# High Availability and Disaster Recovery Across Deployment Models

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

High availability (HA) and disaster recovery (DR) strategies protect your Mule applications from
downtime caused by infrastructure failures, disasters, or maintenance. The right approach depends on
how you deploy Mule runtime engine: managed platforms such as CloudHub 2.0 and CloudHub build in
much of the resilience for you, whereas deployments that you operate—Runtime Fabric, Hybrid
Standalone, and on-premises servers—require you to design clustering, failover, and backups
yourself.

## Understanding Downtime

Downtime strikes at any time, from any direction, and in any form, whether you plan for it or not.
Keeping an organization operational during a technology outage, a facility loss, a personnel loss,
or a third-party service failure prevents irreversible damage to the business. As organizations
shift to e-commerce models that depend on 24/7 uptime, HA and DR increasingly determine their
financial health.

Even small amounts of downtime add up and hurt an organization:

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Percentage Uptime</th><th>Percentage Downtime</th><th>Downtime Per Week</th><th>Downtime Per Year</th></tr></thead><tbody><tr><td><div><div><p>99%</p></div></div></td><td><div><div><p>1%</p></div></div></td><td><div><div><p>1.68 hours</p></div></div></td><td><div><div><p>3.65 days</p></div></div></td></tr><tr><td><div><div><p>99.9%</p></div></div></td><td><div><div><p>0.1%</p></div></div></td><td><div><div><p>10.1 minutes</p></div></div></td><td><div><div><p>8.75 hours</p></div></div></td></tr><tr><td><div><div><p>99.99%</p></div></div></td><td><div><div><p>0.01%</p></div></div></td><td><div><div><p>1 minute</p></div></div></td><td><div><div><p>52.5 minutes</p></div></div></td></tr><tr><td><div><div><p>99.999%</p></div></div></td><td><div><div><p>0.001%</p></div></div></td><td><div><div><p>6 seconds</p></div></div></td><td><div><div><p>5.25 minutes</p></div></div></td></tr></tbody></table>

## High Availability Versus Disaster Recovery

- **High availability (HA)** - Measures a system’s ability to remain accessible when a component
  fails. You implement HA by building multiple levels of fault tolerance and load balancing into a
  system.

- **Disaster recovery (DR)** - Restores a system to an acceptable previous state after a natural
  disaster (flooding, tornadoes, earthquakes, fires) or a man-made disaster (power failures, server
  failures, misconfigurations).

Both strategies increase overall availability, but they differ in one key way: HA generally
preserves the service with no loss, whereas DR preserves the data but usually incurs a brief loss of
service while the DR plan runs and the system restores.

## Creating Effective SLAs

A Service Level Agreement (SLA) defines what counts as acceptable service.

High availability means the service stays up, functions correctly, and processes requests and
responses properly. It doesn’t mean the service always runs at full capacity. Systems that you
design for high availability prevent outages and protect against interruptions. The SLA sets
expectations for every stakeholder.

An effective SLA does these things:

- Eliminates single points of failure

- Redirects and handles traffic

- Detects failures

For example, a basic service might define these SLAs:

- Normal operation handles 1,000 transactions per second with 1-second response times.

- Total downtime per year stays at or below 0.5 percent, or 1.83 days.

- Minimum acceptable service handles 100 transactions per second with 1-second response times for up
  to 2 hours a week.

For details, refer to:

- [Defining SLA Tiers](https://docs.mulesoft.com/api-manager/latest/defining-sla-tiers)

- [Rate Limiting and Throttling - SLA-Based Policies](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla)

## Disaster Recovery

**How quickly can your company get back to work after an IT emergency?**

Disaster recovery (DR) restores a system to an acceptable previous state after a natural or man-made
disaster. To drive your DR plan, use measurable business requirements such as Recovery Time
Objective (RTO) and Recovery Point Objective (RPO).

DR centers on your RPO and RTO. RPO is the point you return to after a disaster. For example, if you
back up the system every 24 hours, your RPO is at most the previous 24 hours. RTO is how quickly you
restore to your RPO and resume business, which includes the time to bring backup infrastructure or
applications online when your primary environment fails.

Backups form a major component of a solid disaster recovery program. How much of your backup
environment runs before a disaster determines your standby type, and each type trades cost for
recovery time:

Cold standby

Nothing runs in the backup environment, which keeps your expense to a minimum. Your cold standby is
a plan or script that, after you detect an outage, starts or creates the backup infrastructure,
deploys and starts your Mule applications, and routes traffic to them. Cold standby costs the least
but has the longest RTO.

Warm standby

You fully set up the backup infrastructure and deploy your Mule applications, but no Mule
applications run. After you detect an outage, you start them and route traffic to them. Warm standby
has a shorter RTO than cold standby.

Hot standby (active-passive)

You install, configure, and fully run the backup environment, including your Mule runtimes and
applications, but it doesn’t process requests until you detect an outage. Your RTO covers only the
time to route traffic to the backup environment.

Active-active

Two or more environments run and process traffic at the same time. When one environment fails, the
others keep serving requests with no downtime. Active-active costs the most.

How each deployment model implements these types depends on what you manage. For example, in an
on-premises deployment, a cold standby leaves the operating system stopped, whereas in CloudHub 2.0,
a cold standby is a plan or script to create the private space and deploy your applications in the
backup region. See the HA and DR page for your deployment model.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Term</th><th>Definition</th><th>Example</th></tr></thead><tbody><tr><td><p>Recovery Time Objective (RTO)</p></td><td><p>How quickly do you need to recover this asset?</p></td><td><p>1 min? 15 min? 1 hr? 4 hrs? 1 day?</p></td></tr><tr><td><p>Recovery Point Objective (RPO)</p></td><td><p>How fresh must the recovery be for the asset?</p></td><td><p>Zero data loss, 15 mins out of date?</p></td></tr></tbody></table>

## High Availability and Disaster Recovery by Deployment Model

HA mechanisms and DR responsibilities differ depending on how you deploy Mule. Each deployment model
has a primary HA mechanism, a DR strategy and responsibility split, and a level of cross-region
support. Use these differences to pick the right approach for how you run Mule.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Deployment Model</th><th>Primary HA Mechanism</th><th>DR Strategy and Responsibility</th><th>Cross-Region DR (Runtime Plane)</th><th>When to Use</th></tr></thead><tbody><tr><td><div><div><p>CloudHub 2.0</p></div></div></td><td><div><div><p>MuleSoft runs multiple replicas across availability zones automatically.</p></div></div></td><td><div><div><p>You own the multiregion strategy and provide a bring-your-own (BYO) global load balancer. MuleSoft manages in-region resilience.</p></div></div></td><td><div><div><p>Supported through the Global Deployment entitlement, which MuleSoft provides.</p></div></div></td><td><div><div><p>Fully managed, multi-replica resilience on AWS.</p></div><div><p>See <a href="https://docs.mulesoft.com/cloudhub-2/ch2-ha-dr">CloudHub 2.0 High Availability and Disaster Recovery</a></p></div></div></td></tr><tr><td><div><div><p>CloudHub</p></div></div></td><td><div><div><p>MuleSoft runs multiple workers across availability zones automatically.</p></div></div></td><td><div><div><p>You own cross-region failover. MuleSoft manages in-region resilience.</p></div></div></td><td><div><div><p>Not built in. You design and run cross-region failover.</p></div></div></td><td><div><div><p>Fully managed, multi-worker resilience on AWS.</p></div><div><p>See <a href="https://docs.mulesoft.com/cloudhub/cloudhub-hadr">CloudHub High Availability and Disaster Recovery</a></p></div></div></td></tr><tr><td><div><div><p>Runtime Fabric</p></div></div></td><td><div><div><p>You run a minimum of two replicas across availability zones, with optional Horizontal Pod Autoscaling (HPA).</p></div></div></td><td><div><div><p>You own backup, restore, and failover to a standby cluster.</p></div></div></td><td><div><div><p>Not built in. You fail over to a standby cluster in another region.</p></div></div></td><td><div><div><p>Kubernetes-based clusters that you operate.</p></div><div><p>See <a href="https://docs.mulesoft.com/runtime-fabric/latest/rtf-ha-dr">Runtime Fabric High Availability and Disaster Recovery</a></p></div></div></td></tr><tr><td><div><div><p>Hybrid Standalone</p></div></div></td><td><div><div><p>You cluster runtimes to share memory and fail over automatically.</p></div></div></td><td><div><div><p>You own backup, restore, and DR. MuleSoft provides control-plane availability and best practices.</p></div></div></td><td><div><div><p>You design and run cross-region recovery. Not built in.</p></div></div></td><td><div><div><p>You control the servers, which are managed through Anypoint Platform.</p></div><div><p>See <a href="https://docs.mulesoft.com/hybrid-standalone/hybrid-standalone-hadr">Hybrid Standalone High Availability and Disaster Recovery</a></p></div></div></td></tr><tr><td><div><div><p>On-Premises</p></div></div></td><td><div><div><p>You cluster Mule runtime servers for automatic failover, using active-active, fault-tolerant, or zero-downtime topologies.</p></div></div></td><td><div><div><p>You own the HA architecture, backup, restore, and DR for your servers and data.</p></div></div></td><td><div><div><p>Not built in. You design and run cross-region recovery.</p></div></div></td><td><div><div><p>On-premises clustering that you operate yourself.</p></div><div><p>See <a href="https://docs.mulesoft.com/on-premises/latest/on-premises-hadr">High Availability and Disaster Recovery for On-Premises Mule Runtime Engine</a></p></div></div></td></tr></tbody></table>

MuleSoft keeps the Anypoint Platform control plane resilient. In the managed runtime models,
MuleSoft also keeps in-region infrastructure resilient; in self-managed and on-premises models, you
own the infrastructure. In every model, you own any runtime strategy that spans regions.

> [!NOTE] Cross-region DR in this matrix applies to Mule runtime regions only, not to the Anypoint
> Platform control plane.

## Best Practices

Follow these general design principles for high availability and disaster recovery:

- Keep your integrations stateless.

- Don’t share transactional information between client invocations or scheduled executions.

- When the middleware must retain data because of a system limitation, persist it in an external
  store, such as a database or a messaging queue, rather than in the middleware infrastructure or
  memory.

- As the system scales—especially in the cloud—keep each worker or node’s state and resources
  independent of the other workers, which delivers better performance, scalability, and reliability.

## See Also

- [CloudHub 2.0 High Availability and Disaster Recovery](https://docs.mulesoft.com/cloudhub-2/ch2-ha-dr)

- [CloudHub High Availability and Disaster Recovery](https://docs.mulesoft.com/cloudhub/cloudhub-hadr)

- [Runtime Fabric High Availability and Disaster Recovery](https://docs.mulesoft.com/runtime-fabric/latest/rtf-ha-dr)

- [Hybrid Standalone High Availability and Disaster Recovery](https://docs.mulesoft.com/hybrid-standalone/hybrid-standalone-hadr)

- [High Availability and Disaster Recovery for On-Premises Mule Runtime Engine](https://docs.mulesoft.com/on-premises/latest/on-premises-hadr)