Harness CD service licensing is the way Harness measures use of its Continuous Delivery and GitOps module. Harness explains that the module “uses services as the core construct for defining and managing the software you deploy”, whether containerized workloads, traditional virtual machines, serverless functions or custom deployment targets.[1] The documentation describes “two licensing models for CD: a legacy service-based model where you license by active services directly, and the Developer 360 model where you license by developers and receive service entitlements as part of that subscription”. Both only count services deployed in the last 30 days.[1]
Editions
CD is sold as a module of the Enterprise plan and as part of the Essentials plan’s DevOps Essentials bundle.[7] In the Developer 360 model, each Developer may use up to .33 CD Services, which the Subscriptions page expresses as one service for every three Developers.[2][3] The DevOps Essentials terms add a different unit for that bundle, the Continuous Delivery Deployment Event, which is billable when a new Service is deployed to an Environment or an existing Service is updated.[6] The contract page repeats the Deployment Event definition for DevOps Essentials and says that deployment events do not include processes outside Harness CD and GitOps.[2] Catalog rows: Each Developer may use up to .33 CD Services and the metric Deployment Event.
Metrics
A CD Service is “an independent unit of software that is managed, tracked, and deployed using Harness Continuous Delivery (CD) and Harness GitOps”. It can be a binary running a daemon or application, a script or executable, a containerized service, a virtual machine, a serverless function, an application synced through GitOps to a unique infrastructure, or a custom definition.[2] In practice the documentation maps a service to a Kubernetes deployment, statefulset or daemonset, a GitOps application, a containerized cloud service such as AWS ECS, a virtual machine, a serverless function or a custom definition.[1]
A Service Instance (SI) refers to “the pods or instances of a CD Service deployed to a host”. CD tracks the instances of every deployed service every 60 minutes.[2] See CD Service and Service Instance.
Counting / floors
Active service window. “Services deployed using the CD module in the last 30 days are considered active services.” A service not deployed for more than 30 days stops consuming a licence and resumes when redeployed, keeping its identity. Renaming a service preserves its history, but deleting a service and recreating it with the same name makes it a new service whose 30-day window “starts fresh”.[1] Rows: Only services deployed in the last 30 days consume CD licences and Deleting and recreating a service starts a new licence history.
95th percentile. For reporting, “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”. This excludes the top 5 percent of instance counts, so load testing, blue-green deployments and other temporary scaling “do not artificially inflate your license usage”.[1][2] See Service Instances use the 95th percentile of 30 days of hourly samples.
Licences per deployment type. The documentation gives the following ratios.[1]
| Deployment type | Service licences consumed |
|---|---|
| Containerized (Kubernetes, Amazon ECS, Tanzu, Azure WebApps) | 1 for every 20 service instances; 25 instances consume 2 licences |
| Traditional VM-based (AMI/ASG, WinRM or SSH) | 1 for every 20 service instances |
| Serverless functions (AWS Lambda, Google Cloud Functions, Azure Functions and others) | 1 for every 5 unique functions deployed in the last 30 days |
| Custom deployments with an instance fetch script | 1 for every 20 service instances |
| Custom deployments without a working instance fetch script | 1 for each active custom service |
| Pipelines with no service (provisioning only, shell scripts, custom stages) | 1 for every 2000 executions of such custom stages |
The contract page states the same threshold: when a service has “more than 20 Service Instances”, the additional instances “will count towards another Harness CD Service”.[2] For pipelines with no service, each custom stage counts as one execution, so a pipeline with two custom stages uses two executions.[1] The rows are One CD service licence per 20 Service Instances, Serverless functions consume one CD licence per five unique functions and Custom deployments without an instance fetch script cost one licence each. A documented change table shows that serverless functions were previously valued at one service per function and are now 0.2 service per function.[1]
GitOps. “By default, Harness calculates CD license usage based on Services, but calculates GitOps license usage based on Applications.” That can overstate usage when the same service is deployed to several environments through separate GitOps Applications. A feature flag, which customers request from Harness Support, makes Applications linked to a Harness Service use that Service for licence calculation, so several linked Applications count as one service. Independent Applications remain counted individually. A service is active if any linked Application was synced in the previous 30 days, whether through a pipeline or directly.[1] See GitOps is licensed per Application unless service-based licensing is enabled and the program GitOps service-based licensing.
Exceeding the licence. “Harness does not block deployments when you exceed your licensed service count.” Pipelines and deployments continue.[1] The contract consequences are in the Subscription Terms: excess use is invoiced at the then-current License Unit rate, and exceeding the permitted License Units for 30 or more days is a Suspension Event.[5] See Exceeding the licensed CD service count does not block deployments.
Virtualization & partitioning
The CD unit abstracts away the infrastructure. Kubernetes pods, ECS tasks and virtual machines each count as service instances, and the ratio of 20 instances to one licence applies the same way to VMs and containers.[1] There is no rule for physical hosts, hypervisors or hard partitioning. The percentile method means that a cluster that scales out briefly, for example during a blue-green deployment, does not raise the counted instances unless the higher level persists for more than 5 percent of the 30-day samples.[1] See virtualization and partitioning.
Cloud / BYOL
Whether the delivery pipeline runs in Harness SaaS or in a self-managed installation, the counting is the same, and the documentation does not distinguish them.[1] Cloud Credits apply to pipeline stages executed on Harness cloud infrastructure, and execution time on customer-owned infrastructure is excluded from cloud compute minutes.[2]
Programs
- Other service-based modules. Service Reliability Management uses services with a 30-day active window, allowing .33 SRM Services per Developer.[2][3] Chaos Engineering uses services with a 365-day window and licences measured over a yearly cycle.[3][4] The Chaos mapping is 1:1 for Kubernetes workloads, VMs and cloud services, 5:1 for serverless functions and 100:1 for other targets.[4] The contract page calls this unit an RT Service and counts a Target Resource once in 12 months.[2]
- Developer 360 subscription model. The entitlement ratio of 1 service per 3 Developers.[3]
- View licence usage. Only users with account-level permissions can see subscription and licence data, and the Subscriptions page shows active services by deployment type, service instances tracked and historical consumption.[1]
Audits and compliance
CD licence data is self-service. The documentation says the subscription page shows “licensed service count, current consumption, and usage trends over time”, including which projects and services consume licences.[1] The Subscription Terms permit Harness to ask for “reasonable documentation evidencing current usage” and to confirm it with platform data.[5] Typical review points are services that were deployed once in the last 30 days but are no longer needed, services recreated under the same name, GitOps Applications that duplicate one service across environments, and pipelines whose custom stages have no service attached.[1]
Out of scope
- Prices per service, which Harness does not publish.
- Legacy licence models other than the two described in the CD documentation.
- Harness Open Source, which has no service-based licence and is described in Harness Open Source and editions.