harness · vishal-av · Sep 9, 2025 · Sep 9, 2025 · Sep 14, 2025
@@ -1,6 +1,27 @@
 ---
 title: CD onboarding path
 description: Ramp up on Harness CD
+tags:
+  - cd-onboarding
+  - continuous-delivery
+  - cd-pipelines
+  - deployment-strategies
+  - kubernetes-deployment
+  - devops-onboarding
+  - terraform-automation
+  - rbac
+  - approvals
+  - service-definitions
+  - environment-management
+  - triggers
+  - governance
+  - secrets-management
+  - artifacts
+  - templatization
+  - continuous-verification
+  - delegate-installation
+  - onboarding-path
+  - infrastructure-as-code
 sidebar_position: 1
 ---
 

@@ -6,6 +6,30 @@ helpdocs_topic_id: vytf6s0kwc
 helpdocs_category_id: c9j6jejsws
 helpdocs_is_private: false
 helpdocs_is_published: true
+tags:
+  - ecs
+  - amazon-ecs
+  - aws-ecs
+  - ecs-deployment
+  - ecs-rolling-deploy
+  - aws-iam
+  - ecs-task-definition
+  - ecs-service-definition
+  - ecs-blue-green
+  - ecs-canary
+  - ecs-autoscaling
+  - ecs-run-task
+  - aws-service-mesh
+  - ecs-circuit-breaker
+  - ecs-overrides
+  - ecs-cloudwatch
+  - ecs-fargate
+  - ecs-infrastructure
+  - ecs-provisioning
+  - aws-elb
+  - ecs-target-groups
+  - ecs-deployment-strategies
+  - ecs-service-discovery
 ---
 
 This topic shows you how to deploy images to your Amazon Elastic Container Service (ECS) cluster using a Rolling Deployment strategy in Harness.

@@ -1,6 +1,19 @@
 ---
 title: Spot Elastigroup
 description: Deploy a Spot Elastigroup using Harness CD.
+tags:
+  - spot-elastigroup
+  - aws-elastigroup
+  - spot-instances
+  - ami-artifacts
+  - oidc-aws-connector
+  - elastigroup-setup
+  - elastigroup-deploy
+  - elastigroup-canary-deploy
+  - elastigroup-swap-route
+  - application-load-balancer
+  - elastic-load-balancer
+  - feature-flag-cds-spot-elastigroup-ng
 redirect_from:
   - /docs/continuous-delivery/deploy-srv-diff-platforms/aws/spot-deployment
 sidebar_position: 1

@@ -1,13 +1,20 @@
 ---
 title: Helm deployments overview
-description: High-level view of Harness Helm deployments and Harness' options for users to perform Helm Deployments.
+description: High-level view of Harness Helm deployments and Harness's options for users to perform Helm Deployments.
+tags:
+   - helm
+   - helm-deployment
+   - harness-managed-helm
+   - native-helm
+   - helm-charts
+   - canary-deployment
+   - blue-green-deployment
 sidebar_position: 1
 ---
 
-Harness supports Helm deployments as part of its Kubernetes swimlane. You can deploy Helm charts and subcharts to your target infrastructure using all of the common chart and artifact repositories and cloud platforms.
+Harness supports Helm deployments as part of its Kubernetes swimlane. You can deploy Helm charts and subcharts to your target infrastructure using the common chart and artifact repositories and cloud platforms.
 
-This topic explains Harness managed Helm and Helm managed Helm deployments, advantages and disadvantages of both approaches, and what option is best suited for your requirement. 
-This topic explains Harness managed Helm and Helm managed Helm deployments, advantages and disadvantages of both approaches, and what option is best suited for your requirement. 
+This topic explains Harness-managed Helm and Helm-managed Helm deployments, the advantages and disadvantages of both approaches, and which option is best suited for your requirements. 
 
 ## Helm pipeline components
 
