1. Harness Deployments Onboarding Path

This guide explains the five-phase journey for onboarding with Harness CD, from initial account setup to production-ready deployment automation with SSO and infrastructure-as-code. Each phase builds upon the last, introducing key Harness concepts, deployment patterns, governance controls, and automation strategies.

Following this roadmap reduces ramp-up time, ensures best practices are adopted early, and provides a structured path from simple deployments to advanced enterprise patterns. If you are looking for hands-on tutorials rather than a conceptual roadmap, go to Continuous Delivery tutorials.

What you will learn

• Five-phase onboarding journey: The stages from initial account setup to SSO-enabled DevOps with IaC, and what to accomplish in each phase

• Key Harness entities: Services, environments, infrastructure definitions, connectors, delegates, and how they work together

• Deployment strategies: When to use rolling, blue-green, canary, and basic deployment patterns for different risk profiles

• Governance and security: RBAC models (Center of Excellence vs Distributed DevOps), OPA policy enforcement, and approval workflows

• Automation patterns: Templatization for reusable pipelines and Terraform provider for infrastructure-as-code onboarding

Before you begin

This guide assumes:

• Basic understanding of CI/CD concepts and deployment pipelines

• Familiarity with at least one deployment target (Kubernetes, ECS, VMs, serverless, or cloud platforms)

• Access to a Harness account (trial or licensed)

If you prefer hands-on tutorials, go to Continuous Delivery tutorials.

Overview

This section lists the major onboarding phases and provides links to more details.

Phase 1: Initial setup

Phase 2: Deploy to QA

Phase 3: Deploy to staging

Phase 4: Deploy to production

Phase 5: SSO-enabled DevOps with Infrastructure as Code (IaC)

Phase 1: Initial setup

Step 1. Account and entities setup

Harness organizations (orgs) allow you to group projects that share the same goal. For example, all projects for a business unit or division.

A Harness project is a group of Harness modules and their pipelines. For example, a project might have a Harness CI pipeline to build code and push an image to a repo and a Harness CD pipeline to pull and deploy that image to a cloud platform.

Create a Harness org

1. In Harness, in Account Settings, select Organizations.

2. Select New Organization. The new organization settings appear.

3. In Name, enter a name for your organization.

4. Select Save and Continue.

Invite collaborators

1. In Invite People to Collaborate, enter a user's name and select it.

2. In Role, select the role the member will have in this org, such as Organization Admin or Organization Member.

3. Select Add.

   • Members receive invites via their email addresses.

   • You can always invite more members from within the org later.

4. Select Finish. The org is added to the list in Account Settings > Organizations.

Create a project

1. In Harness, go to Home and select Projects.

2. Select Project.

3. Name the project, and select a color. The Id of the project is generated automatically.

4. In Organization, select the org you created.

5. Add a description and tags, and then select Save and Continue.

6. In Invite Collaborators, type a member's name and select it.

7. Select a role for the member, and select Add.

8. Select Save and Continue to create the project.

Step 2. Delegate installation

The Harness Delegate is a service you run in your local network or VPC to connect your artifacts, infrastructure, collaboration, verification, and other providers with Harness Manager.

When you first connect Harness to a third-party resource, the Harness Delegate is installed in your target infrastructure (for example, a Kubernetes cluster). After the delegate is installed and registers with Harness, Harness can connect to third-party resources. The delegate performs all operations, including deployment and integration.

Go to Install Harness Delegate on Kubernetes or Docker to install the delegate in your target infrastructure.

Step 3. Secret managers and migrating secrets

Harness includes a built-in secret management feature that enables you to store encrypted secrets, such as access keys, and use them in your Harness connectors and pipelines. Go to Add a secret manager to configure a secret manager.

Looking for specific secret managers? Go to:

• Add an AWS KMS Secret Manager

• Add a HashiCorp Vault Secret Manager

• Add an Azure Key Vault Secret Manager

• Add Google KMS as a Harness Secret Manager

• Add an AWS Secrets Manager

Phase 1 outcome: You now have a Harness organization and project, a delegate installed in your target infrastructure, and a secret manager configured for secure credential storage. You are ready to define your first service and environment in Phase 2.

Phase 2: Deploy to QA

Step 1. Service and environments

Services

Services represent your microservices and other workloads. Each service contains a Service Definition that defines your deployment artifacts, manifests or specifications, configuration files, and service-specific variables. Go to Create a service to create services.

Services are often configured using runtime inputs or expressions, so you can change service settings for different deployment scenarios at pipeline runtime. Runtime inputs (<+input>) prompt the user for values at execution time, while expressions (for example, <+pipeline.sequenceId>) dynamically resolve values from pipeline context. Go to Using services with inputs and expressions to use runtime inputs and expressions.

The following examples show a Kubernetes service and an ECS Fargate service. Choose the example that matches your deployment platform. Key fields like connectorRef, imagePath, and namespace are placeholders — replace them with your actual connector and infrastructure identifiers.

Environments

