Using Terraform Providers: Complete Beginner Guide

Using Terraform providers is how Terraform communicates with cloud platforms, SaaS services, networking tools, and local systems. Terraform itself does not know how to create an EC2 instance, provision a Kubernetes cluster, or manage a DNS record. Providers make those actions possible.

Whether you're deploying infrastructure on AWS, Azure, or Google Cloud, or managing local resources, every Terraform configuration depends on one or more providers.

This guide explains how Terraform providers work, how Terraform downloads them, how to lock provider versions, where to find provider documentation, and the best practices used in production environments.

What Are Terraform Providers and Why Do They Matter?

Terraform providers are plugins that enable Terraform to interact with external APIs and services. Every resource and data source in Terraform belongs to a specific provider.

For example:

• The AWS provider manages AWS resources.
• The AzureRM provider manages Microsoft Azure resources.
• The Google provider manages Google Cloud resources.
• The Local provider manages files and local system resources.

When you run Terraform commands, Terraform uses the provider plugin to translate your configuration into API requests for the target platform.

Without providers, Terraform would have no way to create, update, or delete infrastructure.

If you're new to Terraform, start with this guide on Getting Started with Terraform and AWS before moving into provider-specific configurations.

Using Terraform Providers: How They Work

Every Terraform provider follows a simple workflow:

1. You declare a provider requirement in your configuration.
2. Terraform identifies the provider source.
3. Terraform downloads the provider plugin during initialization.
4. Terraform uses the provider to communicate with external APIs.
5. Resources and data sources become available for use in your configuration.

Think of providers as Terraform's integration layer. Similar to how package managers download libraries, Terraform downloads provider plugins that extend its capabilities.

Types of Terraform Providers

Terraform categorizes providers into three main groups.

Official Providers

Official providers are developed and maintained by HashiCorp or official technology vendors.

Common examples include:

• aws
• azurerm
• google
• kubernetes
• local

These providers receive regular updates, bug fixes, and security improvements.

In most production environments, teams primarily rely on official providers because they are actively maintained and thoroughly documented.

Partner Providers

Partner providers are created by technology vendors and participate in HashiCorp's provider partner program.

Examples include:

• digitalocean
• heroku
• bigip

These providers are maintained by their respective organizations and integrate with the Terraform ecosystem.

Community Providers

Community providers are built by open-source contributors.

They often support niche platforms, internal tools, or emerging technologies. Since maintenance quality can vary, review documentation, release activity, and issue history before adopting them in production.

How Terraform Downloads and Installs Providers

After creating your Terraform configuration, initialize the working directory using:

terraform init

Before running the command, ensure Terraform is installed correctly by following this guide on Installing Terraform.

During initialization, Terraform:

• Identifies required providers
• Downloads provider plugins
• Creates a lock file
• Prepares the working directory

You may see output similar to:

Initializing provider plugins...

- Finding hashicorp/local versions matching "2.5.3"...
- Installing hashicorp/local v2.5.3...
- Installed hashicorp/local v2.5.3

Terraform stores downloaded providers inside the .terraform directory within the working directory.

Running terraform init multiple times is safe and does not modify deployed infrastructure.

Understanding Terraform Provider Source Addresses

Terraform uses source addresses to locate and download provider plugins.

The format is:

[hostname/]namespace/provider

Example:

source = "hashicorp/local"

Breaking it down:

• hashicorp is the namespace or organization.
• local is the provider name.
• registry.terraform.io is the default hostname if none is specified.

The following source addresses are equivalent:

source = "hashicorp/local"

source = "registry.terraform.io/hashicorp/local"

Source addresses become especially important when working with private registries or internally developed providers.

For official details, see the Terraform Provider Requirements Documentation.

How to Configure Required Providers

Provider requirements are defined inside the terraform block.

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "2.5.3"
    }
  }
}

This configuration instructs Terraform to download version 2.5.3 of the Local provider from the HashiCorp namespace.

Defining provider requirements explicitly makes configurations easier to maintain and reproduce across environments.

