Terraform provider

The DX Terraform provider lets you manage your DX configuration as code. It supports configuring and maintaining the Catalog and Scorecards within DX Fabric.

It ensures Fabric configuration is versioned, reviewed, repeatable, and promoted through the same delivery workflows you already use for infrastructure.

The Registry page is the source of truth for installation, provider configuration, resources, data sources, and examples supported by the current release.

Why use the Terraform provider

Managing Fabric configuration in Terraform is useful when DX is part of your broader platform setup. Instead of making one-off changes in the UI, DX resources can be defined in code, reviewed in pull requests, and applied consistently.

Key benefits of the cases for the Terraform provider include:

  • Standardization: Keep DX configuration aligned across business units, environments, or newly onboarded organizations.
  • Change control: Review DX changes in pull requests and keep an auditable history in Git.
  • Repeatability: Recreate the same DX setup without manually clicking through the product.
  • Platform integration: Manage Fabric-related DX configuration alongside the rest of your internal platform and infrastructure code.

Common use cases

The Terraform provider can be leveraged to do the following:

  • Configure Fabric setup for Software Catalog and Scorecards: Define shared configuration in code instead of applying changes manually.
  • Manage shared platform configuration: Keep central DX configuration in the same repository as related platform code and policy.
  • Roll out updates safely: Propose changes through pull requests, validate them in CI, and apply them with the rest of your infrastructure changes.
  • Reduce configuration drift: Use Terraform state and plans to make intended DX configuration explicit.

Common workflows

Author configuration in code

Define your DX provider configuration and Fabric resources in Terraform files, then commit them to the repository your team uses for infrastructure or platform automation.

For the current provider arguments, resources, and data sources, check out the Terraform Registry Docs.

Review and plan changes

Run terraform plan in CI or locally before applying changes. This makes DX configuration updates visible in the same review flow as infrastructure changes.

This workflow is useful when Fabric configuration changes need coordination across platform, operations, or engineering leadership teams.

Staging rollout of new scorecard checks

Define new scorecard checks as PRs, send them for leadership review, apply them on a set date after you’ve communicated to your org the changes coming.

Use the UI for discovery, Terraform for durability

Many teams discover or validate configuration in DX first, then move durable Fabric setup into Terraform. That keeps the UI useful for exploration while reserving Terraform for changes that should be repeatable and tracked.

Getting started

Start with the provider reference and repository: