As of Sep 18, 2025
This page offers details and License Unit descriptions for each product module to help customers make informed procurement and deployment decisions. Harness may modify these product descriptions to reflect new features or changing practices, but the modifications may not be retroactive or materially decrease Harness’s overall obligations during an Order Form Term.
Many of the Modules are licensed under the “Developer” License Unit, described here:
“Developer” means each person, identified by a specific, unique email address, who is an employee, agent, or contractor of the Customer or Customer’s Affiliate that accesses Software or the Harness Platform directly, or contributes to code development, deployment, security, maintenance, optimization or any other technical activities related to software code that is managed with Harness products, across all production and non-production en. For clarity, even if a person undertakes more than one of the activities described above, each such person shall only be counted as one Developer. If a customer wishes to use bots or robotic process automation to run the Software or Harness Platform, Customer must first obtain Harness’s prior written consent and such usage may be subject to additional restrictions. Harness may revise the definition of a Developer upon notice to the Customer, however the modifications may not be retroactive or materially decrease Harness’s overall obligations during an Order Form license term.
For Modules with License Units that include “Developer” and other supplemental License Units, the “License Unit Description” column lists “Developer +” along with the additional information.
The list of subprocessors for each Module can be found here. Customers must subscribe to this page to receive notifications of changes to the list of subprocessors. To subscribe, visit https://trust.harness.io, scroll down to the “Trust Center Updates” section, and click “Subscribe to updates.”
The Statements of Work for the following Professional Services offerings are available at the applicable URL:
- Onboarding: https://www.harness.io/legal/onboarding-program
- Adoption: https://www.harness.io/legal/adoption-program
- DevOps Essentials Guided Onboarding: https://www.harness.io/legal/devops-essentials-guided-onboarding-program
- Advisory: https://www.harness.io/legal/advisory-program
- Education: https://www.harness.io/legal/education
| Product Name | Product Description | License Unit Description |
|---|---|---|
| Continuous Integration (CI) | https://developer.harness.io/docs/continuous-integration | Developer+
For more details regarding how Harness Cloud Credits are calculated and utilized, please visit our Continuous Integration Subscriptions and license FAQ below, the terms of which are incorporated into this Order Form. https://developer.harness.io/docs/continuous-integration/ci-quickstarts/ci-subscription-mgmt/#harness-cloud-billing-and-build-credits |
| Continuous Delivery (CD) | https://developer.harness.io/docs/continuous-delivery | Developer +
Each Developer may use up to .33 CD Services. If there are more than 20 Service Instances in any of these CD Services, such additional CD Service Instances will count towards another Harness CD Service. A "CD Service" is an independent unit of software that is managed, tracked, and deployed using Harness Continuous Delivery (CD) and Harness GitOps. A CD Service may include, but is not limited to, the following: A binary running a daemon or application. A script or executable. A containerized service (e.g., Docker container). A virtual machine (VM). A serverless function (e.g., AWS Lambda, Google Cloud Function). An application synced via GitOps to a unique infrastructure. Custom definitions as configured within Harness Continuous Delivery. A “Service Instance” refers to the pods or instances of a CD Service deployed to a host. CD constantly tracks the instances of a Service deployed at a sixty (60) minute cadence. Harness tracks all SIs for all deployed Services at a sixty (60) minute cadence, when reporting for license consumption. Additionally, Harness takes the 95th percentile of all SI data points seen over the last 30 days for the Service, and uses this value as the number of SIs for the Service. |
| Feature Flags (FF) | https://developer.harness.io/docs/feature-flags | Developer +
"Monthly Tracked Keys" ("traffic keys") correspond to the number of unique user, device, account or other keys upon which feature flag decisions are based. Harness FF tracks your MTKs within a calendar month. |
| Feature Management & Experimentation (FME) | https://developer.harness.io/docs/feature-management-experimentation | Developer +
"Monthly Tracked Keys" ("traffic keys") correspond to the number of unique user, device, account or other keys upon which feature flag decisions are based. Harness FF tracks your MTKs within a calendar month. An "Event" is a record of user or system behavior. Events can be as simple as a page visited by a user, or a user interacting or seeing a feature controlled or managed by FME. As part of Customer’s subscription to the Harness Feature Management and Experimentation product (FME), Harness will include: (i) Harness’ internal CDN usage to serve customers and (ii) Customer’s transmission of impressions to Harness’ infrastructure. Harness provides a daily quota of 5,000 daily CDN requests per Monthly Tracked Key (MTK) entitlement and 5,000 daily received impressions per MTK entitlement. If Customer exceeds this limit, Customer may receive a notification from Harness and will be subject to overages at the cost of $0.20 per million CDN requests and $0.15 per million impressions if the issue is not resolved within 5 business days of receiving the notification for overages. |
| Cloud Cost Management (CCM) | https://developer.harness.io/docs/cloud-cost-management | Fees are charged as a percentage of the Total Tracked Cloud Spend, as tracked by Harness, up to a certain agreed upon amount, as stated in the Order Form.
“Total Tracked Cloud Spend” means the annual cloud costs data transmitted to and measured by CCM via the Harness API integration. The fees for Harness Cloud Cost Management - Cloud Cost Insights are charged at 1% of Customer’s Harness total tracked cloud spend up to a certain agreed upon amount, as stated in the Order Form annually, and discounted (if any) as reflected on the Order Form. During the term of this Order Form, if Customer wishes to utilize additional capacity, Customer must enter a new Order Form. The fees for Harness Cloud Cost Management - Commitment Orchestrator are charged at 1.25% of Customer’s Harness total tracked EC2 cloud spend up to a certain agreed upon amount, as stated in the Order Form annually, and discounted (if any) as reflected on the Order Form. During the term of this Order Form, if Customer wishes to utilize additional capacity, Customer must enter a new Order Form. The fees for Harness Cloud Cost Management - Autostoping are charged at 1.25% of Customer’s Harness total tracked cloud spend in nonproduction environments up to a certain agreed upon amount, as stated in the Order Form annually, and discounted (if any) as reflected on the Order Form. During the term of this Order Form, if Customer wishes to utilize additional capacity, Customer must enter a new Order Form. The fees for Harness Cloud Cost Management - Cluster Orchestrator are charged at 2% of Customer’s Harness total tracked cloud spend in Kubernetes environments up to a certain agreed upon amount, as stated in the Order Form annually, and discounted (if any) as reflected on the Order Form. During the term of this Order Form, if Customer wishes to utilize additional capacity, Customer must enter a new Order Form. |
| Security Testing & Orchestration (STO) | https://developer.harness.io/docs/security-testing-orchestration | Developer +
Each Developer is entitled to one hundred (100) Security Scans per month. A “Security Scan” is a single execution of a security test initiated through STO against a unique application target, service, or codebase. Security Scans can be triggered via automation, scheduled jobs, or manual execution. Additionally, the Security Scan may cover multiple files or endpoints, depending on the configuration, but is counted as one Security Scan per test execution. |
| Service Reliability Management (SRM) | https://developer.harness.io/docs/service-reliability-management | Developer +
Each Developer may use up to .33 SRM Services. An "SRM Service" is an independent unit of software that is managed and tracked using SRM. A SRM Service may include an application, metric, datapoint or other measurement that is managed by monitoring systems or tools like Prometheus or other application performance monitoring (APM) vendors. |
| Chaos Engineering (CE) | https://developer.harness.io/docs/chaos-engineering | Developer +
Each Developer may use up to 0.33 CE Services. A “CE Service” is any Target Resource that undergoes chaos experiments during a 30-day period using CE. A Target Resource may include but is not limited to
Running a chaos experiment using CE on each of these Target Resources above counts as one CE Service. For any other Target Resources not listed above, 100 chaos experiments on the non-listed Target Resource is equal to one CE Service. Repeated experiments on the same Target Resource within the 30-day period do not count as additional CE Services. |
| Software Engineering Insights (SEI) | https://developer.harness.io/docs/software-engineering-insights | Developer |
| Infrastructure as Code Management (IaCM) | https://developer.harness.io/docs/infrastructure-as-code-management | Developer+
Each Developer is entitled to ten (10) Executions per month. An Execution is defined as a successful run of a Terraform apply or Terraform destroy command that results in resource changes (i.e., provisioning, updating, or decommissioning infrastructure). An Execution includes, but is not limited to:
|
| Supply Chain Security (SCS) | https://developer.harness.io/docs/software-supply-chain-assurance | Developer+
Each Developer is entitled to one hundred (100) supply chain Executions per month. An Execution is defined as a single end-to-end run of a security validation workflow initiated by SCS. This includes the scanning, analysis, or attestation of a software artifact, dependency set, build process, or pipeline stage for integrity, provenance, and risk signals. One Execution includes a complete scan or verification of an artifact (e.g., container image, software package, binary, or manifest) initiated by a user, pipeline, or automated policy. Executions may involve multiple steps such as SBOM (Software Bill of Materials) generation, signature validation, dependency scanning, and compliance checks—but are counted as one execution per artifact per scan event. Applies to both pre- and post-deployment validation workflows. |
| Internal Developer Portal (IDP) | https://developer.harness.io/docs/internal-developer-portal | Developer |
| Database DevOps (DB) | https://developer.harness.io/docs/database-devops | "DB Instance" means each copy of a Schema deployed within a database environment.
A "Schema" is the structure or system that defines the organization of data, including tables, relationships, views, and other database objects. It provides a blueprint for how data is stored, accessed, and secured within the database. |
| Artifact Registry (AR) | https://developer.harness.io/docs/artifact-registry/ | "GB Storage" refers to the amount of digital storage, measured in gigabytes (GB), that is allocated for storing and managing artifacts within the Artifact Registry. Artifacts may include software packages, binaries, libraries, and other build-related components that are created, versioned, and stored for use in development and deployment processes. |
| DevOps Essentials | The DevOps Essentials bundle includes:
|
Developer+
The license unit descriptions of each of the included product modules will also apply, along with the following descriptions: STO A “Security Scan” executes the Security Testing Orchestration (STO) step within a pipeline. This involves scanning a target for security vulnerabilities. A “target” can be a repository, container image, configuration, or live application. CD A "Deployment Event" occurs when a CD Service is distributed, deployed, upgraded, or otherwise delivered to an Environment using any deployment strategy, including but not limited to manual, automated, blue-green, canary, or rolling deployments. Deployment Events are considered billable i) when a new CD Service is successfully deployed to an Environment, or ii) when an existing CD Service in an Environment is updated, upgraded, or modified. An "Environment" means a designated infrastructure or set of infrastructures where a Service is deployed, such as development, staging, or production environments. Exclusions: Deployment Events do not include processes or activities outside Harness CD and Harness GitOps unless specified in the applicable agreement. CI A "Cloud Credit" represents one minute of compute time consumed on Harness cloud infrastructure to execute pipeline stages or processes initiated by the customer. Cloud Credits are applicable when utilizing Harness modules that rely on Harness cloud resources for execution, including but not limited to Continuous Integration (CI), Security Testing Orchestration (STO), and Infrastructure as Code Management (IaCM). Cloud Credits are influenced by the following factors: - Operating System: The type of operating system used for the execution, which may affect resource consumption. - Allocated Resources: The virtual computing resources provided for execution, such as CPU, memory, and disk usage. Each pipeline stage or process executed on Harness cloud infrastructure, regardless of its complexity or duration, contributes to the consumption of Cloud Credits. Exclusions Cloud compute minutes do not include execution time or resources consumed on customer-owned infrastructure or external systems integrated with Harness unless explicitly specified in the customer agreement. IACM A "Deployment Event" occurs when executing an Infrastructure as Code Management (IaCM) stage within a pipeline that involves a Workspace through Terraform or OpenTofu commands. Each i) execution of an IaCM stage in a pipeline, or ii) action performed to create, update, destroy infrastructure resources defined in the state file associated with the Workspace, constitutes a billable Deployment Event. A "Workspace" is an independent unit that manages the lifecycle of resources defined by Terraform or OpenTofu within a shared state file. A Workspace serves as the context in which infrastructure resources are provisioned, modified, and tracked during IaCM stage execution. Exclusions. Actions or commands performed outside the IaCM stage in the Harness platform, and operations that do not involve referencing a Workspace or managing resources defined within a state file, are not considered Deployment Events. If Customer’s use of the Harness Platform exceeds the number of License Units set forth in the Order Form, Customer will be billed for such excess use at the end of the month in which such excess use occurs. |
| API Discovery | https://docs.traceable.ai/docs/api-catalog | “API Endpoint” refers to a specific URL or location on a server where an API can access the resources or services it needs to perform its functions. |
| API Security Testing (AST) | https://docs.traceable.ai/docs/api-testing | “API Endpoint” refers to a specific URL or location on a server where an API can access the resources or services it needs to perform its functions. |
| API Protection | https://docs.traceable.ai/docs/traceable-runtime-protection | “API Call” means any discrete unit of communication initiated by a software component (including but not limited to a web browser, mobile application, API consumer, backend service, or automated script)—to a service, endpoint, or resource that is processed and/or protected by the Platform measured on a rolling 3 month average. API Calls may occur over various supported protocols, including but not limited to HTTP, gRPC, or WebSocket, and originate from interactive user actions, background processes, system integrations, or automated workflows.
Each API Call is counted individually, regardless of its source or intended function, whether the request is allowed blocked or flagged by API Runtime Protection, and contributes to the Customer’s usage volume for billing and quota purposes. |
| Web Application Protection | https://docs.traceable.ai/docs/wap-api-protection | “API Call” means any discrete unit of communication initiated by a software component (including but not limited to a web browser, mobile application, API consumer, backend service, or automated script)—to a service, endpoint, or resource that is processed and/or protected by the Platform measured on a rolling 3 month average. API Calls may occur over various supported protocols, including but not limited to HTTP, gRPC, or WebSocket, and originate from interactive user actions, background processes, system integrations, or automated workflows.
Each API Call is counted individually, regardless of its source or intended function, whether the request is allowed blocked or flagged by API Runtime Protection, and contributes to the Customer’s usage volume for billing and quota purposes. |
| Bot Protection | https://docs.traceable.ai/docs/bot | “API Call” means any discrete unit of communication initiated by a software component (including but not limited to a web browser, mobile application, API consumer, backend service, or automated script)—to a service, endpoint, or resource that is processed and/or protected by the Platform measured on a rolling 3 month average. API Calls may occur over various supported protocols, including but not limited to HTTP, gRPC, or WebSocket, and originate from interactive user actions, background processes, system integrations, or automated workflows.
Each API Call is counted individually, regardless of its source or intended function, whether the request is allowed blocked or flagged by API Runtime Protection, and contributes to the Customer’s usage volume for billing and quota purposes. |
| Cloud Development Environments | https://developer.harness.io/docs/cloud-development-environments | Developer |
| AI Test Automation | https://developer.harness.io/docs/ai-test-automation | Developer+
A “Test Run” is the execution of a single test on an application (i.e. web, mobile, backend, desktop, APIs etc.), an environment (i.e. development, QA/staging, production, pre-production), configurations, code changes or builds, using Harness AI Test Automation. Regardless of whether the Test Run is triggered via other Harness products, manually, or is pre-scheduled, each executed test, whether successful or failed, will count as one Test Run. If multiple concurrent tests or the same tests are executed across multiple environments (e.g. dev, QA, staging, prod), each executed test counts as a separate, individual Test Run. If a test is retried (e.g., after a failure or for any other reason), the retried test counts as one additional Test Run |