> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Handling Providers
> Explains how Terraform discovers, downloads, versions, initializes, and reuses providers, plus using terraform init, provider sources, version locking, and registry best practices for reproducible workflows
In this lesson you'll learn how Terraform discovers, downloads, versions, initializes, and reuses providers across runs. Mastering this flow helps with reliable team workflows, reproducible CI runs, and faster troubleshooting when provider plugins cause issues.
Start with the core command:
```bash theme={null}
$ terraform init
```
terraform init prepares the working directory — it initializes the backend, locates required providers from your configuration, and downloads provider plugins into the project. Importantly, terraform init does not change infrastructure; it sets up the environment so subsequent commands like terraform plan and terraform apply can run.
Example configuration referencing multiple providers:
```hcl theme={null}
# Azure Provider
provider "azurerm" {
features {}
}
# AWS Provider
provider "aws" {
region = "us-east-1"
}
# Local Provider (used for creating local files)
provider "local" {}
```
Provider publication and trust model
* Providers are typically published to the Terraform Registry and are organized by publisher/namespace.
* Providers fall into three common tiers: Official (HashiCorp-maintained), Verified/Partner (vendor-validated), and Community (third-party).
| Provider Tier | Description | Examples |
| ------------------ | --------------------------------------------------------------------------------------------- | -------------------------------------------------------- |
| Official | Maintained by HashiCorp; generally recommended for production | `hashicorp/azurerm`, `hashicorp/aws`, `hashicorp/google` |
| Verified / Partner | Vendor-supported and validated by HashiCorp; good balance of support and feature coverage | `microsoft/azapi` (example partner provider) |
| Community | Community-maintained providers; useful for niche use cases but evaluate before production use | Various independent authors |
What happens during terraform init
1. Initialize the configured backend.
2. Discover required providers referenced in configuration.
3. Query the Registry for provider metadata (namespace, available versions).
4. Download and install provider binaries into the project directory.
Example terraform init output (first run):
```bash theme={null}
$ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding latest version of hashicorp/azurerm...
- Finding latest version of hashicorp/aws...
- Finding latest version of hashicorp/local...
- Installing hashicorp/azurerm v4.28.0...
- Installed hashicorp/azurerm v4.28.0 (signed by HashiCorp)
- Installing hashicorp/aws v5.97.0...
- Installed hashicorp/aws v5.97.0 (signed by HashiCorp)
- Installing hashicorp/local v2.5.2...
- Installed hashicorp/local v2.5.2 (signed by HashiCorp)
Terraform has created a lock file: terraform.lock.hcl to record the provider selections it made above. Include this file in your version control repository so that Terraform can guarantee to make the same selections by default when you run "terraform init" in the future.
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure.
```
Provider binaries and workspace layout
* Provider plugins are stored inside your project under the `.terraform` directory (they are not installed globally). Example listing:
```bash theme={null}
$ ls -lah .terraform/providers/registry.terraform.io/hashicorp/
total 20K
drwxr-xr-x 5 rithin rithin 4.0K May 12 02:31 .
drwxr-xr-x 3 rithin rithin 4.0K May 12 02:31 ..
drwxr-xr-x 3 rithin rithin 4.0K May 12 02:31 aws
drwxr-xr-x 3 rithin rithin 4.0K May 12 02:31 azurerm
drwxr-xr-x 3 rithin rithin 4.0K May 12 02:31 local
```
* Provider IDs use a namespace/type pattern such as `hashicorp/azurerm`. The provider type (for example `azurerm`, `aws`, `local`) is what you reference when declaring resources (e.g., `azurerm_virtual_network`, `aws_s3_bucket`).
Provider versioning and lock files
* Providers are versioned. By default, Terraform will choose the latest compatible version; however, pinning or constraining provider versions is best practice for stability.
* terraform init creates a `terraform.lock.hcl` that records the exact provider download selections. When this file exists in the project, subsequent `terraform init` runs will prefer those locked versions and reuse already-installed binaries.
Example init output when reusing locked provider versions:
```bash theme={null}
$ terraform init
Initializing the backend...
Initializing provider plugins...
- Reusing previous version of hashicorp/azurerm from the dependency lock file
- Reusing previous version of hashicorp/aws from the dependency lock file
- Reusing previous version of hashicorp/local from the dependency lock file
- Using previously-installed hashicorp/azurerm v4.28.0
- Using previously-installed hashicorp/aws v5.97.0
- Using previously-installed hashicorp/local v2.5.2
Terraform has been successfully initialized!
```
Include `terraform.lock.hcl` in version control. The lock file ensures everyone (local developers and CI) uses the exact same provider versions for reproducible, deterministic runs.
When to re-run terraform init
* Run `terraform init` any time you change provider configuration, add a new provider, or modify provider version constraints.
* CI pipelines should run `terraform init` at the start of each job so the correct backend and provider plugins are installed.
Exploring providers on the Terraform Registry
* The Terraform Registry is the authoritative place to browse providers, view version history, filter by tier (official, verified, community), and inspect usage examples and source links.
You can filter providers by tier and category on the Registry. Official providers (HashiCorp) include AWS, Azure, and Google Cloud; partner/verified providers are vendor-maintained and validated; community providers are contributed by independent maintainers.
Provider pages include version history, release notes, download stats, and usage instructions. For example, the azurerm provider page shows recent releases and how to pin your configuration:
Pinning a provider source and version
To ensure Terraform pulls the provider from the intended source and respects a version constraint, add a `terraform` block with `required_providers` and then configure the provider. Example:
```hcl theme={null}
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "4.58.0"
}
}
}
provider "azurerm" {
# Configuration options
}
```
This pattern guarantees your team and CI use the same provider source and version. In the next lesson we'll cover version constraints and provider upgrade strategies in more depth.
Links and references
* Terraform Registry — [https://registry.terraform.io/](https://registry.terraform.io/)
* Terraform CLI documentation — [https://www.terraform.io/docs/cli/index.html](https://www.terraform.io/docs/cli/index.html)
* Managing providers and modules — [https://www.terraform.io/docs/language/providers/index.html](https://www.terraform.io/docs/language/providers/index.html)