Software catalog and ownership
Every service. And who owns it.
Your services live in a wiki, a spreadsheet and three people’s heads. Cycloid’s catalog is one view over your real resources, built from the Blueprints you deploy with.
Software catalog with owners
Why teams bolt a portal on the side
A catalog you maintain by hand is out of date by lunch
Most teams already have an inventory. It’s just scattered, stale, and missing the one field you need when something breaks. The cost shows up in three places.
It lives in three places
A wiki here, a spreadsheet there, the rest in Slack and people’s memory. None of them agree, and none are current when you need them.
A separate portal needs feeding
Backstage hands you the catalog, then the assembly, the plugins and the upkeep. It’s only as fresh as the effort you keep pouring in.
Nobody knows who owns it
When a service pages at 2am, “who owns this?” shouldn’t take twenty minutes and three wrong answers. An inventory without owners is a phone book with no numbers.
Cycloid for your team
What one catalog means for each reader
One catalog for infra and
services, no second system
The problem
Standing up and maintaining a separate portal is a project sitting on top of your actual job.
With Cycloid
The catalog is a view of what you already deploy – configured through Blueprints, current by default, with nothing extra to run.
The outcome
One place for infrastructure and services, without a portal to babysit.
Find any service, owner,
doc and dependency
The problem
Finding who owns a service, where its docs are, or what it depends on means asking around and hoping.
With Cycloid
Search the catalog. Owner, docs, APIs and dependencies sit on the resource, and they stay current.
The outcome
Answers in seconds, not a Slack thread and a guess.
Ownership you can measure
and govern
The problem
You can’t govern what you can’t see, and “who owns this?” has no reliable answer across the estate.
With Cycloid
Ownership coverage is measured – orphans listed, a threshold alerting – and ownership carries real authority over actions and approvals.
The outcome
Governance you can point to, without a separate portal to fund.
How it works
A lens over your real resources, not a parallel system
01 · Deploy through a Blueprint
The Blueprint that provisions a resource also decides how it appears in the catalog. You configure one thing, not two.
02 · It appears on its own
The resource is in the catalog the moment it exists. Nothing to register twice, nothing to keep in sync.
03 · Register what runs elsewhere
Services and APIs you don’t deploy through Cycloid go in as catalog-only entries, so the picture covers your whole estate.
04 · Name the owners
Every resource has a stewarding team, plus named owners where it matters. Those names decide who runs which action and who approves it.
05 · Find it in seconds
Filter by team, type, environment or label. A developer finds a service and its owner without a Slack thread.
Every property shows where its value came from, inherited, set by a plugin or overridden here, the way DevTools shows which CSS rule won. Typed relationships feed the dependency graph, so you can follow a service to the database it needs. Backstage is a framework you build and run. This is the catalog as product, on the platform that already deploys your infrastructure.
A lens over your real resources, not a parallel system
The short version
The catalog, counted
90%
of organisations use an IDP (DORA, 2025)
90%
ownership coverage before we flag it
1
owner field required: code owner. Add the rest
0
double entry. Deploy it and it’s listed
Who owns checkout-api, and is it passing the scorecard?
Here’s what the catalog holds for checkout-api.
Service · checkout-api
Scorecard 4 of 5
Code owner
Team Payments
On-call team
payments-oncall
Failing rule
No runbook link set
Last deploy
Blueprint v4.2, 3 days ago
Working with your assistant
Who owns it, answered from the record
Does the assistant get its own permissions?
No. There’s no service account and no elevated assistant role. If you can’t deploy to production, neither can the assistant you’re talking to, in Cycloid’s own assistant or any compliant MCP host.
Ask who owns a service and the answer comes from the catalog, not a wiki page someone last edited in March. Your assistant reads the same ownership fields, scorecard results and relationships you see. A field nobody set comes back empty, not guessed.
It sees exactly what you see. Anything you have no relationship to is simply absent from the answer, never listed as withheld.
Frequently asked questions
Backstage is a framework you assemble, host and maintain. Cycloid gives you the catalog, ownership and scorecards as product. If you run Backstage today, the two can sit side by side while you compare.
No. What you deploy through Cycloid appears on its own, and anything else registers as a catalog-only entry, a Blueprint with no actions. The catalog covers your whole estate, not just the parts Cycloid built.
A stewarding team for access, plus ownership fields for code, security, privacy, SRE and your own. A dashboard shows coverage, lists the orphans and alerts when coverage drops below 90% by default.
Yes. Typed relationships connect resources, so you can follow a service to what it depends on and back. The dependency graph page covers how edges are detected and what blast radius shows.
See your own estate in one catalog
Bring the service you can never find the owner for. In twenty minutes we’ll show it in the catalog – owner, docs, dependencies – and how ownership coverage looks across the rest.