Terraform Providers: Complete Starter Guide

Using Terraform providers is essential to interact with any external platform when managing infrastructure as code. Whether you’re launching resources on AWS, provisioning services on Azure, or creating a local file, Terraform providers are what make that possible.

This guide explains how providers work, where they come from, and how to use them properly in your Terraform configuration. If you’re new to Terraform or need clarity on how plugins and providers operate, this post walks you through everything you need to know.

What Are Terraform Providers?

Terraform providers are plugins that act as a bridge between your configuration files and the infrastructure platforms you manage. Every resource block in Terraform is tied to a specific provider.

For example:

  • To create an EC2 instance, you use the AWS provider.
  • To spin up a virtual machine in Azure, you use the AzureRM provider.
  • To manage local files, the local provider is used.

Using Terraform providers ensures that Terraform can translate your declared configurations into actual API calls to your chosen service.

Types of Terraform Providers

Terraform categorizes providers into three main types:

Official Providers

These are built and maintained by HashiCorp. Examples include:

  • aws
  • azurerm
  • google
  • local

Official providers are regularly updated, tested, and have strong documentation.

Partner Providers

Developed by third-party vendors in collaboration with HashiCorp. These undergo a partner review process. Examples include:

  • heroku
  • digitalocean
  • bigip (by F5)

Community Providers

Created by individual contributors from the open-source community. These are often used for niche platforms or experimental features. Quality and update frequency can vary.

Installing Providers with terraform init

After writing a configuration file, the next step is to initialize the working directory. This is done using the terraform init command.

terraform init

Terraform scans the configuration files for used providers, then downloads the required plugins from the Terraform Registry.

By default, plugins are downloaded into:

.terraform/plugins/

You’ll see an output message like:

- Installing hashicorp/local v2.0.0...

This shows the provider name and version, ensuring you’re using the correct plugin. You can safely run terraform init multiple times; it won’t affect any deployed infrastructure.

Provider Source Address Explained

The source address helps Terraform locate where to fetch the provider plugin. The format is:

[hostname/]namespace/provider

Example:

source = "hashicorp/local"

Here’s what it means:

  • hashicorp: The organization or namespace that owns the plugin
  • local: The name of the provider
  • Hostname (optional): Defaults to registry.terraform.io if omitted

So, hashicorp/local and registry.terraform.io/hashicorp/local both point to the same provider.

This format is especially useful when using private registries or custom providers hosted on platforms like GitHub or internal servers.

How to Lock Provider Versions

While using Terraform providers, it’s best practice to specify a version range. This avoids sudden breaking changes if a new version introduces updates incompatible with your code.

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

This locks your configuration to version 2.0.0 of the local provider. You can also specify version ranges:

version = ">= 2.0.0, < 3.0.0"

Locking versions makes your deployments predictable and prevents errors caused by untested provider updates.

Where to Find Providers and Documentation

All official and community-supported Terraform providers are available at the Terraform Registry. For each provider, you’ll find:

  • Resource types it supports
  • Data sources
  • Arguments and attributes for each resource
  • Version history

This registry is your go-to source when learning or troubleshooting using Terraform providers.

Example: Using the Local Provider

Here’s a simple configuration using the local provider:

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

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

Running the following commands will initialize and create the file:

terraform init
terraform apply

This example demonstrates how using Terraform providers simplifies the task of working with different platforms without complex scripting.

Conclusion

Understanding and using Terraform providers effectively is vital for writing clean, scalable infrastructure code. Providers allow Terraform to work with any cloud or on-prem service through plugins, giving you incredible flexibility.

By learning how to manage source addresses, lock provider versions, and install them correctly, you ensure that your infrastructure remains stable, secure, and easy to maintain.

As you build more complex systems, using multiple providers together will become second nature—and Terraform makes this seamless.

FAQ — Terraform Providers

Q1: Can I use multiple providers in one configuration?

Yes. You can use different providers by declaring them individually in your configuration files.

Q2: Where are provider plugins stored?

Terraform stores downloaded plugins in a hidden .terraform/plugins folder in your working directory.

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

Not always, but it’s strongly recommended to avoid unexpected issues due to automatic updates.

Q4: How do I update a provider version?

Update the version in your configuration and re-run terraform init. Terraform will fetch the new version.

Q5: What if my provider is not in the registry?

You can develop and use a custom provider by hosting it in a private registry or using a direct source path.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top