Provider Sets separate provider configuration from module code, making it easier for platform teams to reuse existing Terraform modules across no-code provisioning and self-service workflows.
Terraform modules help platform teams standardize and reuse infrastructure. But using those same modules with no-code provisioning has historically come with an important constraint: provider configuration needs to be included directly in the module code.
This means modules designed for traditional Terraform workflows may need to be modified or duplicated before they can be offered through no-code provisioning.
Today, we're changing that with Provider Sets, which allow platform teams to define provider configuration separately and reuse it across projects and workspaces.
»The provider configuration challenge
Consider a platform team that maintains a standard AWS RDS module.
The module defines what infrastructure should be created, while the provider configuration may intentionally live outside the module. That's common in traditional Terraform workflows. But no-code provisioning also needs enough information to configure the provider when Terraform creates and runs the workspace.
Historically, this meant modules intended for no-code provisioning needed to include their provider configuration directly in the module.
For organizations operating across multiple accounts, regions, or projects, this can lead to duplicated modules and provider configuration and limit which existing modules can be offered through self-service.
»Introducing Provider Sets
Provider Sets allow platform teams to define provider configuration centrally in HCP Terraform and reuse it across projects and workspaces.
For example, a platform team could define an AWS Provider Set:
provider "aws" {
region = var.aws_region
profile = var.aws_profile
}
When Terraform creates a workspace through a no-code workflow, the assigned Provider Set is automatically applied. The module remains focused on what infrastructure should be created, while the Provider Set determines how Terraform configures the provider.
Provider Sets include:
Reusable provider configuration: Define provider configuration once and reuse it across multiple modules and workspaces.
Flexible scoping: Apply Provider Sets globally across an organization or scope them to specific projects and workspaces.
Variable interpolation: Reference Terraform variables so the same Provider Set can adapt across accounts, regions, and environments.
Workspace overrides: Use project-level provider configuration as a default while allowing workspace-level configuration to override it when needed.
For example, the same Provider Set could reference:
provider "aws" {
region = var.aws_region
}
A project might define:
aws_region = "us-east-2"
while a particular workspace defines:
aws_region = "eu-central-1"
Terraform resolves the value through the existing variable hierarchy, allowing the same Provider Set to adapt across projects and workspaces without duplicating the provider configuration.
Platform teams can also create different Provider Sets for different needs, such as aws-production, aws-development, azure-production, or gcp-development.
»Bring existing modules to no-code provisioning
By separating provider configuration from module code, modules no longer need an embedded provider block simply to participate in a no-code workflow.
Platform teams can take existing Terraform modules, pair them with the appropriate Provider Sets, and make them available through no-code provisioning without maintaining separate self-service-specific copies.
For application developers, the provider complexity remains behind the platform boundary. Developers select the infrastructure they need and provide the inputs exposed by the platform team, while Terraform handles the provider configuration required to provision it.
Provider Sets are also designed to preserve existing workflows. Modules that already contain provider configuration can continue to work without modification, allowing organizations to adopt Provider Sets incrementally rather than migrating their entire module catalog at once.
»Use Provider Sets with Terraform Developer Portal self-service and agentic workflows
Provider Sets extend the same separation of concerns to self-service workflows in the Terraform Developer Platform (TDP).
TDP allows platform teams to define reusable infrastructure patterns that developers can discover and provision through self-service workflows. Provider Sets allow platform teams to manage the provider configuration needed by those workflows separately, keeping provider complexity behind the platform boundary.
For example, a platform team could make an approved AWS module available through TDP while using Provider Sets to manage the provider configuration needed across different accounts, projects, or environments. Developers can focus on the infrastructure they need and the inputs relevant to their application, without needing to understand or construct the underlying provider configuration.
This creates a clear platform boundary: platform teams define how infrastructure connects to providers, while developers choose what infrastructure they need.
The same model also extends to automated and agent-driven self-service.
Provider Sets are accessible through the HCP Terraform API and can be managed through tfctl, allowing automation and coding agents to discover and work with platform-defined provider configuration rather than constructing provider blocks themselves.
For example:
tfctl api /organizations/{organization}/provider-sets \
-a name=my-aws-provider-set \
-a description="Shared AWS provider config" \
-a "provider-source=registry.terraform.io/hashicorp/aws" \
-a global=true \
-a priority=false \
-a 'configuration-hcl=provider "aws" {\n region = var.region\n}'
Because tfctl exposes the documented HCP Terraform API through its OpenAPI foundation, these workflows can work across different coding agents and automation environments without requiring a custom integration for each one.
An agent could help a platform engineer discover existing Provider Sets, create or update one, or use the appropriate platform-defined configuration as part of a TDP self-service workflow. The agent helps execute the workflow, while HCP Terraform remains the source of truth for provider configuration and governance.
This allows TDP self-service to extend across human and agent-driven workflows, without requiring developers or agents to recreate provider configuration themselves.
»A more reusable foundation for Terraform self-service
Provider Sets solve a provider configuration problem, but the impact extends to self-service.
By separating what infrastructure a module creates from how its provider is configured, platform teams can reuse more of the Terraform modules they already maintain across no-code provisioning and emerging self-service workflows.
Provider Sets make existing Terraform modules more reusable as self-service building blocks while keeping provider configuration centrally managed by platform teams.
Ready to get started? Explore the Provider Sets documentation to learn how to configure and reuse provider configurations across your Terraform no-code provisioning workflows.
