CD service licensing
How Harness CD module tracks and consumes service-based licensing
The Harness Continuous Delivery and GitOps (CD) module uses services as the core construct for defining and managing the software you deploy. Services represent the deployable units of your applications, whether they are containerized workloads, traditional virtual machines, serverless functions, or custom deployment targets.
Harness offers 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 models only count services that have been deployed within the last 30 days, ensuring you pay only for what you actively use. Go to Subscriptions and licenses to understand the broader Harness licensing framework and how Developer 360 works across modules.
What you will learn
Service definition: How Harness defines a service across different deployment types (Kubernetes, VMs, serverless, GitOps, custom).
Active service window: What makes a service count as active (30-day deployment window) and how service instances are tracked.
License consumption ratios: How different deployment types consume service licenses (containerized, traditional, serverless, custom, GitOps).
95th percentile calculation: Why Harness uses the 95th percentile of service instances to ignore temporary spikes and keep licensing fair.
Service tracking improvements: Recent enhancements to tracking (GitOps services, serverless valuation, pipeline executions without services).
Service
The CD module deploys software services to infrastructure platforms spanning traditional VMs, Kubernetes, public cloud platforms, serverless functions, and other custom deployment targets. A service is an independent unit of software you track and manage through Harness CD and GitOps.
A Harness CD service typically maps to one of the following:
A service in Kubernetes (a deployment, statefulset, or daemonset)
An application synced via GitOps to a unique infrastructure destination
A containerized service on a cloud platform such as AWS ECS or Azure Container Instances
A virtual machine in traditional VM-based applications
A serverless function in environments such as AWS Lambda or Google Cloud Functions
A custom definition (Harness CD allows custom service definitions for unsupported platforms)
Active service
Services deployed using the CD module in the last 30 days are considered active services. Both the service-based and Developer 360 licensing models only consume licenses for active services. This means services created and deployed more than 30 days ago no longer consume any licenses with Harness CD, ensuring license consumption reflects only active usage.
Service lifecycle after 30 days: When a service has not been deployed for more than 30 days, it stops consuming a license. If you redeploy that service later, it becomes active again and resumes consuming a license. The service identity is preserved, so redeployment does not count it as a new service for license tracking purposes.
Service renaming and migration: Renaming a service in Harness preserves its license tracking history. If you delete a service and recreate it with the same name, Harness treats it as a new service for license tracking purposes, and its 30-day activity window starts fresh.
Service instances
Service instances (SIs) refer to the pods or instances of a service deployed to a host. The CD module continuously tracks the instances of each service deployed, at a 60-minute cadence, allowing administrators to monitor these instances and service versions across different infrastructure hosts.
Service instances play a key role in how license consumption works:
Tracking cadence: Harness tracks all service instances for all deployed services every 60 minutes.
95th percentile calculation: When reporting for license consumption, 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 service instances. This approach is beneficial because it ignores temporary spikes in instance counts. The top 5 percent of your highest instance counts are excluded, so activities like load testing, blue-green deployments, or other temporary scaling events do not artificially inflate your license usage. Licensing stays true to your steady-state instance counts.
License consumption: For most deployment types, one service license is consumed for every 20 service instances (see exceptions below for serverless and custom deployments).
Service license consumption for active services
Only active services (services deployed in the last 30 days) consume one or more service licenses. The following sections explain how Harness CD consumes service licenses across different deployment scenarios.
Containerized applications
Harness CD deploys containerized services to architectures such as Kubernetes, Amazon ECS, Tanzu Application Services, and Azure WebApps. In all these architectures, Harness tracks pods of services as service instances, as explained in the section above. Service instances are tracked the same way whether a service is deployed using pipelines or synced using GitOps.
License consumption: Harness CD consumes 1 service license for every 20 service instances of a service.
Examples:
A CD service running 5 service instances (95th percentile of last 30 days of instance tracking) will consume 1 service license.
A CD service running 25 service instances (95th percentile of last 30 days of instance tracking) will consume 2 service licenses.
Traditional (non-containerized) applications
Harness deploys traditional VM-based applications (non-containerized) to architectures such as Amazon AMI/ASG, Azure WebApps, and WinRM or SSH to VMs. In all these architectures, Harness tracks instances of the service as every VM deployed.
License consumption: Harness CD consumes 1 service license for every 20 service instances of a service.
Examples:
A CD service running 5 service instances will consume 1 service license.
A CD service running 25 service instances will consume 2 service licenses.
Serverless functions
Harness deploys serverless functions to architectures such as AWS Lambda, AWS SAM, Google Cloud Functions, Serverless.com Framework, and Azure Functions. In all these architectures, Harness does not track instances of functions deployed, since serverless functions scale dynamically and instance counts are not meaningful for license tracking.
License consumption: Harness CD consumes 1 service license for every 5 unique functions deployed.
Examples:
5 unique functions deployed in the last 30 days will consume 1 service license.
25 unique functions deployed in the last 30 days will consume 5 service licenses.
Custom deployments
Harness allows custom deployments using deployment templates to support deployments to architectures not yet natively supported by Harness CD. From a license tracking perspective, Harness encourages all customers to configure an instance fetch script as part of the custom deployment, which returns the instances of this service deployed on the target architecture.
There are two scenarios:
Instance fetch script is configured: The instance fetch script is properly configured and Harness has steady visibility to all service instances for the service.
Harness CD consumes 1 service license for every 20 service instances of the custom service.
Instance fetch script is not configured: The instance fetch script is not properly set up or functioning as expected, and Harness has no visibility to service instances for the service.
Harness CD consumes 1 service license for each active custom service.
Pipelines with no service
Harness allows custom deployments where no service is associated with the deployment. This can happen when a pipeline execution only runs infrastructure provisioning steps, only performs shell script executions, or runs a custom stage with the environment configured but no service. In all these scenarios, the lack of service configuration means Harness loses the default license tracking.
License consumption: Harness CD consumes 1 service license for every 2000 executions of such custom stages.
Custom stages are more than a logical division. Each custom stage counts as one pipeline execution. For example, if a pipeline has two custom stages, then executing that pipeline will use 2 executions in relation to service license consumption.
View your license usage
Harness provides visibility into your service license consumption through the subscription management interface. To view your current license usage, navigate to Account Settings and select Subscriptions in the Harness Platform. This page displays your licensed service count, current consumption, and usage trends over time.
Who can view license data: Only users with account-level permissions can access subscription and license usage data. Account administrators can assign these permissions through RBAC roles. Go to RBAC in Harness to understand permission management and Manage roles to configure access for your team.
License usage metrics: The subscription page shows active services by deployment type, service instances tracked, and historical consumption trends. This helps you understand where your license usage is coming from and identify opportunities for optimization.
Subscription page walkthrough
The subscription page provides an intuitive interface for visualizing what services are being tracked, giving you greater visibility and control over your deployments. You can view real-time data on active services, service instances, and how your consumption aligns with your licensed capacity.
The following video demonstrates how to navigate the subscription page and interpret license usage data:
Key features shown in the video:
Navigating to the subscription page from Account Settings
Understanding the breakdown of active services by deployment type
Viewing service instance counts and the 95th percentile calculation
Monitoring consumption trends over the last 30 days
Identifying which projects and services are consuming licenses
CD Service
1 Service = 20 SI
1 Service = 20 SI
No change in licensing rules.
GitOps Service
Not measurable by customer, not calculated in product
1 GitOps Service = 20 SI (1 Service)
New service tracking introduced for GitOps Services. With the CDS_GITOPS_SERVICE_BASED_LICENSING feature flag, Applications linked to a Harness Service use the Service for license calculation. Go to GitOps service-based licensing to learn how this affects license calculation.
Pipeline Execution (Deployments w/o Service)
Not measurable by customer, not calculated in product
2000 Executions = 1 Service
New service tracking introduced for Deployments without service. Specifically, per Stage Execution. If a Pipeline has 5 Stages with no service being deployed, we bill 5 Executions.
Serverless Services
1 Function = 1 Service
1 Function = 0.2 Service For SI based - No Charge
Adjusted valuation to 0.2 Service per function.
Harness does not block deployments when you exceed your licensed service count. If your active service count grows beyond your purchased license capacity, your account continues to function normally, and all pipelines and deployments execute without interruption.
GitOps service-based licensing
By default, Harness calculates CD license usage based on Services, but calculates GitOps license usage based on Applications. This can cause a usage discrepancy when the same service deploys to multiple environments through separate GitOps Applications, because each Application counts independently toward license consumption even though they share the same underlying service and manifests.
To address this, Harness offers service-based licensing for GitOps behind the CDS_GITOPS_SERVICE_BASED_LICENSING feature flag. When this feature flag is enabled, Harness uses the following logic to calculate GitOps license usage:
Application linked to a Harness Service: Harness uses the linked Service for license calculation, consistent with how CD licensing works. Multiple Applications that share the same Service count as a single Service for licensing purposes.
Independent Application (no service linkage): Harness continues to use the existing Application-based model. Each independent Application counts separately toward license consumption.
Active service window for GitOps service-based licensing
When service-based licensing is enabled, a service is considered active if any GitOps application linked to that service has been synced within the previous 30 days. This includes both pipeline-driven syncs and direct application syncs initiated from the GitOps Applications page.
For example, suppose a service is linked to three GitOps applications across different environments. If any one of those applications is synced, either through a pipeline or directly, the service is considered active for the applicable 30-day period.
Once a service is identified as active, Harness applies the standard 95th percentile calculation across all service instances.
This approach ensures that GitOps activity is reflected in license calculations regardless of whether the sync is initiated through a pipeline or directly from the GitOps Applications page.
Subscription dashboard display
When the CDS_GITOPS_SERVICE_BASED_LICENSING feature flag is enabled, the subscription dashboard displays GitOps license usage in separate tabs within the Past 30 Days Usage Details section:
Services: Displays GitOps applications that are linked to Harness services and are included in service-based licensing.
GitOps Applications (not linked to service): Displays independent GitOps applications that are not linked to a Harness service and are included in application-based licensing.

