> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/add-a-custom-remote-script-and-manifests.md).

# Add a custom remote script and manifests

Run a script at deployment runtime and pull in your manifests.

This topic describes how to use Custom Remote Manifests to run a script at deployment runtime and pull in your manifests.

Harness provides support for all the major DevOps platform manifests and specifications, but there are situations when you want to use a custom script to pull your manifests.

Harness provides Custom Remote Manifests to let you run your script at deployment runtime and pull in your manifests.

In some cases, your manifests are in a packaged archive and you want to extract and use them at runtime. In these cases, you can use a packaged archive with Custom Remote Manifests.

You can use Custom Remote Manifests to add a script that pulls the package and extracts its contents. Next, you supply the path to the manifest or template for Harness to use.

Custom Remote Manifests are supported for:

* Kubernetes
* Helm chart
* OpenShift

For other methods, go to [Add Kubernetes Manifests](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/define-kubernetes-manifests.md) to configure the standard manifest sources.

## What you will learn from this topic

* How to [add secrets](#add-secrets-for-a-script) for a custom remote manifest script.
* How to [add the remote script and Kubernetes manifests](#add-the-remote-script-and-kubernetes-manifests) to a Harness service.
* How to [view the Harness Delegate](#view-the-harness-delegate-selected-for-the-deployment) selected for a deployment.
* How Custom Remote Manifests work for [Kubernetes YAML](#kubernetes-yaml), [OpenShift](#openshift-manifest), and [Helm chart](#helm-chart-manifests) manifests.

## Before you begin <a href="#before-you-begin" id="before-you-begin"></a>

Review the following topics before you add a custom remote script and manifests.

* [Kubernetes Deployment Tutorial](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-cd-quickstart.md)
* [Kubernetes Deployment Basics](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-deployments-overview.md)

## Supported platforms and technologies <a href="#supported-platforms-and-technologies" id="supported-platforms-and-technologies"></a>

Go to [Supported Platforms and Technologies](/continuous-delivery/new-to-continuous-delivery/cd-integrations.md) for the full list.

## Limitations <a href="#limitations" id="limitations"></a>

The following limitations apply:

* Custom Remote Manifests scripts use Bash only.
* The Delegate that runs the script must have all the software needed for the scripts to execute. If you select a Delegate in the Kubernetes Cluster Connector used by the stage Infrastructure Definition, then the script is run on that Delegate.

## Add secrets for a script <a href="#add-secrets-for-a-script" id="add-secrets-for-a-script"></a>

Typically, your script to pull the remote package uses a user account. For example:

```bash
curl -sSf -u "johndoe:mypwd" -O 'https://mycompany.jfrog.io/module/example/manifest.zip'
```

You can use Harness secrets for the username and password in your script. For example:

```bash
curl -sSf -u "<+secrets.getValue("username")>:<+secrets.getValue("password")>" -O 'https://mycompany.jfrog.io/module/example/manifest.zip'
```

Go to [Add and Reference Text Secrets](https://developer.harness.io/harness-platform/use-harness-platform/secrets/add-use-text-secrets) for more information.

## Start a pipeline <a href="#start-a-pipeline" id="start-a-pipeline"></a>

This topic assumes you have a Harness Project set up. If not, go to [Create Organizations and Projects](https://developer.harness.io/harness-platform/new-to-harness-platform/get-started) to set one up.

You can create a Pipeline from any module in your Project, or in the **Project Overview**, and then add stages for any module.

Enter a name for the Pipeline and click **Start**. You can then add a stage.

## Add a deploy stage <a href="#add-a-deploy-stage" id="add-a-deploy-stage"></a>

Go to [Add a Stage](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/add-a-stage) for the steps to add a stage. Then do the following:

1. Name the stage, and select what you want to deploy. For example, select Service.
2. Click **Set Up Stage**. The new stage's settings appear.
3. Click **Next** or **Service**.

## Create a Harness Kubernetes service <a href="#create-a-harness-kubernetes-service" id="create-a-harness-kubernetes-service"></a>

In Service, you can define/select the Service and Service Definition.

Select or create the Service.

To add your manifests, go to **Manifests** in the **Service Definition**.

## Add the remote script and Kubernetes manifests <a href="#add-the-remote-script-and-kubernetes-manifests" id="add-the-remote-script-and-kubernetes-manifests"></a>

You can use your Git repo for the remote script and manifests in Manifests and Harness will use them at runtime.

If you are adding the image location to Harness as an Artifact in the Service Definition, go to [Add Container Images as Artifacts for Kubernetes Deployments](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/add-artifacts-for-kubernetes-deployments.md) to configure it.

1. In your Harness Kubernetes Service, in **Manifests**, click **Add Manifest**.
2. In **Specify Manifest Type**, select **K8s Manifest**, and then click **Next**.
3. In **Specify K8s Manifest Store**, click **Custom Remote.**

   ![Custom Remote selected as the manifest store](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-a9c759919475b6ebd46eecbcf94fd240245b9d4a%2Fadd-a-custom-remote-script-and-manifests-38.png?alt=media)
4. Click **Continue**. The Manifest Details appear. Add your script to pull the package containing your manifests and specify the folder path for the manifests.

   ![Manifest Details with the script and folder path fields](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-70a643405db6d969bd940937d48eee50ec8d0c68%2Fadd-a-custom-remote-script-and-manifests-39.png?alt=media)
5. Enter the name in **Manifest Name**.
6. In **Custom Remote Manifest Extraction Script**, enter the path to the Git repo where your remote manifest script is available. This script runs on the Harness Delegate selected for the deployment.
7. In **Extracted Manifest File Location**, enter the folder path for the manifests.
8. In **Define Delegate Selector**, Harness selects the best delegate. Select a specific delegate from the list of tags available for delegates or leave this blank and allow Harness to select a delegate. Go to [Use delegate selectors](https://developer.harness.io/harness-platform/use-harness-platform/delegates/delegate/manage-delegates/select-delegates-with-selectors) for more information.

   <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Delegate selectors do not override service infrastructure connectors. Delegate selectors only determine the delegate that executes the operations of your pipeline.</p></div>
9. In **Values.yaml**, the field is populated with the folder path for the values.yaml.
10. Click **Submit**. The new manifest is created and added to **Manifests** in Harness.

    ![The new manifest listed in Manifests](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-12ab9ff872e20dc30ec1fe61b69e480b4ca69da6%2Fadd-a-custom-remote-script-and-manifests-40.png?alt=media)

## View the Harness Delegate selected for the deployment <a href="#view-the-harness-delegate-selected-for-the-deployment" id="view-the-harness-delegate-selected-for-the-deployment"></a>

The custom script runs on the Harness Delegate selected for deployment. If you selected a Delegate in the Kubernetes Cluster connector used by the stage's Infrastructure Definition, then the script is run on that Delegate.

Harness creates a temporary working directory on the Delegate host for the downloaded package. You can reference the working directory in your script with `WORKING_DIRECTORY=$(pwd)` or `cd $(pwd)/some/other/directory`.

After deploying your Pipeline, you can view the Delegate that was selected for the deployment.

Click **Execution Summary**, and then click **Custom Manifest Values Fetch Task** in the console to view the selected Delegate.

![Custom Manifest Values Fetch Task showing the selected delegate](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-670ec5e5073d245e4dcf861426c99130fa64a3fd%2Fadd-a-custom-remote-script-and-manifests-41.png?alt=media)

{% hint style="info" %}
**How Harness uses selectors when deploying custom remote manifests**

If you use separate connectors for downloading manifests and deploying the manifests to your environment, how Harness uses the selectors specified in the connectors varies between custom remote manifests and manifests downloaded from other store types, such as HTTP Helm.

For other store types, the delegate used for deployment must have all the selectors used with both connectors. For example, if a GitHub connector has selectors A and B, and the Kubernetes connector is configured with selectors C and D, the delegate used for deployment must have all of these selectors, that is, A, B, C, and D.

With custom remote manifests, Harness does not merge the delegate selectors used in the connectors when carrying out the deployment task. This is because the manifests have already been downloaded to Harness and are made available for deployment. Therefore, the delegate that is deploying a custom remote manifest needs to have only selectors C and D.
{% endhint %}

## Kubernetes YAML <a href="#kubernetes-yaml" id="kubernetes-yaml"></a>

You can enter the path to a manifests folder.

For example, if your expanded package has this folder structure:

```
manifest:
  - values.yaml
  - templates
    - deployment.yaml
    - service.yaml
```

In this example, you can enter manifest and Harness automatically detects the values.yaml and the other file (for example, deployment.yaml and service.yaml). If no values.yaml file is present, Harness uses the other files.

This is all the setup required. You can deploy the Service, and Harness executes the script at runtime.

## OpenShift manifest <a href="#openshift-manifest" id="openshift-manifest"></a>

Provide the path to the OpenShift template, Kubernetes manifest, or Helm file. For example, manifest/template.yaml.

Do not enter a folder. Harness requires a direct path to the file.

This is all the setup required. You can deploy the Service, and Harness executes the script at runtime.

## Helm chart manifests <a href="#helm-chart-manifests" id="helm-chart-manifests"></a>

When configuring a Helm chart with Custom Remote manifests, in the **Manifest Details** > **Advanced** section, you can select a **Helm Version**, and then add the command flags that you want to pass based on the version.

Go to [Add Helm chart](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/helm/deploy-helm-charts.md#add-the-helm-chart) for more information on Helm command flags.

## Task breakdown of custom remote manifest with Kubernetes deployment <a href="#task-breakdown-of-custom-remote-manifest-with-kubernetes-deployment" id="task-breakdown-of-custom-remote-manifest-with-kubernetes-deployment"></a>

Harness performs deployment with two Harness Delegate tasks. These are jobs that the Harness Manager assigns to the delegate:

1. **Fetch Files**: This task goes to the source repository or manifest source to fetch the manifests and download them onto the delegate running in your environment.
2. **Kubernetes Rolling Deploy**: This task takes the manifests collected from the Fetch Files task and deploys them into the target Kubernetes cluster.

## Scenario 1: On-premise manifest source with cloud target cluster <a href="#scenario-1-fetching-on-premise-manifest-source-with-cloud-target-cluster" id="scenario-1-fetching-on-premise-manifest-source-with-cloud-target-cluster"></a>

In this scenario, Harness fetches an on-premise manifest source and the deployment cluster is in the cloud. You have two delegates: one on-premise and one in the cloud.

* The Harness Manager uses the delegate installed in your environment to collect the manifest from the on-premise source and then store it with the deploy task.
* The Harness Manager assigns the task with the archived manifests to the cloud delegate associated with the cloud Kubernetes cluster for deployment.

## Scenario 2: On-premise manifest source with on-premise target cluster <a href="#scenario-2-fetching-on-premise-manifest-source-with-on-premise-target-cluster" id="scenario-2-fetching-on-premise-manifest-source-with-on-premise-target-cluster"></a>

In this scenario, Harness fetches a manifest source that is on-premise, and the deployment cluster is also on-premise. You have two delegates: one for on-premise tasks and one for the on-premise Kubernetes cluster.

**One delegate with access to on-premise remote manifest source and on-premise target cluster**

* The Harness Manager assigns the Fetch Files task to the delegate with access to the custom remote manifest source.
* If that same delegate has access to the on-premise Kubernetes cluster, it performs a second fetch for any values.yaml files needed for deployment and then performs the deployment.

**One delegate with access to on-premise remote manifest source and one delegate with access to on-premise target cluster**

* The Harness Manager assigns the Fetch Files task to the delegate with access to the custom remote manifest source.
* The manifests collected are archived for the Deploy task that is done by the delegate with access to the on-premise Kubernetes cluster.

## Go templating and public artifacts <a href="#notes" id="notes"></a>

You can use Go templating in your Kubernetes resource files, just as you would for files stored in Git or inline. Go to [Example Kubernetes Manifests Using Go Templating](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/example-kubernetes-manifests-using-go-templating.md) for more information. For OpenShift, you must use OpenShift templating.

If the artifact you are deploying with your manifest is public (DockerHub) and does not require credentials, you can use the standard public image reference, such as `image: harness/todolist-sample:11`.

## Next steps

* [Add Kubernetes Manifests](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/define-kubernetes-manifests.md): Configure the standard Kubernetes manifest sources supported by Harness.
* [Add Container Images as Artifacts for Kubernetes Deployments](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/add-artifacts-for-kubernetes-deployments.md): Add the artifact image for your Kubernetes deployment.
* [Example Kubernetes Manifests Using Go Templating](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/example-kubernetes-manifests-using-go-templating.md): Understand how Go templating works in Kubernetes manifests.
* [Add Helm chart](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/helm/deploy-helm-charts.md#add-the-helm-chart): Configure Helm command flags for a Helm chart manifest.

{% @harness-feedback/feedback %}