Terraform Registry Cache
This example demonstrates the Terraform registry cache — transparent provider and
module caching behind a single flag — and eager multi-platform pre-seeding of
providers via atmos terraform cache mirror.
What's here
-
A tiny
random-petcomponent that requires several providers (hashicorp/random,null,local,tls), so real providers flow through the cache oninit/plan. -
The same component consumes a registry-sourced module (
cloudposse/label/null), so module-registry traffic flows through the cache too. -
atmos.yamlwith the cache enabled and targetplatformsdeclared:components:terraform:platforms:- linux_amd64- darwin_arm64- windows_amd64cache:enabled: true
Try it
# On macOS/Windows, trust the local cache proxy certificate once.atmos terraform cache trust# Plan the component. Providers and the registry module are fetched through the# ephemeral cache proxy and stored on disk. At the end you'll see a report like:# Registry cache: 12 MB downloaded and cached (5 objects)atmos terraform plan random-pet -s dev# Simulate a fresh checkout / CI runner so init re-installs from scratch. The# on-disk cache persists across runs even though the proxy is ephemeral, so this# second init is served entirely from the cache:# Registry cache: 12 MB saved (5 hits)rm -rf components/terraform/random-pet/.terraformatmos terraform plan random-pet -s dev# Inspect the cache.atmos terraform cache listatmos terraform cache stats
The report has two halves: saved is bandwidth served from the cache on hits, and
downloaded and cached is what the proxy fetched from upstream and added to the
cache on misses. A run that re-uses an existing .terraform (no install) contacts the
proxy for nothing and prints no report.
Module caching
On init, the cloudposse/label/null module is resolved through the proxy's module
registry mirror: its version listing and download resolution route through the
cache and are stored. After a run, atmos terraform cache stats / cache list show a
non-zero module count alongside the providers.
What gets cached depends on how the registry serves the module's content:
- Registry metadata (version listings, download resolution) is always cached, removing registry round-trips on subsequent runs.
- The module archive is cached when the registry resolves the download to a plain
HTTP(S) archive (e.g. a
.tar.gz/.zip). - Git-sourced modules — the common case for the public registry and mono-repos — pass through unchanged for now; full content caching for those arrives with the upcoming git mirror.
Unlike providers, modules are not pre-seeded by cache mirror (that wraps
terraform/tofu providers mirror, which is providers-only). Modules are cached
lazily through the proxy the first time init resolves them.
Pre-seed for multiple platforms
The proxy is lazy — it only caches the platform Terraform requests at run time
(your host's). For mixed CI/developer fleets, or to build an air-gapped bundle,
pre-seed the cache for every target platform with cache mirror, which wraps
terraform providers mirror into the same cache directory:
# Uses components.terraform.platforms from atmos.yamlatmos terraform cache mirror random-pet -s dev# Or override the platforms for a one-offatmos terraform cache mirror random-pet -s dev \--platform=linux_amd64 --platform=darwin_arm64atmos terraform cache list
The mirror writes the canonical filesystem_mirror layout the proxy already serves,
so the same cache directory works three ways: lazily (proxy), eagerly (mirror), and
offline (filesystem_mirror).