To manage an AWS instance or a DNS record, Terraform needs a provider for the relevant system. Terraform Core determines which operations to perform and in what order; the provider exposes the system’s resources, data sources, and functions and communicates with its API. The provider is a plugin, while a provider server is its running implementation that serves operations to Terraform. section 1.2 section 1.2.3 section 12.4.4
Choose providers by the systems you need to manage, then consult their registry documentation for available components and settings. Declare the provider source and configure its connection in the root module; a project can use several providers or multiple configurations of one provider. Run `terraform init` to install required plugins. Its lock file records the selected versions so future initialization can make the same selections by default. section 2.4 section 2.4.1 section 8.4 section 1.4.2
A provider for posts and account lookups
A configuration declares `terraformindepth/mastodon` in `required_providers`, sets `host` in `provider "mastodon"`, looks up an account with `data "mastodon_account"`, and creates a post with `resource "mastodon_post"`. The data source and resource are components supplied by that provider, not built-in Terraform resource types. section 12.1 section 2.5
Most users need not write a provider. If a platform lacks one, design its public resources, data sources, and functions before implementation: incompatible changes can affect many modules. Provider development uses Go and the Terraform Plugin Framework. Tests can create a provider server through a factory and check required credential environment variables before testing resources or data sources. For ordinary infrastructure tests, focus on your configuration’s logic rather than retesting a well-tested provider. section 12.1 section 12.9 section 12.4.4 section 9.1.1
