Learn Harness' Key Concepts

Updated 1 week ago by Michael Cretzman

This topic is a very quick summary of the key concepts of Harness.

Visual Summary

Harness involves several modules to cover the entire development and DevOps lifecycle:

And we're adding more modules all the time.

This video overview provides details about some Harness modules:

Here's a quick video overview of Harness key concepts:

See more videos by Harness.

What's next? Sign up for Harness and then try a quickstart.

Harness Architecture

The Harness platform has two components:

  • Harness Manager — Harness Manager is where your CI/CD and other configurations are stored and your pipelines are managed. Your pipelines can be managed purely through Git as well.
    Pipeline are triggered manually in the Harness Manager or automatically in response to Git events, schedules, new artifacts, and so on.
    Harness Manager is available either as SaaS (running in the Harness cloud) or as Self-Managed (running in your infrastructure).
  • Harness Delegate — The Harness Delegate is a software service you install in your environment that connects to the Harness Manager and performs tasks using your container orchestration platforms, artifact repositories, monitoring systems, etc.

See a visual example

See Delegates Overview.

Install the Harness Delegate whenever you need it

The Delegate is key to enabling Harness to perform CI/CD, etc tasks, but you don't need to install it right away.

You can install the Delegate as part of the flow when setting up your Pipelines or Connectors.


A Harness account is the top-level entity under which everything is organized.

Within an account you have organizations, and within organizations you have projects.

You can add resources at the account-level, and also at the organization and project levels.

All organizations and projects in the account can use the account's resources.

All projects in the organization can use the org's resources.

Why is this great? Each team can manage its resources within its project and not have to bother account admins every time they want to add a Connector or a secret. Projects make teams independent. This is part of Harness' democratization goals for developers.
See a visual example

Organizations and Projects

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

Within each Org you can add several Harness Projects.

See a visual example

A Harness Project contains Harness Pipelines, users, and resources that share the same goal. For example, a Project could represent a business unit, division, or simply a development project for an app.

See a visual example

Think of Projects as a common space for managing teams working on similar technologies. A space where the team can work independently and not need to bother account admins or even org admins when new entities like Connectors, Delegates, or secrets are needed.

Much like account-level roles, project members can be assigned Project Admin, Member, and Viewer roles.

See a visual example

Project users have at least view access to all configuration and runtime data of a Project and share the same assets (Environments, Services, Infrastructure, etc).

See Projects and Organizations.

Product Modules

Your project can add Harness products as modules, such as Continuous Integration or Continuous Delivery.

See a visual example


Typically, a Pipeline is an end-to-end process that delivers a new version of your software. But a Pipeline can be much more: a Pipeline can be a cyclical process that includes integration, delivery, operations, testing, deployment, real-time changes, and monitoring.

See a visual example

For example, a Pipeline can use the CI module to build, test, and push code, and then a CD module to deploy the artifact to your production infrastructure.

Pipeline Studio

You build Pipelines in Pipeline Studio.

You can create Pipelines visually or using code, and switch back and forth as needed.

See a visual example



See Harness YAML Quickstart.

Pipeline Studio guides you in setting up and running your Pipelines with ready-to-use steps.

See a visual example


A Stage is a subset of a Pipeline that contains the logic to perform one major segment of the Pipeline process. Stages are based on the different milestones of your Pipeline, such as building, approving, and delivering.

See a visual example

Some stages, like a Deploy stage, use strategies that automatically add the necessary steps.

See a visual example

See Add a Stage.

Steps and Step Groups

A step is an individual operation in a stage.

Steps can be run in sequential and parallel order.

A Step Group is a collection of steps that share the same logic such as the same rollback strategy.

See a visual example

See Run Steps in a Step Group.


A Service represents your microservices and other workloads logically.

A Service is a logical entity to be deployed, monitored, or changed independently.

See a visual example

Service Instance

Service Instances represent the dynamic instantiation of a service you deploy via Harness.

For example, for a service representing a Docker image, Service Instances are the number of pods running with the Docker image.

See a visual example

Service Definitions

When a Service is added to the stage in a Pipeline, you define its Service Definition. Service Definitions represent the real artifacts, manifests, and variables of a Service. They are the actual files and variable values.

You can also propagate and override a Service in subsequent stages by selecting its name in that stage's Service settings.

See a visual example

See Monitor Deployments and Services in CD Dashboards.


Environments represent your deployment targets logically (QA, Prod, etc). You can add the same Environment to as many Stages as you need.

Infrastructure Definition

Infrastructure Definitions represent an Environment's infrastructure physically. They are the actual clusters, hosts, etc.


Connectors contain the information necessary to integrate and work with 3rd party tools.

Harness uses Connectors at Pipeline runtime to authenticate and perform operations with a 3rd party tool.

For example, a GitHub Connector authenticates with a GitHub account and repo and fetches files as part of a build or deploy Stage in a Pipeline.

See Connectors How-tos.

Secrets Management

Harness includes built-in Secrets Management to store your encrypted secrets, such as access keys, and use them in your Harness account. Harness integrates with all popular Secrets Managers.

See a visual example

See Harness Secrets Management Overview.

YAML and Git

You can sync your Harness account, orgs, and projects with your Git repo to manage Harness entirely from Git.

Harness can respond to Git events to trigger Pipelines and pass in event data.

See Harness Git Experience Overview.


What you've seen is how Harness integrates with your resources and tools, and how you can build Pipelines.

Harness helps you to model any kind of software development and delivery process in minutes.

It allows for flexibility while making best practices easy to follow and poor practices difficult to implement.

Most importantly, it takes away the pain points of software development, delivery, verification, etc, and gives you confidence in their management and success.

What's next? Sign up for Harness and then try a quickstart.

Please Provide Feedback