The Terraform Registry: A Founder's Guide (2026)

The App Store I Opened for Infrastructure I Didn’t Own

Late 2024. Same wreckage I keep confessing to on this site. I’d over-engineered a URL shortener nobody used into a pile of hand-clicked AWS resources, and I was trying to bring the disaster under control with Terraform. (The whole “how do I get existing infra into code” nightmare is in the Terraform import post — go there for the state-file stuff. This one’s about where the building blocks come from.)

I ran terraform init and watched it download things I didn’t remember asking for. Providers. Modules. A blur of hashes and version numbers. Where were these coming from? What even was this stuff?

So I opened registry.terraform.io.

I expected a boring docs page. Buggy. Ugly. Enterprise-coded. Instead I got something that looked like an app store. A search bar. Thousands of providers. Pre-built modules for “a production VPC,” “an RDS database,” “a whole Kubernetes cluster.” Blue verification badges. Download counts. Version histories. My engineer brain lit up the way it always does right before I lose a weekend: someone already built all of this, and I can just… install it?

Yes. That’s the Terraform Registry. And it is genuinely one of the better package ecosystems in infrastructure tooling. It’s also, for most solo founders reading this, a beautifully stocked furniture store for a house you haven’t bought yet. So let me teach it honestly — what’s in it, how you’d use it if you’re actually there — and then, like I did with Ansible Galaxy, talk most of you out of needing it at all.

---

Wait, What Even Is a Registry?

I’m going to define this once, because the word “registry” does a lot of sneaky work and nobody explains it when you’re new.

Terraform, from HashiCorp (now IBM, we’ll get to that), describes infrastructure as code. You write what you want in files, Terraform makes the cloud match. But the core binary is tiny. It knows nothing about AWS or Cloudflare or any real platform out of the box. It needs plugins to talk to the outside world, and it needs somewhere to download them from.

The Registry is that place. It’s the public, HashiCorp-hosted hub where every provider, plus a mountain of pre-written reusable config, lives.

If you’ve written JavaScript or Python: it’s npm for Terraform. A central catalog of stuff you pull in, with versions and docs and download counts. Same shape as Ansible Galaxy in the configuration-management world — a package registry, just for cloud resources instead of server setup.

There are two kinds of thing inside, and beginners smash them together constantly. Get this distinction and you can read any module on the Registry without your eyes glazing over.

---

Providers vs Modules: Please Get This Right

The first two weeks I used Terraform, I called everything a “plugin.” Provider? Plugin. Module? Plugin. It’s a natural impulse when you don’t know the vocabulary, but it’s wrong, and the distinction actually matters.

A provider is the thing that teaches Terraform how to talk to one specific platform.

The AWS provider knows how to create an S3 bucket. The Cloudflare provider knows how to make a DNS record. The Datadog provider knows how to create a monitor. Every Terraform config needs at least one provider, because a provider is what actually does something against a real API. Without one, Terraform is a fancy text parser with no friends.

The part I genuinely like: you almost never install a provider by hand. You declare it in your config, run terraform init, and Terraform figures out which providers you referenced and downloads them automatically. That silent download you saw on your first init? That’s the Registry doing its main job. There are over 4,000 providers now — big clouds, random databases, SaaS tools you’d never expect to manage as code.

A module is a reusable bundle of config someone already wrote so you don’t have to.

If a provider is one raw building block (one bucket, one server), a module is a pre-assembled room. “A production-grade VPC with public and private subnets, route tables, NAT gateways, and all the wiring between them” — packaged, parameterized, ready to call. You point at it, pass a few inputs, get a whole slab of infrastructure. The famous one is terraform-aws-modules/vpc/aws, pulled an absurd number of times because nobody sane wants to hand-write a VPC.

That’s it. That’s the whole vocabulary. Provider = the plugin that does stuff on a platform. Module = a reusable recipe built from those plugins. The Registry hosts both. Everything else is detail — but it’s detail that’ll bite you if you skip it.

---

Actually Using a Public Module (Without Getting Burned)

Say you genuinely have an AWS account and you need a VPC — the networking foundation nearly everything on AWS sits inside. You could hand-write maybe 200 lines of HCL describing subnets and gateways and route tables, cross-referencing three AWS docs tabs and a StackOverflow thread from 2021.

Or you pull the community module in about eight lines:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.13.0"

  name = "my-app-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]
}

That source string is the Registry address — always namespace/name/provider. Run terraform init, Terraform fetches the module alongside the AWS provider it depends on. One terraform apply later, you have a correctly wired VPC. That’s maybe an afternoon of work you just bought back for free.

Two things that are the difference between “clean deploy” and “3 AM Slack message from yourself”:

Pin your damn version. The Registry moves. Modules get new releases. An unpinned module can silently change between runs and break a config you haven’t touched in months. I watched someone’s staging environment implode because a minor module bump changed a default from false to true. Pin it. Bump it deliberately.

Read the module before you run it. A public module is someone else’s opinions about your infrastructure, frozen in HCL. Most of the popular ones are excellent. But you’re pulling real config into your real cloud — skim what it creates. I once found a “production VPC” module that hard-coded an open security group rule. Not malicious, just sloppy. Five minutes of reading saved me a very stupid incident.

This is the genuinely great part of the Registry. On a real project with real users, pulling a battle-tested VPC module instead of reinventing it is pure leverage.

---

Who Built This Thing (and Should You Trust Them)

