> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/manage-deployments/controlling-deployments-with-barriers-resource-constraints-and-queue-steps.md).

# Controlling resource usage with Barriers, Resource Constraints, and Queue steps

This topic describes how to control resource usage during Harness deployments.

{% hint style="info" %}
This feature is in Beta[^1] and requires enablement. [View all early access features.](/release-notes/features.md)

{% @harness-feature-flag-access/request-feature-flag-access module="continuous-delivery" pagePath="continuous-delivery/use-continuous-delivery/manage-deployments/controlling-deployments-with-barriers-resource-constraints-and-queue-steps" featureFlags="%5B%7B%22name%22%3A%22Project-scoped%20resource%20constraint%20queue%22%2C%22key%22%3A%22CDS\_PROJECT\_SCOPED\_RESOURCE\_CONSTRAINT\_QUEUE%22%2C%22status%22%3A%22BETA%22%2C%22description%22%3A%22Scopes%20resource%20constraints%20to%20the%20individual%20project%20instead%20of%20the%20account%2C%20preventing%20unrelated%20projects%20from%20queuing%20on%20the%20same%20infrastructure%20key.%22%7D%5D" %}
{% endhint %}

Harness offers several ways to control deployments and resource usage to protect resources and their capacity limits. This topic describes their differences and provides best practices.

## What you will learn from this topic

* How [Barriers](#barriers), [resource constraints](#resource-constraints), and [Queue steps](#queue-steps) are defined and scoped
* How to enable [resource constraint scoping at the project level](#resource-constraint-scoping-at-the-project-level)
* How to decide which control option to use, per the [best practices](#best-practices)

## Before you begin

* Review [Barriers](#barriers), [resource constraints](#resource-constraints), and [Queue steps](#queue-steps) individually, since each control option has a different scope and use case.

### Control option definitions <a href="#control-option-definitions" id="control-option-definitions"></a>

The following options help you control how deployments use your resources.

### Barriers <a href="#barriers" id="barriers"></a>

Barriers synchronize stages/[step groups](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/step-groups.md) of a Pipeline that are executed in parallel. Barriers ensure that one stage/step group does not proceed until another stage/step group has reached a specific point.

For more information, see [Synchronize Parallel Stages and Step Groups using Barriers](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/flow-control/synchronize-deployments-using-barriers.md).

**Barriers Scope**

Barriers are scoped to the **Pipeline**.

You can only use the same Barrier within the same Pipeline. If you add a **Barrier Name** from one Pipeline into the Barrier step in another Pipeline, it will not work.

### Resource constraints <a href="#resource-constraints" id="resource-constraints"></a>

Resource Constraints protect resource capacity limits by preventing simultaneous deployments to the same Service + Infrastructure combination. The Harness service + infrastructure combination acts as a fixed key called the Infrastructure Key. The Infrastructure Key (the unique key used to restrict concurrent deployments) is formed by combining the Harness service ID, environment ID, connector ID, and infrastructure ID.

By default, this key is scoped at the Harness account level. This means that if the infrastructure is reused in different Harness projects with the same combination of service ID + environment ID + connector ID + infrastructure ID, it can result in queuing of the infrastructure. Consequently, your pipelines will build up in a waiting state.

Resource Constraints are added to every Stage by default, but they can be disabled in a Stage's **Infrastructure** settings by enabling the **Allow simultaneous deployments on the same infrastructure** option.

For more information, see the [Pipeline Resource Constraints](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-resource-constraints.md).

The automatic **Resource Constraints** setting does not apply to [Custom stages](https://developer.harness.io/harness-platform/use-harness-platform/pipelines/add-a-stage#add-a-custom-stage). **Resource Constraints** apply to a combination of Service + Infrastructure, and Custom Stages have no Services or Infrastructures. You can use Barriers and Queue steps in any stage type.

{% hint style="info" %}
**NOTE**

When an environment is added to a Custom Stage, resource constraints do apply, and jobs may get queued based on the environment and infrastructure combination.
{% endhint %}

### Resource constraint scoping at the project level <a href="#resource-constraint-scoping-at-the-project-level" id="resource-constraint-scoping-at-the-project-level"></a>

{% hint style="info" %}
This capability is behind the feature flag `CDS_PROJECT_SCOPED_RESOURCE_CONSTRAINT_QUEUE`. Contact [Harness Support](mailto:support@harness.io) to enable the feature.
{% endhint %}

By default, resource constraints are scoped at an account level. This means that if the infrastructure is reused in different Harness projects with the same combination of service ID + environment ID + connector ID + infrastructure ID, it can result in queuing of the infrastructure. Consequently, your pipelines will build up in a waiting state.

With Resource constraint scoping at the project level, you can scope the resource constraint down to the individual project.

This scoping ensures that the resource constraint is limited to a particular project and does not affect other projects that use the same combination of service ID + environment ID + connector ID + infrastructure ID.

With project-level scoping, the Infrastructure key (the unique key used to restrict concurrent deployments) is formed with the Harness account ID + org ID + project ID + service ID + environment ID + connector ID + infrastructure ID.

This scoping ensures that there are unique resources across projects and prevents queues caused by other project teams deploying to the same infrastructure.

### Queue steps <a href="#queue-steps" id="queue-steps"></a>

Queue Steps synchronize Pipeline executions, queuing Pipelines using a custom key.

Multiple deployments are queued so that one deployment completes before other deployments with the same key can proceed.

For more information, see [Control resource usage with Queue steps](/continuous-delivery/use-continuous-delivery/manage-deployments/control-resource-usage-with-queue-steps.md).

**Queue Step Scope**

Queue steps are scoped to your entire Harness **account**.

If there are Queue steps with the same Resource Key in Pipelines in Projects A and B, and the Pipeline in Project A is running, the Pipeline in Project B will be queued until the Pipeline in Project A is completed.

### Best practices <a href="#best-practices" id="best-practices"></a>

Here are some best practices to help you decide which resource control option to use:

* **Barriers**: use when you want to coordinate the timing of different components' deployments with stages/step groups that are executed in parallel within the same Pipeline.\
  For example, your Pipeline executes Stages A and B in parallel, but you want a database migration in Stage A to complete before a deployment in Stage B. You place a Barrier step after the migration in Stage A and before the deployment step in Stage B.
* **Resource Constraints**: Use when you want to prevent simultaneous deployments to the same Service-Infrastructure combination. This feature is enabled by default.
* **Queue steps**: use when you want to control the **sequence** of multiple Pipeline executions. This can be used on different Pipelines or even multiple executions of the same Pipeline.

## Next steps

* Go to [Control resource usage with Queue steps](/continuous-delivery/use-continuous-delivery/manage-deployments/control-resource-usage-with-queue-steps.md) to configure a Queue step.
* Go to [Pipeline Resource Constraints](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-resource-constraints.md) to review Resource Constraint behavior.
* Go to [Synchronize Parallel Stages and Step Groups using Barriers](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/flow-control/synchronize-deployments-using-barriers.md) to configure a Barrier step.

{% @harness-feedback/feedback %}

[^1]: Beta features are feature-complete but still being validated. Available on request.