How to Lock Provider Versions

Provider version locking helps prevent unexpected changes caused by automatic upgrades.

A basic example:

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "2.5.3"
    }
  }
}

You can also define version ranges:

version = ">= 2.5.0, < 3.0.0"

Many teams prefer using compatible version constraints to receive patch updates while avoiding major breaking changes.

For a deeper understanding of versioning strategies, read this guide on Terraform Version Constraints.

Pro Tip

In production environments, avoid upgrading provider versions directly in critical infrastructure projects without testing.

Validate changes in a development or staging environment first, then promote the update through your deployment pipeline.

Terraform Provider Lock File (.terraform.lock.hcl)

When you run terraform init, Terraform generates a lock file named:

.terraform.lock.hcl

This file records the exact provider versions selected during initialization.

Benefits of the lock file include:

• Consistent deployments across team members
• Predictable CI/CD pipeline behavior
• Protection against unintended provider upgrades
• Reproducible infrastructure builds

A common best practice is to commit .terraform.lock.hcl to version control.

Even when version ranges are specified, Terraform uses the lock file to ensure everyone uses the same provider versions.

Example: Using Multiple Providers

Real-world Terraform projects often use more than one provider.

For example:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }

    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.30"
    }
  }
}

This pattern is common when Terraform provisions AWS infrastructure while simultaneously managing Kubernetes resources.

To learn more, read our guide on using multiple Terraform providers.

Example Configuration Using the Local Provider

The following example creates a local file using the Local provider.

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "2.5.3"
    }
  }
}

resource "local_file" "sample" {
  filename = "/tmp/sample.txt"
  content  = "Hello, TechAlmirah!"
}

Initialize and apply the configuration:

terraform init
terraform apply

Terraform downloads the provider, creates the file, and records the resource in the Terraform state.

To understand how Terraform tracks resources after creation, see:

• Introduction to Terraform State
• Purpose of State in Terraform

Where to Find Providers and Documentation

The best place to discover providers is the official Terraform Registry.

For every provider, the registry includes:

• Installation instructions
• Resources
• Data sources
• Arguments and attributes
• Provider configuration examples
• Version history
• Release information

When troubleshooting provider behavior or learning new features, always start with the provider documentation published in the registry.

Best Practices for Using Terraform Providers

Follow these practices when working with providers:

• Always specify provider version constraints.
• Commit .terraform.lock.hcl to version control.
• Test provider upgrades before production deployment.
• Use official providers whenever possible.
• Read provider release notes before upgrading.
• Keep provider versions consistent across environments.
• Review provider documentation before implementing new resources.

These practices reduce deployment risk and improve infrastructure stability.

Conclusion

Every Terraform project relies on providers to communicate with external platforms and services.

Once you understand provider installation, source addresses, version constraints, and lock files, managing providers becomes straightforward. These fundamentals help create predictable, maintainable, and scalable infrastructure deployments.

As your Terraform knowledge grows, you'll naturally begin working with multiple providers, modules, remote state backends, and more advanced workflows.

FAQ — Terraform Providers

Q1: Can I use multiple providers in one Terraform configuration?

Yes. Terraform supports multiple providers in the same configuration. This is common when managing resources across different platforms or services.

Q2: Where are Terraform provider plugins stored?

Terraform stores downloaded provider binaries inside the .terraform directory within the working directory.

Q3: Do I always need to specify a provider version?

Terraform does not require it, but specifying provider versions is considered a best practice because it improves deployment consistency and reduces upgrade-related issues.

Q4: How do I update a provider version?

Update the version constraint in your configuration and run:

terraform init -upgrade

Terraform will download compatible provider versions based on the updated constraints.

Q5: What is the purpose of .terraform.lock.hcl?

The lock file records the exact provider versions selected during initialization, ensuring consistent deployments across developers, workstations, and CI/CD pipelines.

Q6: What if a provider is not available in the Terraform Registry?

Terraform supports private registries and custom provider distribution methods. Organizations can develop and distribute their own providers for internal use.