Anyone can publish. That’s the price of an open registry. So HashiCorp stamped every provider with a tier so you know where it came from. Three buckets, and the distinction is trust, not quality:

Official — built and maintained by HashiCorp. The heavy hitters: AWS, Azure, Google Cloud, Kubernetes. As safe as it gets.

Partner — maintained by the actual company behind the product. Datadog, Cloudflare, and friends. They went through HashiCorp’s onboarding and are nominally on the hook for supporting it. Nearly as trustworthy as Official. It means the vendor actually cares enough to publish.

Community — everything else. This is the biggest bucket, and some genuinely great stuff lives here. That VPC module everyone uses? Community-maintained. But there’s no promise anyone’s watching it. It could be abandoned, half-baked, or last touched during the Trump administration.

Modules get a similar signal: partner-published ones get a Verified badge (the blue checkmark). Community modules don’t.

Here’s what I actually do: I treat the tier as a starting filter for deciding who to trust, then I still read the code. The badge tells you who the author is. It doesn’t do your due diligence for you. A Verified badge means “a known org published this,” not “this is bug-free and safe for your prod.” I’ve found abandoned Partner modules and pristine Community ones. The badge is a signal, not a guarantee.

---

The OpenTofu Registry: The Fork Nobody Asked For (But Got Anyway)

You can’t talk about Terraform in 2026 without the license mess, and it touches the Registry directly.

August 2023. HashiCorp relicensed Terraform from the open-source MPL to the Business Source License — source-available, restricted, not OSI-approved open source. The community lost its mind. A fork called OpenTofu spun up almost immediately, kept the MPL, joined the Linux Foundation, became a CNCF project. Then IBM closed its $6.4 billion acquisition of HashiCorp in February 2025. Terraform is now an IBM product. The license didn’t revert. (The full fork history, and what it actually means for your day-to-day, is in the Terraform import post.)

Here’s the Registry-specific twist: OpenTofu built its own registry. It lives at registry.opentofu.org (browsable at search.opentofu.org), also carries 4,000-plus providers, and it’s architecturally different in a way I genuinely respect.

Instead of a big hosted service, the OpenTofu Registry pre-generates all its metadata into static files and serves them from a Cloudflare R2 bucket. No servers. No runtime. A pile of JSON behind a CDN. It’s cheap, it’s boring, it can’t fall over. Community-governed under the Linux Foundation. Recent OpenTofu versions even let you run your own origin registry and distribute providers through standard OCI container registries — which is the kind of “nobody owns the pipes” thinking I like.

For a bootstrapper, the practical version: concepts are identical. Providers, modules, the source/version block all work the same. If genuinely open tooling matters to you, OpenTofu and its registry are the safer long-term bet. If you want the biggest ecosystem and don’t care about the BSL, HashiCorp’s registry is still fine. If HCL itself makes you want to throw your laptop, Pulumi lets you write infra in real programming languages — different rabbit hole, same “I should probably not be doing this at $0 MRR” energy.

---

You Probably Have Nothing to Put In This Registry Yet

Now the part nobody will tell you, because they want you browsing modules and feeling like a Real Infrastructure Engineer.

Most solo founders do not need Terraform. Which means they do not need its registry. At all. Not yet.

The Registry is a catalog of infrastructure building blocks. So the honest first question isn’t “which VPC module” — it’s “how much infrastructure am I actually running?”

If your stack is Vercel for the frontend, Railway or Fly.io for a backend, and Neon for Postgres — congratulations, the answer is close to zero. There’s no VPC to stand up. No fleet of instances. No tangle of IAM policies and load balancers. Those platforms are your infrastructure layer. They took everything a provider or module would manage and hid it behind a git push. Browsing the Registry from a Vercel-and-Neon app is window-shopping for furniture you have no room for.

The Registry earns its keep the moment you have real cloud sprawl. Dozens or hundreds of resources on AWS or Google Cloud. Multiple environments that must stay identical. A team reviewing infra changes in pull requests. That’s when pulling a hardened VPC module instead of hand-rolling it is actual leverage, not cosplay. It’s a good problem — it usually means real usage. Real revenue. It is not a $0 MRR problem.

I went spelunking through the Registry in that 2024 cleanup for the same broken reason I reached for Kubernetes and Ansible before it: I manufactured enough infrastructure to justify the enterprise tool, then went shopping for the enterprise catalog. Classic Broken Engineer move. The learning was real and I don’t regret it — I can read a module now and know exactly what it’ll create. But if I’d run that redirect service on Railway and Neon like a sane person, there’d have been nothing to provision, and the Registry would’ve stayed a browser tab I never opened.

So here’s the actual decision:

• Managing real cloud resources, on a team, scared of drift? Learn Terraform or OpenTofu. Pull vetted modules. Pin versions. Respect your state file. The Registry is one of the better ecosystems in the business.
• Solo founder with a Vercel deploy, a Neon database, and a dream? Close the tab. Build the product. Bookmark this post for the day the sprawl finds you.

The best infrastructure module is the one you never installed because Vercel and Railway already ran that layer. The Registry isn’t something you browse to feel legitimate. It’s what you graduate to when the magic boxes run out. I browsed it to feel legitimate. Don’t be like me.

---

This is the Broken Engineer Guide. I over-engineer everything, fail at selling anything, and dump the scars here so you can maybe skip a few. Go build something that doesn’t need a provider yet.