Environments represent your deployment targets (QA, Prod, etc). Each environment contains one or more Infrastructure Definitions that list your target clusters, hosts, namespaces, and other infrastructure details. Go to Create environments to create environments.

Service Overrides

In DevOps, it is common to have multiple environments, such as development, testing, staging, and production. Each environment might require different configurations or settings for the same service.

For example, in the development environment, a service may need to use a local database for testing, while in the production environment, it should use a high-availability database cluster.

To enable the same service to use different environment settings, DevOps teams can override service settings for each environment.

Go to Create service overrides to configure environment-specific service settings.

Step 2. Adding artifact sources

In DevOps, an artifact source is a location where the compiled, tested, and ready-to-deploy software artifacts are stored. These artifacts could be container images, compiled binary files, executables, or any other software components that are part of the application.

To add an artifact source, you add a Harness connector to the artifact platform (DockerHub, GCR, Artifactory, etc.) and then add an artifact source to a Harness service that defines the artifact source name, path, tags, and so on.

For the list of artifact sources that you can use in your Harness services, go to Artifact Sources.

Step 3. Create a simple pipeline

To create a simple CD pipeline:

1. Create a pipeline.

2. Add a CD stage.

3. Define a service.

4. Target an environment and infrastructure.

5. Select execution steps.

You can model pipelines visually in the UI, using YAML, or via the REST API.

The following example shows a simple CD pipeline using a Kubernetes rolling deployment. Replace placeholder values like Service_1, Env_1, and Infra_1 with your actual service, environment, and infrastructure identifiers.

Phase 2 outcome: You have created a service with artifact sources, an environment with infrastructure definitions, and executed your first simple pipeline to deploy to QA. You are now ready to adopt advanced deployment strategies in Phase 3.

Phase 3: Deploy to staging

Step 1. Deployment strategies

You have likely heard terms like blue/green and canary when it comes to deploying code and applications into production. These are common deployment strategies, available in Harness CD as stage strategies, along with others.

Harness supports multiple deployment strategies. Choose based on your risk tolerance and rollback needs:

• Rolling: Incremental updates with gradual instance replacement (default for most use cases)

• Blue Green: Deploy new version alongside old, then instant traffic switch (instant rollback capability)

• Canary: Gradual traffic shift to new version with validation between phases (detect issues early before full rollout)

• Basic Deployments (Apply): Declarative Kubernetes resource application (for static configs like namespaces, ConfigMaps)

• Multi-service: Deploy multiple services in a single stage

The following YAML examples illustrate each strategy. Replace placeholder values like Service_1, Env_1, and connector references with your actual Harness identifiers.

Go to Deployment concepts and strategies to learn more about choosing the right strategy for your deployment scenario.

Step 2. Triggers and input sets

Triggers automatically initiate pipeline execution based on specific events or conditions, such as Git events, new Helm Charts, new artifacts, or specific time intervals. Triggers in Harness CD enable faster feedback cycles, enhanced efficiency, and decreased reliance on manual intervention during the deployment process.

Here are examples of a new artifact trigger and GitHub Webhook trigger:

Phase 3 outcome: You have implemented a deployment strategy for staging environments and configured triggers to automate pipeline execution based on Git events or artifact updates. You are ready to add governance and verification before promoting to production in Phase 4.

Phase 4: Deploy to production

Step 1. Approvals and governance (OPA)

Approvals

• Harness manual approvals: You can specify Harness user group(s) to approve or reject a pipeline at any point in its execution. During deployment, the user group members use Harness Manager to approve or reject the pipeline deployment manually.

• JIRA approvals: Jira issues can be used to approve or reject a pipeline or stage at any point in its execution. During deployment, the pipeline evaluates the fields in the Jira ticket based on criteria you define. Its approval or rejection determines if the pipeline or stage may proceed. You can add the Jira Approval step in Approval stages or in CD stages. The Jira Approval step prevents the stage execution from proceeding without an approval.

• ServiceNow approvals: You can use ServiceNow tickets to approve or reject a pipeline or stage at any point in its execution. During deployment, a ServiceNow ticket's fields are evaluated according to the criteria you define, and its approval or rejection determines if the pipeline or stage may proceed.

• Custom approvals: Custom approval stages and steps add control gates to your pipelines by allowing you to approve or reject a pipeline or stage at any point during build execution. When you add a Custom Approval step, you add a script to the step, and then use the script results as approval or rejection criteria.

When an approval step is denied, the pipeline stops execution and logs the denial reason. The pipeline status shows as "Aborted" or "Failed" depending on failure strategy configuration. When approved, the pipeline proceeds to the next step. Approval history is visible in the pipeline execution details.

Go to Approvals to learn more about configuring approvals.

Governance

Harness Policy As Code uses Open Policy Agent (OPA) as the central service to store and enforce policies for the different entities and processes across the Harness platform. You can centrally define and store policies and then select where (which entities) and when (which events) they will be applied.

