Software catalogue and ownership
A software catalogue, with owners
Your services live in a wiki, a spreadsheet and three people’s heads. Cycloid’s catalogue is one view over your real resources, built from the Blueprints you deploy with.
Software catalogue with owners
Why teams bolt a portal on the side
A catalogue kept by hand is stale 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 catalogue, 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 catalogue changes for your team
One catalogue 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 catalogue 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 catalogue. 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
Deploy it, and it's in the catalogue
01 · Deploy through a Blueprint
The Blueprint that provisions a resource also decides how it appears in the catalogue. You configure one thing, not two.
02 · It appears on its own
The resource is in the catalogue 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 catalogue-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. Documentation lives on the same resource page, next to its owner, APIs and dependencies. 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 catalogue as product, on the platform that already deploys your infrastructure.
Deploy it, and it’s in the catalogue
The short version
The catalogue in numbers
90%
of organisations have adopted at least one platform (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 catalogue holds for checkout-api.
Service · checkout-api
Scorecard level: Silver
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
Ask your assistant who owns it
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 catalogue, 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
How is this different from Backstage?
Backstage is a framework you assemble, host and maintain. Cycloid gives you the catalogue, ownership and scorecards as product. If you run Backstage today, the two can sit side by side while you compare.
Do we have to deploy through Cycloid to use the catalogue?
No. What you deploy through Cycloid appears on its own, and anything else registers as a catalogue-only entry, a Blueprint with no actions. The catalogue covers your whole estate, not just the parts Cycloid built.
How is ownership tracked?
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.
Does it show dependencies?
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 services in one catalogue
Bring the service you can never find the owner for. In twenty minutes we’ll show it in the catalogue – owner, docs, dependencies – and how ownership coverage looks across the rest.