Terraform Multiple Providers Made Simple

Terraform multiple providers capability allows you to use more than one infrastructure or utility plugin in the same configuration. This becomes especially useful when your infrastructure relies on different cloud services or needs to generate values like random strings alongside resource provisioning.

In this post, you’ll learn how to set up and manage multiple providers in a single Terraform project. Whether you’re combining AWS with Azure or using local and random utilities, this guide will walk you through everything you need to know—step by step.

What Are Terraform Providers?

Before diving into Terraform multiple providers, it’s important to understand what a provider is.

A provider in Terraform is a plugin that lets you interact with an external platform—cloud services, APIs, utilities, or local resources. Providers enable Terraform to communicate with different tools and services through a consistent configuration format.

Examples of common providers include:

  • aws for Amazon Web Services
  • azurerm for Microsoft Azure
  • google for Google Cloud
  • local for managing local resources
  • random for generating random values like IDs, names, or passwords

Using multiple providers simply means declaring and using resources from more than one provider in a single configuration.

Why Use Multiple Providers in Terraform?

Managing Terraform multiple providers becomes essential when your infrastructure setup spans different services or functionalities.

Here are a few practical scenarios:

  • You want to provision infrastructure on AWS and also store logs on Google Cloud.
  • You need to generate random passwords for Azure VMs.
  • You’re creating local files while using cloud-based compute services.

Instead of maintaining separate configurations, you can streamline everything into one project and manage it in a unified way.

Declaring Multiple Providers

Let’s look at a simple example using two providers: local and random.

Step 1: Define Providers in main.tf

You don’t always have to declare providers explicitly, but when you want more control (like versioning), you can use:

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

Step 2: Add Resource Blocks

Here’s how to use both providers in one file:

resource "local_file" "pet" {
filename = "/tmp/pets.txt"
content = "We love pets"
}

resource "random_pet" "my_pet" {
prefix = "awesome"
separator = "-"
length = 2
}

The local_file block creates a file on your system. The random_pet block, from the random provider, generates a pet name like awesome-lion-tiger.

Initializing with Multiple Providers

When working with Terraform multiple providers, it’s essential to initialize your project with:

terraform init

Terraform reads your .tf files, identifies all used providers, and installs the necessary plugins from the Terraform Registry.

If a provider was already initialized previously (like local), it will be reused. New ones (like random) will be freshly installed.

You’ll see output like:

- Reusing previous version of hashicorp/local from the dependency lock file
- Installing hashicorp/random v3.4.3...

This process sets up your .terraform directory, preparing the environment for planning and applying changes.

Planning and Applying Resources

With multiple providers configured, run:

terraform plan

Terraform will show you an execution plan:

  • Resources that are new will be marked with a +
  • Resources that are unchanged will be skipped

For example:

+ random_pet.my_pet will be created
+ id = (known after apply)
+ length = 2
+ prefix = "awesome"
+ separator = "-"

Next, run:

terraform apply

Terraform will confirm the plan, wait for your approval, and then apply the changes. It will create the file and generate the random name in one go.

How Terraform Handles Multiple Providers

Behind the scenes, Terraform merges provider definitions into a unified context. You can:

  • Reference attributes between providers (e.g., output a random name into a local file)
  • Isolate resources logically but keep them in a single directory
  • Combine modules and pass providers as inputs for even greater flexibility

This design makes Terraform multiple providers a core feature for modern infrastructure as code practices.

Best Practices for Using Multiple Providers

  1. Use version constraints: Avoid unexpected updates by locking provider versions.
  2. Keep files organized: Use separate .tf files for complex setups (e.g., random.tf, local.tf).
  3. Test in stages: Run terraform plan frequently when introducing new providers.
  4. Consult documentation: Each provider has unique arguments and behaviors. Always refer to Terraform Registry.

Following these practices keeps your project clean, portable, and easier to debug.

Conclusion

Using Terraform multiple providers gives you the power to manage diverse infrastructure components in one place. Whether you’re generating a random string, creating cloud resources, or working with local files, combining providers enhances flexibility and reduces duplication.

With a solid grasp of how to declare, initialize, and apply resources across different providers, you’re now ready to build robust and scalable environments using Terraform’s plugin-based architecture.

FAQ — Terraform Multiple Providers

Q1: Can I use more than two providers?

Yes, Terraform supports as many providers as needed in a configuration.

Q2: Do I need to re-run terraform init when adding a new provider?

Yes. Adding a new provider requires reinitializing with terraform init to install the new plugin.

Q3: Can different resources share data across providers?

Yes. You can use outputs from one resource as inputs for another, even across providers.

Q4: What happens if two providers have the same resource type name?

Terraform distinguishes them using the provider block or namespace, avoiding conflicts.

Q5: Is it possible to define provider blocks separately for each resource?

Yes. You can use the provider argument inside a resource block to bind it to a specific provider instance.

Leave a Comment

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

Scroll to Top