Find your module.
See the proof.
Terraform, OpenTofu and Ansible modules with transparent test evidence. Know what was checked before you deploy.
Check a source for free. No account needed.Example verification receipt
Succeeded41 checks passed1 advisory
Security, compliance and best practices
- Scan
- Apply
- Verify
- Destroy
What are you building?
Search the catalog for infrastructure modules with clear, verifiable evidence.
ansible-rsyslog-forward
rsyslog ships logs in clear over port 514, which is what most examples do. This role configures the sending side with the gtls driver, the collector's CA and x509/name, so a host with a certificate from elsewhere in the estate cannot collect your logs. The live test watches a line arrive and reads the handshake. Original role, live-tested on Rocky Linux 10.
ansible-ssh-ca
sshd can trust a CA and accept any certificate it signed, so access is granted by signing rather than by editing authorized_keys everywhere. The live test proves it four ways over a real connection: the matching certificate gets in, one for another principal does not, one that expired does not, and a key the CA never signed does not. Original role, live-tested on Rocky Linux 10.
gcp-filestore
A managed Cloud Filestore NFS share for GKE and Compute Engine, VPC-peered with no public exposure, optional per-client export rules for least-privilege access, and deletion protection on.
One toolkit.
Your way of working.
Inspect your estate, review plans, and run verified modules from your machine.
Explore Vizier Local Vizier CentralBring projects, environments, change reviews, and team access together.
Explore Vizier CentralScan / Apply / Check / Destroy
What one run does
Every stage happens in an account of ours. Nothing here asks for your cloud credentials, and nothing runs on your laptop.
Read the code
A security scan over the source, before anything is initialised. Code that opens a port to the internet or carries a committed credential never reaches a cloud account at all.
Apply it for real
In an isolated sandbox account that is ours, not yours. No cloud credential of yours is used or requested, and nothing runs on your machine.
Check it
Your own assertions run against the live infrastructure, not against a plan file. A plan says what should happen; this is what did.
Tear it down
Always, on every path out, including a failure. A run that applied and did not tear down is an incident, and it is reported as one rather than quietly counted as a pass.
No rubber stamp
What we refuse to certify
Anyone can return a tick. The value is entirely in what a verification declines to say, so these are written down, and each one is a rule in the code that decides a verdict.
A run that applied nothing does not pass
Applied 0, destroyed 0, every command exited zero. That is an empty pipeline reporting success, and it is the single result most worth catching, because it is what a broken submission looks like.
A scanner that did not run is not a clean scan
"No findings" and "nothing looked" both produce a zero. They are opposite facts, they are recorded separately, and only one of them can be certified.
A teardown nobody measured is a leak
If the resource count could not be read after the destroy, the receipt says unknown. It does not print a zero, because a number nobody measured is not a number.
A leak is never filed as a failure
A failed pipeline waits until morning. Resources nobody knows about are billing now, so a leak carries its own state, its own exit code, and instructions for finding what was left behind.
From the repository you are already in
One command, or one API call
Vizier is our CLI, free to download. certify submits the commit you are on and waits for the receipt. It refuses a dirty working tree, because we fetch the commit and a receipt built from an uncommitted edit would describe code that is not the code in front of you.
A leak gets its own exit code, separate from a failed verification, so a pipeline can page for one and stay quiet about the other.
$ vizier certify --wait
run r1787651111-4bb0 queued
source git::https://github.com/acme/platform.git
ref a3f19c8e2b7d4501f6c9ab8e0d2f4713c5a6b890
running
run r1787651111-4bb0 SUCCEEDED
security 41 passed, 1 advisory (checkov 3.2.334)
pipeline 5 of 5 stages
resources 12 applied, 12 destroyedWe run this on ourselves first
901 modules, put through the same pipeline
The catalog is not a side business, it is the evidence. Every module here went through the checks we sell, 341 of them through a real apply and teardown against a live cloud account. Each listing shows exactly which rung it earned, including the ones that have not earned the top one.
They are also what our attestation service consults when you ask whether a module you already depend on has ever been verified.
- modules published
- 901modules published
- applied and destroyed for real
- 341applied and destroyed for real
- cloud platforms
- 19cloud platforms
- clouds covered
- 19clouds covered
From the blog
Read more →2026-09-18
Why IaC Bazaar's Verified Catalog Beats Hunting for Modules in the Open Market
Hunting for production-ready Terraform modules across 24,000+ unvetted options costs more than most teams realize. Here is why IaC Bazaar's verified catalog changes that calculus entirely.
2026-09-13
How IaC Bazaar Cuts Through the Fragmented Infrastructure-as-Code Market
The IaC ecosystem is growing fast and fracturing faster. See how IaC Bazaar's verified modules and Vizier orchestration give infrastructure teams a trusted, production-ready path through the noise.
2026-09-11
Why Vizier Changes How Teams Orchestrate Infrastructure as Code
Most teams treat Terragrunt as both a provisioning helper and an orchestration layer. In 2026, that architectural conflation is costing them. Here is what a verified-catalog-backed orchestrator actually changes.
Find out what your code really does
Verification runs are in early access while we finish the sandbox. Tell us what you would point it at and we will get in touch when it opens.