Default settings
The Harness Default Settings are broadly scoped configurations that apply to your entire account, an entire organization in your account, or a specific project. These settings control configurations for certain Harness Platform features and high-level module settings.
To manage default settings at the account, org, or project scope, you need view and edit permissions for Default Settings at the corresponding scope.
Managed Default Settings
Default Settings include configurable module-specific parameters that you can customize based on your needs, such as enabling or disabling features at specific scopes.
When configuring default settings, be mindful of your current scope. For example, editing settings at the account scope applies the setting across the entire account.
- Account scope
- Organization scope
- Project scope
To access the Default Settings at the Account scope:
- Go to Account Settings.
- Select Default Settings.
To access the Default Settings at the Org scope:
- Select Organizations and select the organization you want to modify.
- Select Organization Settings, and then select Default Settings.
To access the Default Settings at the Project scope:
- Select Projects and select the project you want to modify.
- Select Project Settings, and then select Default Settings.
On the Default Settings screen, settings are divided into Platform (General), cross-module feature (Connectors, Notifications, Pipelines, AIDA), and module-specific settings (CCM, CD, Git Experience, SSCA).
Expand each section to configure the settings in that section. Available settings vary by scope.
Allow Overrides
If necessary, you can configure the Default Settings differently at the account, org, and project scopes.
To do this you must enable Allow Overrides at the account and/or org scope. This allows the setting to be overridden at lower scopes. Allow Overrides is not available at the project scope because that is the lowest scope.
To force lower scopes to inherit the configuration from a higher scope, disable Allow Overrides.
Restore to Default
All Default Settings are initially set to their default values. Once you modify a setting, you can quickly set it back to the default by selecting Restore to Default..
Default Settings reference
These are the Default Settings available for configuration at the Account scope. You can also configure Default Settings at the Org and Project scopes, but some options are not available at lower scopes.
General
Enable Force Delete of Harness Resources: You can force delete a Harness entity even if your pipelines or other entities reference it. For more information, go to Force delete.
Connectors
Disable Harness Secret Manager: You can choose to disable the Harness built-in Secret Manager at any point and use any other Secret Manager to store secrets. For more information, go to Disable built-in secret manager.
Continuous Deployment
These settings are for the Harness CD module.
- Enable Emails to be sent to non-Harness Users: To send emails to non-Harness users, you must configure your own SMTP server and enable this default setting.
- Project Scoped Resource Constraint Queue: Resource Constraints protect resource capacity limits by preventing simultaneous deployments to the same Service + Infrastructure combination. For more information, go to Resource constraints.
- Enable Native Helm steady state for jobs: By default, the steady state check is only performed for Harness-managed workloads. To perform steady state check for jobs in Native Helm Deployment, you must enable this setting.
- Fetch files from Git using provider-specific APIs: Utilize provider-specific APIs (works with GitHub, GitLab, Bitbucket, and Azure Repos) for efficient file retrieval from Git, instead of relying on JGit. This approach can encounter API rate limits. Refer to your Git provider's documentation for limit details.
- Disable addition of Harness track selector in Kubernetes deployments: During canary deployments, Harness adds a selector (
harness.io/track: stable
) in deployment objects during the rolling deployment phase. If there are pre-existing deployment objects in the cluster (not deployed by Harness), this can cause an errors. For more information, go to Skip Harness label selector tracking on Kubernetes deployments. - Ignore status code for HTTP connections: This setting is only relevant for HTTP steps and HTTP Helm repositories. When enabled, Harness only requires a valid response from the target HTTP server and does not verify the response code. This is useful when the Harness Delegate is configured with a proxy, because socket connection tests conducted by Harness from the delegate do not account for proxy details.
Continuous Integration
Currently, Harness-managed caching with self-managed build infrastructures is behind the feature flags CI_ENABLE_DLC_SELF_HOSTED
and CI_ENABLE_CACHE_INTEL_SELF_HOSTED
. Contact Harness Support to enable these features.
To use Harness CI Intelligence caching features, such as Cache Intelligence and Harness-managed Docker layer caching, with self-managed build infrastructures, you must provide S3-compatible object storage where Harness can store and manage your caches.
Use the S3-Compatible Object Store for Self-Managed Build Infrastructure settings to connect your S3-compatible object storage to your Harness account. If you want to define different object storage for individual organizations or projects, you must allow overrides and then change these settings at the lower scopes.
- Endpoint URL: S3-compatible storage URL.
- Region: Geographical region where your storage is hosted. This is optional for some providers.
- Bucket Name: The name of the bucket to use for Harness-managed caches.
- Access Key and Secret Key: Access key and secret key to access your S3-compatible storage. Currently, only access key and secret key authentication is supported. If you don't want to use this authentication method, consider other caching options.
This storage is only for Harness-managed caches (such as those created by Cache Intelligence) for builds that run on self-managed build infrastructure.
Self-managed build infrastructure is any build infrastructure other than Harness CI Cloud.
This doesn't apply to Harness CI Cloud because, when you use Harness CI Cloud with Harness-managed caches, Harness uses Harness-hosted Harness Cloud storage.
Git Experience
For information about these settings, go to Git Experience settings.
Pipeline
For information about these settings, go to Pipeline settings.
Cloud Cost Management
For information about these settings, go to Set up perspective preferences and View and apply recommendations.
Notifications
For information about these settings, go to Notification settings.
Supply Chain Assurance
These settings are for Harness SSCA.
- Use Base64 encoded secrets for attestation
- Enable SSCA Airgap
Harness AI Development Assistant
Enable this setting to use Harness AI Development Assistant (AIDA).