---
schema_version: "1"
id: 496d579290237489353f07c394eb69d8016e0734fa2eab5ebd5150df51b9c8a4
title: Deploying Apps to CloudHub 2.0
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/cloudhub-2/ch2-deploy.md
canonical_url: https://docs.mulesoft.com/cloudhub-2/ch2-deploy
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 6021362e1ef354c27e7d0fbe04c0486aa76d1875111d475a54a0715ef88dc2be
description: MuleSoft Documentation Site
latest: true
---
---
product: CloudHub 2.0
---

# Deploying Apps to CloudHub 2.0

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

You can deploy Mule apps to either a shared or private space in CloudHub 2.0.

- [Deploying Apps to Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-shared-space)

- [Deploying Apps to Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-deploy-private-space)

- [Downloading Test Apps from Exchange](https://docs.mulesoft.com/cloudhub-2/ch2-download-test-app)

> [!IMPORTANT] CloudHub 2.0 supports Mule runtime engine versions 4.3.x and later.

## Application Deployment

After triggering a deployment, the application status eventually changes to `RUNNING`. If the
application status never changes to `RUNNING`, the replicas contain a `state` and `reason` to
indicate why the application status is not `RUNNING`.

When an application is deployed, the following events occur:

1.  The expected state of your application is stored, including application bundle and number of
    replicas.

2.  The application replica status is `PENDING`.

3.  When adequate compute and memory resources are available, each replica is attached to a node.

4.  The replica status is `STARTING`.

5.  The replica finishes loading the application.

6.  The replica status is `STARTED` and the replica can now perform work.

## Application Deployment Failure

If an application fails, for example, due to running of out memory, the following events occur:

1.  The replica status is `TERMINATED`.

2.  CloudHub 2.0 immediately attempts to restart the replica.

3.  The replica status is `RECOVERING`.

If the replica is able to restart:

1.  The replica finishes loading the application.

2.  The replica status is `STARTED` and the replica can now perform work.

If the replica can’t restart, for example, it relies on a network resource which temporarily
unavailable, the following events occur:

1.  The replica status is `PENDING`, with a message indicating "CrashLoopBackoff".

    CloudHub 2.0 attempts to restart the replica, using exponential backoff to avoid an excessive
    number of restart attempts.

2.  The replica status alternates between `RECOVERING` and `PENDING` until the issue preventing a
    successful restart is resolved.

3.  The replica loads the application.

After a successful restart, the replica status is `STARTED` and the replica can now perform work.

## Grace Period

When you stop, restart, update, redeploy, or terminate an application, CloudHub 2.0 tries to delete
it from Mule. To make sure inflight messages are delivered, there’s a five-minute timeout period.
After that period, CloudHub 2.0 shuts down the whole instance. This grace period applies to the
application instance, not to the runtime. The runtime uses its own configuration for shutdown. By
default, the runtime grace period is five seconds.

For more information about shutdown timeout behavior and how CloudHub 2.0 handles long-running
flows, see [Shutdown Timeout Behavior](https://docs.mulesoft.com/cloudhub-2/ch2-understand-app-restart#shutdown-timeout-behavior).

## See Also

- [Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about)

- [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about)