> 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/troubleshooting-and-resources/resources/new-user/manage-inputsets-at-scale.md).

# 12. Manage Deployment Input Sets at Scale

Recommended practices for managing input sets as pipeline runtime inputs grow

This topic collects practices for managing input sets as their use increases, and what goes wrong when teams skip them. Apply these practices as you design pipelines that take many runtime values.

[Input sets](https://developer.harness.io/docs/platform/pipelines/input-sets) are collections of pipeline settings and parameters that are passed into a pipeline at runtime. [Runtime inputs](https://developer.harness.io/docs/platform/variables-and-expressions/runtime-inputs) provide placeholders that you define at runtime manually or with input sets.

For example, if the pipeline deploys Kubernetes manifests, the input set can supply the `values.yaml` used in the pipeline. Input sets also reduce manual input from developers and reduce human error.

As you configure input sets for your pipelines, the number of input set variations and fields can grow. Use the following practices to keep that growth manageable.

***

## Reduce the number of runtime inputs

Evaluate which settings and parameters must be exposed as runtime inputs. Every extra runtime field increases the chance of a wrong value at run time.

If some inputs change only when services deploy to different environments, use overrides so the pipeline computes those parameters from the deployment context. If you keep every environment-specific value as a runtime input instead, developers must fill the same fields on every run, and mistakes multiply across environments.

![Overrides reduce environment-specific runtime inputs](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-594867395c81f9af623725a141934acf4c10efc6%2F18deb6777616e00dea76b396df942fd34eb0c4b07c13f359d9d0b862692af868.png?alt=media)

Go to [Overrides](/continuous-delivery/use-continuous-delivery/cd-building-blocks/overrides-v2.md) to configure service and environment overrides.

***

## Fix values that do not need to change at runtime

Review which parameters can be fixed values instead of runtime inputs. Fixed values shrink the form developers must complete.

In this scenario, configure a partially completed input set and let developers enter only the inputs they need. If you leave every field as a runtime input, each run becomes a long form, and teams recreate the same defaults by hand.

***

## Combine input sets with overlays

You can combine multiple input sets into overlays. When you run the pipeline, you choose which input sets to use for that run.

![Select overlay input sets at runtime](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-3f99d29607f82683c39a130dc07f55ff00763b98%2F73734cfdc84d30c6f89724b15c5e815aa50170052a78eab3c86812af2a69e4f0.png?alt=media)

With overlays, you do not have to define every runtime input value in every input set. That gives a flexible, build-your-own input set experience. At runtime, users can provide an overlay input set to fill the pipeline configurations needed for that run.

If you maintain one large input set per team and environment instead, duplication grows, and a shared change must be edited in many files.

***

## Store and review input sets in Git

Multiple teams might use the same pipeline to deploy their services. A common pattern is one generic pipeline with numerous input sets per team. For example, each team might have seven input sets, one per environment.

Manage the input sets in Git so every edit goes through a pull request where release leads can review changes before they propagate to Harness. If you edit input sets only in the UI without review, incorrect runtime values can reach production without an audit trail.

![Input sets managed through Git Experience](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-48ea787ccc716335d3869bffa0903dcbb033aa50%2F7da4b83599ed61a061326d86885f366e38b99131717b6a4970f2a489264f95f2.png?alt=media)

Go to [Harness Git Experience overview](https://developer.harness.io/docs/platform/git-experience/git-experience-overview) to store pipelines and input sets in Git.

***

## Restrict who can edit pipelines and input sets

Use resource groups and roles to manage access. With resource groups, you can control access to the resources that the input set impacts, such as services, environments, and pipelines.

Allow users to execute the pipeline and access certain services and environments, but remove pipeline create and edit access. That pattern forces configuration changes through Git and pull request review. Developers also cannot run pipelines with input sets against resources they cannot access.

If you grant broad pipeline edit permission, developers can change runtime contracts and target environments without review, and RBAC on services or environments alone will not stop those edits.

![Resource groups limit pipeline edit access](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-b1aa699a4640b403e76b455662770017f6fec75e%2Fa31cc9bd75687be9c20515e6b3703ef2105e430da3014094d627251f0b85a224.png?alt=media)

Go to [Manage resource groups](https://developer.harness.io/docs/platform/role-based-access-control/manage-resource-groups) to configure resource groups.

***

## Next steps

* [Input sets and overlays](https://developer.harness.io/docs/platform/pipelines/input-sets): Create and combine input sets for pipeline runs.
* [Overrides](/continuous-delivery/use-continuous-delivery/cd-building-blocks/overrides-v2.md): Move environment-specific values out of runtime forms.
* [Harness Git Experience overview](https://developer.harness.io/docs/platform/git-experience/git-experience-overview): Store input sets in Git for review.
* [Manage resource groups](https://developer.harness.io/docs/platform/role-based-access-control/manage-resource-groups): Limit who can edit pipelines and related resources.

{% @harness-feedback/feedback %}