@@ -53,7 +60,7 @@ For a detailed explanation of Helm deployments, go to [Deploy Helm charts](/docs
 			<td>
             <ul>
                <li>A <b>Deploy</b> stage includes the deployment strategy and steps.</li>
-               <li>Pick a strategy and Harness automatically adds the required steps.</li>
+               <li>Pick a strategy, and Harness automatically adds the required steps.</li>
                <li>Add custom steps to perform other tasks.</li>
             </ul>
          </td>
@@ -63,42 +70,42 @@ For a detailed explanation of Helm deployments, go to [Deploy Helm charts](/docs
 
 ## Deploying Helm charts managed by Harness
 
-In a Harness managed Helm deployment, Harness fetches Helm chart and deploy it using Kubernetes `kubectl apply -f` command. This deployment method is a suitable option for users who are not fully invested in Helm and are not using its advanced features like Helm hooks, subcharts, and Helm dependencies. Such users can focus on Helm packaging the Kubernetes resources for you and publishing it to a target source. This approach gives you granular control on the Kubernetes resources, and how they're applied. You can specify which files you wish to skip for deployment, and prioritize which are created before the deployment, and so on. 
+In a Harness-managed Helm deployment, Harness fetches the Helm chart and deploys it using Kubernetes `kubectl apply -f` command. This deployment method is suitable for users who are not fully invested in Helm and are not using its advanced features like Helm hooks, subcharts, and Helm dependencies. Such users can focus on Helm packaging the Kubernetes resources for you and publishing them to a target source. This approach gives you granular control over the Kubernetes resources and their application. You can specify which files you wish to skip for deployment, prioritize which are created before the deployment, and so on. 
 
-With more control over the Helm packaged Kubernetes resources, Harness has the luxury of orchestrating Canary and Blue Green deployments, and tracking the resources accordingly. Harness appends canary labels to a Canary deployed service. Harness identifies the primary and stage services' Kubernetes objects deployed and manages the labels and selectors so the correct resources receive traffic. This approach gives Harness further control to version your ConfigMaps and Secrets along with your deployed resources so you get the correct versions with your deployed resources.
+With more control over the Helm-packaged Kubernetes resources, Harness has the luxury of orchestrating Canary and Blue Green deployments and tracking the resources accordingly. Harness appends canary labels to a Canary-deployed service. Harness identifies the primary and stage services' Kubernetes objects deployed and manages the labels and selectors so that the correct resources receive traffic. This approach gives Harness further control to version your ConfigMaps and Secrets along with your deployed resources, so you get the correct versions with your deployed resources.
 
-In the event of rollback, because Harness tracks and control how the files are released, Harness can initiate a rollback based on the ConfigMap version that captures the state of your last successfully deployed service.
+Because Harness tracks and controls how the files are released in the event of rollback, Harness can initiate a rollback based on the ConfigMap version that captures the state of your last successfully deployed service.
 
 Here's a summary of the process:
 
 1. Harness fetches the manifests from your Helm repository to the Harness Delegate.
    <details>
    <summary>Add different types of manifests</summary>
 
-   Here's a showing you how to add different types of manifests. It also describes how to add Helm charts and multiple values YAML files in the same repo as the chart, or in separate repos.
+   Here's a tutorial showing you how to add different types of manifests. It also describes how to add Helm charts and multiple-value YAML files in the same repo as the chart or in separate repos.
 
    <!-- Video:
    https://www.youtube.com/watch?v=Wvr52UKDOJQ-->
    <DocVideo src="https://www.youtube.com/watch?v=Wvr52UKDOJQ" />
 
    </details>
-2. Harness unzips the chart and runs a `helm template` over the Kubernetes resources packaged in the Helm chart.
+2. Harness unzips the chart and runs a `helm template` over the Kubernetes resources in the Helm chart.
 3. On the same Harness Delegate, or a delegate that has access to the target Kubernetes Cluster, Harness proceeds to deploy the Helm chart using the `kubectl apply -f <+kubernetes.resource.yml>` command.
 4. Once deployed, Harness manages and tracks the deployed Helm chart using the **Release Name**.
 
 ### Configuring Helm charts managed by Harness
 
 1. Create a [Harness service](/docs/continuous-delivery/get-started/services-and-environments-overview#services) in your Harness project.
 2. In service **Configuration**, under **Service Definition** > **Deployment Type**, select **Kubernetes**.
-3. In **Manifests**, select **Add Manifest** and navigate to **Manifest Source** in your service, and configure Git, OCI Helm, or HTTP Helm.
+3. In **Manifests**, select **Add Manifest**, navigate to **Manifest Source** in your service, and configure Git, OCI Helm, or HTTP Helm.
 4. Ensure that you have selected **Kubernetes** deployment type in your environment **Infrastructure Definition** as well.
 
-For detailed steps on how to deploy Harness managed Helm charts, go to [Deploy Helm charts](/docs/continuous-delivery/deploy-srv-diff-platforms/helm/deploy-helm-charts).
+For detailed steps on deploying Harness-managed Helm charts, go to [Deploy Helm charts](/docs/continuous-delivery/deploy-srv-diff-platforms/helm/deploy-helm-charts).
 
 ### Pros
 
-- Harness can orchestrate the Helm chart deployment in a Canary and Blue Green strategy.
-- Helm is now focused to package your resources, not deploy your resources. How you deploy and roll out your resources is now sequenced and managed by Harness.
+- Harness can orchestrate the Helm chart deployment using a Canary and Blue Green strategy.
+Helm is now focused on packaging your resources, not deploying them. How you deploy and roll out your resources is now sequenced and managed by Harness.
 - Versioning: Harness Kubernetes deployments version all objects, such as ConfigMaps and Secrets.
 - Rollback: In the event of deployment failure, Harness Kubernetes deployments will roll back to the last successful version via the versioned ConfigMap generated by Harness.
 
@@ -108,25 +115,25 @@ For detailed steps on how to deploy Harness managed Helm charts, go to [Deploy H
 
 ## Deploying Helm charts managed by Helm (Native Helm deployment)
 
-This approach is great when you are first moving to Harness. This requires minimal changes to your Helm package and deployment process. Harness just takes your existing Helm chart and deploys it to the target Kubernetes cluster that you specify for deployment.
+This approach is excellent when you are first moving to Harness. This requires minimal changes to your Helm package and deployment process. Harness takes your Helm chart and deploys it to the target Kubernetes cluster you specify for deployment.
 
-This approach is also suitable if you want to deploy complex Helm charts with hooks, subcharts, and dependency charts because you need not break down your chart and sequence out the dependency charts before deploying the main Helm chart.
+This approach is also suitable if you want to deploy complex Helm charts with hooks, subcharts, and dependency charts because you do not need to break down your chart and sequence out the dependency charts before deploying the main Helm chart.
 
-This approach also works well with the commodity Helm charts because you need not make any tweaks to the open source chart. Just supply a values.yaml file and Harness will perform the Helm fetch and Helm install.
+This approach also works well with the commodity Helm charts because you need not tweak the open source chart. Just supply a values.yaml file, and Harness will perform the Helm fetch and Helm install.
 
 Here's a summary of the process:  
 
-1. Harness fetches the manifests from your Helm repository on to the Harness Delegate.
-2. Harness unzips the chart, runs a `helm template` over the Kubernetes resources packaged in the Helm Chart.
-3. On the same Harness Delegate, or a delegate that has access to the target Kubernetes cluster, Harness will proceed to deploy using the `helm install {YOUR_HELM_CHART}` or a `helm upgrade {YOUR HELM CHART}`.
+1. Harness fetches the manifests from your Helm repository onto the Harness Delegate.
+2. Harness unzips the chart and runs a `helm template` over the Kubernetes resources in the Helm Chart.
+3. On the same Harness Delegate, or a delegate that has access to the target Kubernetes cluster, Harness will proceed to deploy using the `helm install {YOUR_HELM_CHART}` or a `helm upgrade {YOUR_HELM__CHART}`.
 4. After the deployment, Harness queries the deployed instances for tracking using the Helm client.
 
 For detailed steps on Native Helm deployment, go to [Native Helm deployment](/docs/continuous-delivery/deploy-srv-diff-platforms/helm/native-helm-quickstart).
 
 ### Pros
 
 - Rollback: Harness does not perform rollback. Instead, Harness uses Helm's native rollback functionality. This approach works well if you want to use your existing setup.
-- Harness will honor the user's pre and post install hooks configured in the Helm chart.
+- Harness will honor the user's pre- and post-install hooks configured in the Helm chart.
 
 ### Cons
 
@@ -137,12 +144,12 @@ For detailed steps on Native Helm deployment, go to [Native Helm deployment](/do
 
 1. Create a [Harness service](/docs/continuous-delivery/get-started/services-and-environments-overview#services) in your Harness project.
 2. In service **Configuration**, under **Service Definition** > **Deployment Type**, select **Native Helm**.
-3. In **Manifests**, select **Add Manifest** and navigate to **Manifest Source** in your service, and configure Git, OCI Helm, or HTTP Helm.
+3. In **Manifests**, select **Add Manifest**, navigate to **Manifest Source** in your service, and configure Git, OCI Helm, or HTTP Helm.
 4. Ensure that you have selected **Native Helm** deployment type in your environment **Infrastructure Definition** as well.
 
 ## What is supported in both approaches?
 
-### Optional: Trigger pipelines on new Helm chart published or on a new artifact image defined within the Helm chart
+### Optional: Trigger pipelines on a new Helm chart published or on a new artifact image defined within the Helm chart
 
 You can add a trigger to your Harness pipeline that will run the pipeline when the Helm chart or artifact version changes or is published to a repository.
 
@@ -154,11 +161,11 @@ For details, go to:
 
 ### Optional: Helm Chart to Manage Harness Delegates
 
-Harness includes a Helm-based Harness Delegate but you can use any delegate type for Helm deployments.
+Harness includes a Helm-based Harness Delegate, but you can use any delegate type for Helm deployments.
 
-Helm chart delegates are a great way to manage delegates at scale and via automation. The chart remains the same and you simply need to swap out the values.yaml for delegate installation.
+Helm chart delegates are a great way to manage delegates at scale and via automation. The chart remains the same; you simply need to swap out the values. Use YAML for delegate installation.
 
-You can parameterize much of the Helm Chart via Go Templating and pass in parameters via the values.yaml. This makes the Helm installation consistent and, depending on the team's requirements, you can pass in a values.yaml to spin up the delegate.
+You can parameterize much of the Helm Chart via Go Templating and pass in parameters via the values.yaml. This makes the Helm installation consistent, and, depending on the team's requirements, you can pass in a values.yaml to spin up the delegate.
 
 For steps on Helm delegates, go to [Delegate installation overview](/docs/platform/delegates/install-delegates/overview).
 

@@ -1,6 +1,10 @@
 ---
 title: Helm Delete Step
 description: Reference for the Helm Delete step
+tags:
+  - helm
+  - helm-delete-step
+  - helm-deployment
 sidebar_position: 60
 ---
 

@@ -1,6 +1,14 @@
 ---
 title: Kubernetes deployments overview
 description: High-level view of Harness Kubernetes deployment.
+tags:
+  - kubernetes
+  - kubernetes-deployment
+  - kubernetes-manifests
+  - managed-workloads
+  - blue-green-deployment
+  - canary-deployment
+  - rolling-deployment
 sidebar_position: 1
 redirect_from:
   - /docs/continuous-delivery/onboard-cd/cd-quickstarts/kubernetes-cd-quickstart

@@ -2,6 +2,14 @@
 title: Tanzu Command step
 description: Run a CF-enabled shell and use script inputs and outputs
 sidebar_position: 4
+tags:
+  - tanzu-command-step
+  - tanzu-deployments
+  - tanzu-cf-cli
+  - tanzu-harness-expressions
+  - tanzu-script-logging
+  - tanzu-deploy-stage
+
 ---
 
 The Tanzu Command step enables you to run scripts in the same Tanzu environment you are using for deployment in your pipeline.

@@ -1,6 +1,35 @@
 ---
 title: CD & GitOps tutorials overview
 description: Helpful tutorials for using Harness CD and GitOps
+tags:
+  - cd-tutorials
+  - cd-gitops-tutorials
+  - cd-tutorials
+  - gitops
+  - onboarding
+  - deployment-tutorials
+  - kubernetes
+  - helm
+  - kustomize
+  - microservices
+  - ecs
+  - serverless
+  - aws-lambda
+  - aws-vms
+  - azure-vms
+  - data-center-deployment
+  - unified-ci-cd
+  - pipeline-triggers
+  - variables
+  - notifications
+  - pipeline-templates
+  - infrastructure-provisioning
+  - security
+  - verification
+  - prometheus
+  - cloudformation
+  - cosign
+  - opa
 sidebar_position: 0
 ---
 

@@ -1,6 +1,13 @@
 ---
 title: AWS CloudFormation infrastructure provisioning
 description: Learn how to use AWS CloudFormation for infrastructure provisioning for Harness CD.
+tags:
+  - aws-cloudformation
+  - infrastructure-provisioning
+  - infrastructure-as-code
+  - cloudformation-create-stack
+  - cloudformation-rollback
+  - eks
 redirect_from:
   - /tutorials/cd-pipelines/infra-provisioning/cloudformation
   - /tutorials/cd-pipelines/infra-provisioning

@@ -6,6 +6,21 @@ helpdocs_topic_id: ihboxj8xlz
 helpdocs_category_id: Dxej4ug0n5
 helpdocs_is_private: false
 helpdocs_is_published: true
+tags:
+  - cd-services
+  - license-consumption
+  - service-licensing
+  - active-services
+  - service-instances
+  - custom-deployments
+  - pipelines-with-no-service
+  - subscription-page
+  - improved-service-license-tracking
+  - gitops-service-licensing
+  - service-instance-count
+  - licensing-changes
+  - legacy-licenses
+  - license-transition
 ---
 
 Harness Continuous Delivery & GitOps (CD) module uses 'Services' as a key construct in defining and managing the pieces of software that you want to deploy. Since the core value of the CD module is in deploying these services, most Harness customers either directly license by Services (legacy model) or license by Developers (Developer 360 model) and receive services as an included entitlement. More details on the Developer 360 model are available [here](/docs/platform/get-started/subscriptions-licenses/subscriptions).

@@ -8,6 +8,21 @@ helpdocs_is_private: false
 helpdocs_is_published: true
 redirect_from:
   - /docs/continuous-delivery/onboard-cd/cd-concepts/cd-pipeline-basics
+tags:
+  - services
+  - creating-services
+  - creating-environments
+  - service-overrides
+  - override-priority
+  - infrastructure-definitions
+  - infrastructure-tags
+  - values-yaml-overrides
+  - merging-values-yaml
+  - fully-overriding-values
+  - config-files
+  - runtime-inputs-and-expressions
+  - services-and-environments-rbac
+  - environment-groups
 ---
 
 This topic describes Harness Continuous Delivery (CD) services and environments.

@@ -1,6 +1,24 @@
 ---
 title: Deployment concepts and strategies
 description: This topic describes common deployment strategies.
+tags:
+  - deployments
+  - deployment-strategies
+  - blue-green-deployment
+  - canary-deployment
+  - rolling-deployment
+  - basic-deployment
+  - multi-service-deployment
+  - build-deployment
+  - gated-cd
+  - no-gate-cd
+  - approvals
+  - release-gates
+  - verification
+  - risk-management
+  - rollback
+  - cd-pipelines
+  - kubernetes-deployment
 sidebar_position: 1
 helpdocs_topic_id: 0zsf97lo3c
 helpdocs_category_id: etz0u5kujd