Policies are written in Rego, OPA's policy language. Each policy contains a deny[msg] rule that evaluates input data (workspace config, Terraform plan, or state) and returns an error message if the rule fails. Go to OPA policy language documentation to learn Rego syntax and semantics.

The following examples show Harness governance patterns with OPA.

Freeze deployments

A deployment freeze is a period of time during which no new changes are made to a system or application. This ensures that a system or application remains stable and free of errors, particularly in the lead-up to a major event or release. During a deployment freeze, only critical bug fixes and security patches might be deployed, and all other changes are put on hold until the freeze is lifted. Deployment freezes are commonly used in software development to ensure that a system is not destabilized by the introduction of new code in new application versions.

For more information, go to Freeze deployments.

Here's a sample YAML to set up deployment freeze in Harness:

Step 2. RBAC

To perform Role-based access control (RBAC), a Harness account administrator assigns resource-related permissions to members of Harness user groups.

Choose an RBAC strategy based on your organizational structure:

• Center of Excellence (CoE): Centralized control with a dedicated platform team managing Harness resources, connectors, and policies across all projects. Best for organizations that prioritize standardization and governance.

• Distributed DevOps: Each project team manages their own Harness resources with account-level admin oversight. Best for organizations with autonomous teams that need flexibility.

The following tables detail permissions and resource groups for each role in both strategies.

Go to Role-based access control (RBAC) in Harness to configure RBAC in Harness.

Step 3. Continuous Verification

Harness Continuous Verification (CV) is a critical tool in the deployment pipeline that validates deployments by integrating with APMs and logging tools to verify that the deployment is running safely and efficiently.

Harness CV applies machine learning algorithms to every deployment for identifying normal behavior. This allows Harness to identify and flag anomalies in future deployments. During the Verify step, Harness CV automatically triggers a rollback if anomalies are found.

Deployment strategies for Continuous Verification:

• Continuous Verification type

  • Auto

  • Rolling Update

  • Canary

  • Blue Green

  • Load Test

• Sensitivity

• Duration

• Artifact tag

• Fail on no analysis

• Health Source

During the Verify step, Harness compares deployment metrics (error rates, latency, throughput) against a learned baseline from previous deployments. If metrics deviate beyond the sensitivity threshold (Low/Medium/High), Harness flags an anomaly. When "Fail on no analysis" is enabled, the pipeline rolls back automatically. View anomaly detection results and metric comparisons in the Verify step logs within the pipeline execution.

Go to Configure CV to configure continuous verification.

Phase 4 outcome: You have production-ready pipelines with approval gates, policy enforcement, RBAC configured for your team structure, and continuous verification to detect and roll back failed deployments. You are ready to scale onboarding and automation with SSO and infrastructure-as-code in Phase 5.

Phase 5: SSO-enabled DevOps with Infrastructure as Code (IaC)

Step 1. SSO

Harness supports Single Sign-On (SSO) with SAML, integrating with your SAML SSO provider to enable you to log your users into Harness as part of your SSO infrastructure. The user can choose between a variety of SSO integrations according to their needs.

Go to Authentication to configure SSO.

Step 2. Templatization & Automation

Templatization

Harness enables you to add templates to create reusable logic and Harness entities (like steps, stages, and pipelines) in your pipelines. You can link templates in your pipelines or share them with your teams for improved efficiency.

Templates enhance developer productivity, reduce onboarding time, and enforce standardization across the teams that use Harness. Here's an example template that builds a JavaScript application, runs unit tests and pushes to docker registry.

Terraform Automation

The Harness Terraform Provider enables automated lifecycle management of the Harness Platform using Terraform. You can onboard onto Harness on day 1 and also make day 2 changes using this Provider.

The Harness Terraform Provider allows you to define Harness resources (projects, services, environments, pipelines, connectors) as code. This is useful for onboarding multiple teams or replicating configurations across accounts.

The following Terraform script creates a project, Kubernetes connector, secret, service, environment, infrastructure definition, and pipeline. Customize the variable values in a terraform.tfvars file or pass them inline when running terraform apply. Key variables include accountId, orgIdentifier, platform_api_key, and connector details.

Go to Onboard with Terraform Provider to learn more about the Terraform provider.

Phase 5 outcome: You have enabled SSO for seamless user authentication, created reusable templates to standardize pipelines across teams, and automated Harness resource provisioning using the Terraform provider. Your Harness deployment platform is now production-ready and scalable.

Related concepts

Now that you understand the Harness CD onboarding journey, explore these related topics to deepen your knowledge:

• CD pipeline modeling overview: Learn how to structure multi-stage pipelines with dependencies and conditionals

• Deployment concepts and strategies: Detailed comparison of rolling, blue-green, and canary strategies with use case guidance

• RBAC in Harness: Configure roles, resource groups, and permissions for your team structure

• Harness Terraform provider: Automate Harness resource provisioning with infrastructure-as-code

• Continuous Delivery tutorials: Hands-on quickstarts for Kubernetes, ECS, serverless, VMs, and more