Provider caching and mirrors in Terraform - Time & Space Complexity
When Terraform downloads providers, it can use caching and mirrors to speed things up.
We want to see how the number of downloads changes as we add more providers.
Analyze the time complexity of provider downloads with caching and mirrors.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.0"
}
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.0"
}
}
provider_installation {
filesystem_mirror {
path = "/terraform-providers"
include = ["hashicorp/*"]
}
direct {
exclude = ["hashicorp/*"]
}
}
}
This config sets up two providers and uses a local mirror to cache downloads.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Downloading provider binaries from remote sources.
- How many times: Once per unique provider version unless cached locally.
Each new provider version not in cache triggers a download.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 providers | Up to 10 downloads if none cached |
| 100 providers | Up to 100 downloads if none cached |
| 1000 providers | Up to 1000 downloads if none cached |
Pattern observation: Downloads grow linearly with the number of unique providers not cached.
Time Complexity: O(n)
This means the number of downloads grows directly with the number of unique providers needed.
[X] Wrong: "Once a provider is cached, Terraform never checks for updates again."
[OK] Correct: Terraform checks versions and may download updates if the required version changes or cache is cleared.
Understanding how caching affects download operations helps you design efficient infrastructure setups and troubleshoot slow Terraform runs.
"What if we added a shared network mirror for all team members? How would that affect the time complexity of provider downloads?"