This separation provides visibility into how GitOps applications contribute to license consumption under the different licensing models.
Customer FAQs for the improved Service Tracking
Visibility and alerts: The subscription page displays an over-limit indicator when your consumption exceeds your licensed capacity. Account administrators receive notifications through the Harness Platform to alert them of the overage.
Contract adjustments: When you consistently exceed your licensed capacity, your account team will work with you to adjust your contract to match your actual usage and needs. Harness is committed to making this process transparent and collaborative. License increases are not automatic upcharges. Instead, Harness works with you to understand your usage patterns and ensure your subscription aligns with your deployment scale.
Optimization opportunities: If you want to reduce service license consumption before contract renewal, you can identify inactive services, consolidate similar deployments, or review your deployment architecture. The subscription page provides detailed usage data to help you identify optimization opportunities. Go to the subscription page walkthrough section above for guidance on using these metrics.
Improved service license tracking
Harness has enhanced service tracking capabilities to provide more accurate visibility into what is being deployed and managed through the CD module. These improvements ensure that billing reflects the comprehensive set of features you use, promoting fairness and transparency.
The following table summarizes the changes:
CD Service
1 Service = 20 SI
1 Service = 20 SI
No change in licensing rules.
GitOps Service
Not measurable by customer, not calculated in product
1 GitOps Service = 20 SI (1 Service)
New service tracking introduced for GitOps Services.
Pipeline Execution (Deployments without Service)
Not measurable by customer, not calculated in product
2000 Executions = 1 Service
New service tracking introduced for deployments without a service. Specifically, per stage execution. If a pipeline has 5 stages with no service being deployed, we bill 5 executions.
Serverless Services
1 Function = 1 Service
1 Function = 0.2 Service (For SI-based, no charge)
Adjusted valuation to 0.2 Service per function.
GitOps service tracking: GitOps has become a core feature of Harness CD and is widely adopted by customers. Including GitOps services in the billing model ensures that billing accurately reflects the comprehensive set of features you use.
GitOps multi-cluster scenarios: A GitOps application synced to multiple clusters using ApplicationSets or multiple sync destinations counts as one service if it deploys the same workload definition. Each unique infrastructure destination counts separately for service instance tracking. For example, an application synced to three Kubernetes clusters counts as one service, but the pod counts across all three clusters contribute to the total service instance count for the 95th percentile calculation.
Serverless valuation adjustment: By adjusting the valuation to 0.2 of a service per serverless function (or 1 service for every 5 functions), customers deploying serverless architectures experience reduced costs associated with these functions. This change makes it more cost-effective to leverage serverless deployments.
Frequently asked questions
Related concepts
Now that you understand how CD service licensing works, explore related subscription and governance topics:
Subscriptions and licenses: Learn about the Developer 360 model and how developer licenses include service entitlements across modules.
RBAC in Harness: Understand how to assign permissions for viewing and managing license data at the account level.
Manage roles: Configure roles and permissions for license administrators in your organization.
Services and environments overview: Learn how to define and manage services in Harness CD.
For assistance with licensing questions or contract adjustments, contact your Harness account representative or reach out to Harness Support.
Last updated
Was this helpful?