---
schema_version: "1"
id: 302a9c516556dd08b514122b666091d64aeb38449b413fada17e0f5048c763cc
title: Continuous Deployment
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/runtime-manager/continuous-deployment.md
canonical_url: https://docs.mulesoft.com/runtime-manager/continuous-deployment
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 7eb1b2456476046270fdbec2b7bd8caa100c494299f4ba030b2fbc3d0b05c605
description: MuleSoft Documentation Site
latest: true
---
---
product: Runtime Manager
keywords: cloudhub, cloudhub api, manage, api, rest, ci/cd, cd, continuous deployment
---

# Continuous Deployment

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

[![logo cloudhub 2.0 active](/mulesoft/current/en-us/_/img/icons/clouds.svg "CloudHub 2.0")CloudHub 2.0](deployment-strategies#cloudhub-2-0)[ ![logo cloudhub active](/mulesoft/current/en-us/_/img/icons/cloudhub.svg "CloudHub")CloudHub ](deployment-strategies#cloudhub)[ ![logo hybrid active](/mulesoft/current/en-us/_/img/icons/hybrid-cloud.svg "Hybrid")Hybrid ](deployment-strategies#hybrid-deployments)[ ![logo server active](/mulesoft/current/en-us/_/img/icons/server-cloud.svg "Anypoint Platform PCE")Private Cloud Edition ](deployment-strategies#anypoint-platform-private-cloud-edition)[ ![logo rtf active](/mulesoft/current/en-us/_/img/icons/cloud-gear.svg "Runtime Fabric")Runtime Fabric](deployment-strategies#anypoint-runtime-fabric-deployments)

You can use the Runtime Manager REST API for continuous deployment to your own on-premises servers,
or to other cloud servers (outside of CloudHub). The Runtime Manager REST API enables you to
programmatically access much of the functionality provided by Runtime Manager. If you want to
implement continuous deployment to CloudHub, see [CloudHub REST API](https://docs.mulesoft.com/cloudhub/cloudhub-api).

You can implement the process described here as a task in the continuous deployment pipeline in the
following ways:

- As a shell (for example, Microsoft PowerShell, Bash, and so on)

- As a script

- As a Jenkins/Maven Plugin written in Java

For a more complete reference of all the operations, resources, methods, required properties, and
expected responses that are supported through the API, see
[Standalone Runtime Manager API Reference](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/arm-rest-services)
or
[Runtime Fabric API Reference](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/runtime-fabric/)

A Mule Maven plugin that provides the same capabilities is also available. Therefore, use the
process described here as an alternative if you cannot, or do not want, to use the
[Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept).

It is advisable to create a dedicated Anypoint Platform account used exclusively for deployment and
CI related activities.

## Workflow for On-Premises Servers

The workflow explained below can be carried out by various means, depending on your preference, but
the steps remain the same. The high-level steps are as follows:

- The user is signed into Anypoint Platform.

- Information about the servers, server groups, and clusters that are registered on that account is
  obtained.

- An application is deployed to it.

- The application interfaces with the APIs for access management and Runtime Manager.

The workflow must receive the following input parameters:

- **Username** - The Anypoint Platform account username

- **Password** - Password for the Anypoint Platform username

- **Environment** - The deployment environment (for example, Dev, Test, Prod)

- **Target Name** - The name of the target to which to deploy the application

- **Target Type** - The type of target (Server, Cluster, ServerGroup, Runtime Fabric)

- **Artifact Name** - Name of the Mule application to deploy

- **File** - The binary file of the Mule application to deploy

The workflow executes the following API calls in sequence:

![workflow](/mulesoft/current/en-us/runtime-manager/_images/arm-api-workflow.png)

To use the
[Anypoint Platform Access Management API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/):

1.  Call `/login` on the Access Management API with a valid Anypoint Platform user name and password
    to obtain the `access_token` and `token_type` to use in all the subsequent calls.

    > [!TIP] If using Jenkins, the **Username** and **Password** must be configured in the task. The
    > task has to concatenate the `token_type` and `access_token` and save them for the duration of
    > the entire workflow process. The fields must be concatenated as follows:
    > `token = token_type + " " + access_token`, for example:
    > `"bearer 895d1a05-ba24-44f2-a9df-3675c1bde97b"`.  
    > The token in its concatenated form must be passed as a header in every subsequent API call.

2.  Call `/accounts` on the Access Management API to retrieve the organization `id`.

    > [!TIP] The task must then extract the organization identifier from the location
    > 'user.organisation.id' and save it for later use. This step is not mandatory, as the
    > organization identifier can be passed as a local parameter to the task due to its static
    > nature.

3.  Call `/environments` on the Access Management API, passing the organization `id` retrieved in
    the previous step and choosing the correct environment `id` based on the relevant environment
    name (for example, `Dev`, `Test`, `Production`, and so on).

    > [!TIP] The organization `id` retrieved in Step 2 must be passed as part of the API URI. The
    > environment `id` must be extracted from the path 'data\[i\].id', where 'data\[i\].name ==
    > inputEnvironment' (it can take values like 'Dev', 'Test', 'Production' or any valid
    > environment name that is set up in your Anypoint Platform).

To use the
[Standalone Runtime Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/arm-rest-services):

1.  Call either `/servers`, `/clusters`, or `/serverGroups` on the Runtime Manager API, passing the
    server, cluster, or server group name, as well as the retrieved organization `id` and
    environment `id`. This call returns all of the data about this server, cluster, or server group,
    including the `targetId`.

    > [!NOTE] This step retrieves the target `id`, which is then used as a target for the
    > deployment. The task needs to pick up the right server, server group, or cluster identifier
    > based on the target name you set as an input at the beginning of the workflow. The server `id`
    > must be extracted from `data[i].id`, where `data[i].name == inputTargetName`.

2.  Call `/applications` on the Runtime Manager API, passing the organization’s `id` and the
    environment’s `id`, to retrieve the application’s `id` and the rest of its data.

    > [!NOTE] This step retrieves the application `id` to determine whether the following step is a
    > new deployment (6a) or a re-deployment (6b). The application `id` must be extracted from
    > 'data\[i\].id' where 'data\[i\].artifact.name == inputArtifactName' and 'data\[i\].target.id
    > == serverId' / 'clusterId' / 'serverGroupId'.

3.  Post `/applications` on the Runtime Manager API, passing the organization’s `id`, the
    environment’s `id`, 'artifactName', `targetId` (retrieved in Step 1 of this section), the Mule
    application .zip file to deploy and, optionally, the application `id`.

> [!NOTE] This step deploys the actual Mule application artifact for the first time to a target
> environment and server / cluster / server group. Use **POST** requests if no application
> identifier was retrieved in Step 2. Use **PATCH** if an application identifier was retrieved in
> Step 2, to re-deploy the actual Mule application artifact to a target environment and server /
> cluster / server group.

## Workflow for On-Premises Runtime Fabric

The workflow explained below can be carried out by various means depending on your preference, but
the steps remain the same. The high-level steps are as follows:

- It first logs your user into the Anypoint Platform

- Information about the Runtime Fabrics that are registered on that account is obtained

- An application is deployed to it

- The application interfaces with the APIs for the MuleSoft Anypoint Platform Access Management and
  Runtime Manager.

The workflow must receive the following input parameters:

- **Username** - The Anypoint Platform account username

- **Password** - Password for the Anypoint Platform username

- **Environment** - The deployment environment (Dev, Test, Prod, etc.)

- **Target Settings** - The type (ie: MC), name of the target to which to deploy the application,
  and settings

- **Exchange Reference** - Reference of the Mule application to deploy in Exchange

- **Application Configuration** - The application configurations for the deployment

The workflow executes the following API calls in sequence.

**Using the Maven Tool**

1.  Publish the artifact to the Exchange Assets Manager using
    [Maven](https://docs.mulesoft.com/exchange/to-publish-assets-maven).

    > [!NOTE] This step is required to ensure high availability when failure occurs in the target
    > and the Control Plane needs to re-deploy artifacts for recovery.

To use the
[Anypoint Platform Access Management API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/):

1.  Call `/login` on the Access Management API with a valid Anypoint Platform user name and password
    to obtain the `access_token` and `token_type` to use in all the subsequent calls.

    > [!TIP] If using Jenkins, the **Username** and **Password** must be configured in the task. The
    > task has to concatenate the `token_type` and `access_token` and save them for the duration of
    > the entire workflow process. The fields must be concatenated as follows:
    > `token = token_type + " " + access_token` for example:
    > `"bearer 895d1a05-ba24-44f2-a9df-3675c1bde97b"`.

The token, in its concatenated form, must be passed as a header in every subsequent API call.

1.  Call `/accounts` on the Access Management API to retrieve the organization `id`.

    > [!TIP] The task must then extract the organization identifier from the location
    > 'user.organisation.id' and save it for later use. This step is not mandatory, as the
    > organization identifier can be passed as a local parameter to the task due to its static
    > nature.

2.  Call `/environments` on the Access Management API, passing the organization `id` retrieved in
    the previous step and choosing the correct environment `id` based on the relevant environment
    name (for example, `Dev`, `Test`, `Production`).

    > [!TIP] The organization `id` retrieved in Step 2 must be passed as part of the API URI. The
    > environment `id` must be extracted from the path 'data\[i\].id', where 'data\[i\].name ==
    > inputEnvironment' (it can take values like 'Dev', 'Test', 'Production', or any valid
    > environment name that is set up in your Anypoint Platform).
    - Using the
      [Application Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/amc-application-manager/):

3.  Call deployments on the Application Manager API, passing the organization’s `id` and the
    environment’s `id`, to retrieve the application’s `id` and the rest of its data.

    > [!NOTE] This step retrieves the application `id` to determine whether the following step is a
    > new deployment (6a) or a re-deployment (6b). The application `id` must be extracted from
    > `data[i].id`, where
    > `` data[i].artifact.name == inputArtifactName' and `data[i].target.targetId == `targetId` ``.

4.  Post `/deployments` on the Application Manager API, passing the organization’s `id`, the
    environment’s `id`, `applicationName`, `labels`, `target` deployment settings (including the
    target id retrieved in Step 1 of this section), the Exchange reference of the published Mule
    application 'application' to deploy, the application `configuration`, and optionally the
    application `id`.

> [!NOTE] This step deploys the actual Mule application artifact for the first time to a target
> environment and Runtime Fabric. Use `POST` requests if no application identifier was retrieved in
> step 2. Use `PATCH` if an application identifier was retrieved in step 2 to re-deploy.
