Infrahub doesn’t ship with a fixed data model. The schema is yours to define—devices, services, addressing, and whatever else your infrastructure depends on, modeled the way your organization actually works. It’s the most distinctive part of Infrahub, and until now it was also the hardest part to see: the example schemas lived in a GitHub repository of YAML files, and the only way to explore them was to read the raw files.
The Infrahub Marketplace puts them on display. It’s a public catalog of curated, battle-tested schemas and schema collections—a place to see how Infrahub models infrastructure, and to take a working schema with you.
We also used the Marketplace as an experiment—the first product we built end-to-end with AI-driven development, from the first spec to the CI pipeline that still tests the catalog today. Here’s what shipped, and how we built it.
Schemas and collections
The Marketplace contains two types of content. Schemas are versioned YAML files that each model a single domain—devices and interfaces, IP addressing, BGP, QoS, cabling, InfiniBand. Collections are sets of schemas verified to load together, gathered around a common use case: the Security Management collection, for example, bundles security policies, firewall policers, QoS, SNMP, and device user accounts.
Every schema is reviewed by OpsMill before it’s published, and a scheduled job confirms against a real Infrahub instance that every collection still installs cleanly. If it’s in the catalog, it loads.
What it’s for
See how Infrahub models infrastructure—without installing anything. Every schema can be previewed in the browser: what it models, its versions, its dependencies. Browsing working examples is the fastest way to understand how to design your own.
Start a new implementation from a working model. Load the collection closest to your use case into a fresh instance and you have a working data model before you write any YAML.
Find the next domain for the model you already run. If you came to Infrahub to model switches and routers, the catalog shows you what else you can bring into your source of truth—MLAG, BGP peering policies, QoS—and you add it through the normal branch-and-merge workflow.
Build schemas with AI, following Infrahub best practices. The Infrahub schema skill guides an AI assistant through schema design the way we would build it—and it draws on the Marketplace, working from a published schema as its reference design instead of generating a model from nothing.
From the Marketplace to your implementation
Browse the Marketplace, then copy or download a schema or collection into your own repository—or use the Infrahub SDK to load it straight into your Infrahub implementation.
If a schema depends on others, the Marketplace includes those too. From there you can modify anything: add attributes, define new relationships between objects, or extend existing kinds to match your environment.
How we built it
The Marketplace was a new, self-contained product with no legacy code behind it—exactly the right shape for something we’d wanted to try for a while: building a production application end-to-end with AI-driven development. Here’s how we did it.
1. We created a proof of concept
We had a rough idea: a browsable catalog of schemas. So that’s what we wrote down first, as a spec, before any code existed.
Even at proof-of-concept stage, the work went through spec-driven development with Spec Kit. When what came back wasn’t right, the fix was usually upstream—the spec was vague, or the plan had made an assumption we didn’t agree with. We iterated there rather than re-prompting the same request over and over.
It also helped that the Marketplace lived on a brand new site with no traffic on it yet. We could push something broken at 4pm and fix it at 4:30pm without anyone noticing.
That got us a working catalog fast, and it got us something more useful than the code: a concrete idea of what the product actually needed to be.
2. The workflow is a pipeline, not a prompt
Every feature moves through the same stages. Harden the idea. Write the spec. Plan it. Break the plan into tasks. Check the plan for contradictions against the specs already published. Then implement. Bugs run their own track — analyze, fix, test, review — each stage handing structured notes to the next, so the agent writing the fix has the analysis in front of it and the agent writing the tests has both.
Above all of it sits a constitution: five principles the planning stage checks every feature against. Simplicity first. Contract-first development. Test coverage required. Marketplace integrity. Accessible user experience.
The first one does the most work, because a model’s instinct is to build the abstraction you might need in a year:
Build only what is needed now. No code for hypothetical future requirements. Extract a shared abstraction only when the same logic appears in three or more distinct places.
Here’s the part that surprised us: the per-feature specs aren’t in version control. They did their job and we let them go. The constitution stayed. Specs are scaffolding; the rules you keep are the asset.
3. We polished the UI with a human
Once the Marketplace worked, we handed it to our UX/UI designer. What we had was a correct, tested, functional application that was unpleasant to use. Search didn’t feel obvious. The detail pages carried all the data but none of the hierarchy. The install flow worked but didn’t guide you. None of that shows up in a test suite, and none of it was going to fix itself.
The interesting part is that our designer fixed it the same way we’d built it—with AI. They reskinned the site, restructured the schema detail page, and turned the install path into something you can follow without reading the docs: a clear description, a preview, who published it and when, and one command to copy.
So the lesson isn’t that AI ran out of road at the UI. It’s that AI needed someone who already knew what good looked like. A model will execute a design decision cleanly and it will not make that decision for you—it has no opinion about whether a schema’s dependencies belong above the fold. Our designer brought the judgment and used the tools to move faster on it than they could have by hand.
4. We let CI be the reviewer that never gets tired
Humans reviewed every pull request. But you can’t ask a human to check, for the fiftieth time, whether the formatting is right or whether someone used the wrong database session type.
So the cheap checks are automated and unskippable. Pre-commit hooks run ruff, formatting, markdown and YAML lint, ESLint, Prettier and a TypeScript typecheck. CI adds backend unit tests, frontend unit tests and a Playwright end-to-end pass over the real UI.
Periodically we have a scheduled job that spins up a real Infrahub instance in a container and runs infrahubctl schema check against every collection published in the Marketplace. If a schema stops installing into a current Infrahub, we find out the next morning instead of hearing about it from our community. That last one matters more than any of the code. The interesting question about AI-written software was never “is it good code.” It’s “how do you know it still works.” We answered it by testing the product against the product.
5. Then we put it in front of a few hundred strangers
We first trialed the public Marketplace at AutoCon 5. Attendees used it in our “Intro to Infrahub” workshop to pull schemas into their labs, and it held up. The feedback we’ve had since, from the community and from customers, keeps landing on the same two things. Teams want to see what their peers are actually modeling. And they want to start from a schema that already works rather than a blank file.
Where the Marketplace goes from here
That feedback shapes where we take the Marketplace next. We’ll keep developing it with the same goals it launched with: helping teams understand Infrahub schemas, implement and improve their own schema designs, and—most importantly—use AI to develop and manage their schemas with Infrahub best practices built in.
Explore the Marketplace at marketplace.infrahub.app, or read more in the documentation.
