> 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/cd-building-blocks/overrides-v2.md).
# Overrides V2
Manage service, environment, and infrastructure overrides in Harness Continuous Delivery
{% 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/cd-building-blocks/overrides-v2" featureFlags="%5B%7B%22name%22%3A%22Expose%20residual%20Overrides%20V1%20content%20in%20environment%20YAML%22%2C%22key%22%3A%22CDS\_OVERRIDES\_DISABLE\_ENV\_API\_UPDATES%22%2C%22status%22%3A%22BETA%22%2C%22description%22%3A%22Surfaces%20residual%20Overrides%20V1%20content%20in%20environment%20YAML%20so%20you%20can%20remove%20it%20after%20migrating%20to%20Overrides%20V2.%22%7D%5D" %}
{% endhint %}
Overrides V2 is the Harness Continuous Delivery (CD) experience for defining service, environment, and infrastructure overrides. In **Deployments**, open **Overrides** to define overrides for services, environments, and infrastructures at project, organization, and account scope.
{% hint style="info" %}
**Overrides V1**
For information on the earlier overrides model, go to [Environments overview](/continuous-delivery/use-continuous-delivery/cd-building-blocks/environments/environment-overview.md).
{% endhint %}
***
## What you will learn from this topic
* How to set the [permissions](#permissions) required for each override type
* How to configure [override types](#override-types) for manifests, config files, variables, and application settings
* How to [override service, environment, and infrastructure settings](#override-service-environment-and-infrastructure-settings) and understand [override priority](#override-priority)
* How to [manage overrides using Git Experience](#manage-overrides-using-git-experience)
***
## Before you begin
* **CD module access**: Open **Deployments** in a Harness project where Continuous Delivery is enabled.
* **Permissions**: You need the Create/Edit permissions listed under [Permissions](#permissions) for the override methods you plan to use. Go to [RBAC in Harness](https://developer.harness.io/docs/platform/role-based-access-control/rbac-in-harness) to assign roles.
* **Related entities**: Services, environments, and infrastructures that you want to override must already exist (or you create them as part of the override workflow).
***
## Permissions
The following override methods require these permissions:
* **Service & Infrastructure Specific**:
* `Service: Create/Edit`
* **Infrastructure Specific**: `Environment: Create/Edit`
* **Service Specific**:
* `Service: Create/Edit`
* **Global Environment**: `Environment: Create/Edit`
***
## Limitations
Overrides V2 has the following limitation:
* Runtime inputs are not supported for **Infrastructure Specific** and **Service & Infrastructure Specific** variables.
***
## Important notes
Keep the following in mind when you use Overrides V2:
* Overrides V2 supports infrastructure entities and infrastructure-and-service combinations. You can view them in a separate Overrides V2 section under Project, Org, and Account scopes.
* With Overrides V2, environment variables can be created only in the **Global Environment** variables section. You cannot create them in the **Environment** section.
* Service and Infrastructure continue to behave as before this change.
* If you continue to use Terraform scripts with Overrides V1 (without migrating to V2 scripts) while Overrides V2 is enabled, the Terraform plan can change and you may encounter errors while executing the V1 Terraform scripts.
* When overrides as part of remote environments are migrated, the overrides are created as inline overrides with Overrides V2. Inline overrides can be moved as remote entities using [APIs](https://apidocs.harness.io/tag/ServiceOverrides/#operation/serviceOverrideMoveConfigs).
* After migrating to Overrides V2, residual V1 override content may still be present in the environment YAML but not visible in the UI. This hidden V1 content can cause unexpected behavior in pipelines. To clean up, contact [Harness Support](mailto:support@harness.io) to enable the feature flag `CDS_OVERRIDES_DISABLE_ENV_API_UPDATES` on your account. Once enabled, the V1 overrides become visible in the YAML. Remove the V1 override content, and then request that the feature flag be disabled.
### Overrides V2 capabilities
Overrides V2 provides the following capabilities:
* **Greater flexibility**: Manage overrides for any CD entity, including service-specific environment overrides and **Global Environment** override variables.
* **Enhanced infrastructure variable management**: Manage infrastructure overrides and service-specific infrastructure overrides.
* **Independent management**: Overrides are represented as their own YAML object, which allows more streamlined and independent management.
* **More granular configuration**: Set up overrides at both the account and organizational level for service and environment entities within a project context.
For additional information about Overrides V2, go to the following resources:
* [API Management of Overrides](https://apidocs.harness.io/tag/ServiceOverrides#operation/createServiceOverride)
* [Terraform Management of Overrides](https://registry.terraform.io/providers/harness/harness/latest/docs/resources/platform_environment_service_overrides)
{% hint style="info" %}
**Account-wide Overrides V2**
When Overrides V2 is enabled on your account, it is enabled globally. Existing automation continues to work, and the APIs remain backward compatible with the V1 experience. You can search, filter, and sort overrides on the listing page, and the YAML view for Overrides V2 is available.
{% endhint %}
### Demo video
{% embed url="" %}
***
## Override types
Harness supports the following override types. Use the tabs to review each type.
{% tabs %}
{% tab title="Manifests" %}
You can override the following manifest types:
* Values YAML
* OpenShift Param
* Kustomize
* Helm Repo
* Tanzu Application Service (TAS) manifest
* TAS vars
* TAS AutoScalar
{% endtab %}
{% tab title="Config Files" %}
Config files are completely overridden.
Config files are a black box that can contain multiple formats and content, such as YAML, JSON, plain text, and similar formats. Consequently, they cannot be overridden like values YAML files.
{% endtab %}
{% tab title="Variables" %}
Like config files, variables are completely overridden.
You can use expressions to reference service variables. For example, `<+serviceVariables.VAR_NAME>`.
You can reference service variables in your pipeline steps, values YAML, JIRA steps, and so on.
Go to [Use Harness expressions](https://developer.harness.io/docs/platform/variables-and-expressions/harness-variables) to review variable expressions.
{% endtab %}
{% tab title="Application Settings and Connection Strings" %}
In [Azure App Service configuration](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/azure/azure-web-apps-tutorial.md#azure-web-apps-app-services-configuration), Web App settings **Application Settings** and **Connection Strings** can be passed as environment variables to the application code.
You can override **Application Settings** and **Connection Strings** from **Global Environment** overrides.
{% endtab %}
{% endtabs %}
***
## Override service, environment, and infrastructure settings
To override one or more settings for all services, environments, and infrastructures at the project, organization, or account level, perform the following steps:
1. In **Deployments**, select your project, and then select **Overrides**.
2. Select an override method:
* **Global Environment**
* **Service Specific**
* **Infrastructure Specific**
* **Service & Infrastructure Specific**
3. Select **New Override**.
4. Select a project, organization, or account-level override.
5. In **Override Type**, select one of the following override types:
* Variable
* Manifest
* Config File
* Application Settings (applicable to **Global Environment** override method only)
* Connection Strings (applicable to **Global Environment** override method only)
6. Override the setting.
***
## Override priority
The override priority from top to bottom is:
1. **Service & Infrastructure Specific** overrides
2. **Infrastructure Specific** overrides
3. **Service Specific** overrides
4. **Global Environment** overrides
Overrides defined at project, organization, and account levels have the following override priority:
1. Project
2. Organization
3. Account
***
## Manage overrides using Git Experience
When you create overrides, you can store them remotely or inline.
* **Inline**: Overrides are stored in the Harness Platform.
* **Remote**: Overrides are stored in a repository based on your choice.
### Move overrides from inline to remote
You can store overrides remotely in a repository. The following steps explain how to store overrides in GitHub. You can choose a source code repository of your choice.
1. Select **Overrides**.
2. Under the **Global Environment** tab, select your **Environment**.
You can select **Inline** or **Remote** code source under all override methods.
3. Select **Remote**.
4. In **Git Connector**, select or create a Git connector to the repository for your environment. Go to [Code Repo Connectors](https://developer.harness.io/docs/platform/connectors/code-repositories/ref-source-repo-provider) to configure a connector.
5. In **Repository**, select your repository. If your repository is not listed, enter its name.
Create the repository in GitHub before entering it in **Repository**. Harness does not create the repository for you.
6. Select **Git Branch**.
7. Harness Git Experience auto-populates the **YAML Path** based on the scope where overrides are configured, for example, `{scope}/overrides/harnessdevenv.yaml`.
8. Select **Save**.
{% hint style="info" %}
**Remote override requirements**
Keep the following in mind when you move overrides to Git:
1. Overrides also support [Bidirectional Sync](https://developer.harness.io/docs/platform/git-experience/gitexp-bidir-sync-setup).
2. When moving overrides to Git, the corresponding Environment must also be in Git.
3. Similar to environments, for Service-specific remote overrides, the Service must be remote.
4. For infrastructure specific overrides, the Infrastructure must be remote for the overrides to be moved to Git successfully.
5. You can clone service and environment overrides by copying the YAML configuration from an existing setup and reusing it with updated inputs.
6. You can replicate the same overrides across different Service-Environment combinations using the Clone option.
7. You can select a Git branch other than the default branch to store your Overrides.
{% endhint %}
***
## Next steps
* [Environments overview](/continuous-delivery/use-continuous-delivery/cd-building-blocks/environments/environment-overview.md): Learn about overrides V1 and how environments work in Harness.
* [API Management of Overrides](https://apidocs.harness.io/tag/ServiceOverrides#operation/createServiceOverride): Manage overrides using the Harness API.
* [Terraform Management of Overrides](https://registry.terraform.io/providers/harness/harness/latest/docs/resources/platform_environment_service_overrides): Manage overrides using the Harness Terraform provider.
* [Code Repo Connectors](https://developer.harness.io/docs/platform/connectors/code-repositories/ref-source-repo-provider): Connect a Git repository for remote overrides.
{% @harness-feedback/feedback %}
[^1]: Beta features are feature-complete but still being validated. Available on request.