Dependency graph
Know the blast radius. Before you touch it.
Every outage story starts with a change to something another thing depended on. Cycloid builds the graph from what your infrastructure already declares, so you see the impact before the action runs.
Resource relationships
Where the edges come from
Nobody maintains this by hand
A dependency map someone has to update is out of date within a sprint, which is why nobody trusts the one in the wiki. Cycloid builds its graph from what’s already there. Your infrastructure code, your cloud accounts, your Blueprints.
Detected
Read from Terraform, cloud metadata, Kubernetes, tags and cross-account references. Rebuilt on every sync, so you see today’s topology, not March’s.
Declared
A Blueprint says what its resources depend on, so they arrive connected. Set a reference and the edge appears. Clear it and it goes.
Drawn
Engineers add what no detector can infer, like the nightly job that quietly needs a bucket. Drawn edges survive every sync, and you can only connect what you can already see.
Cycloid for your team
What a current graph changes for each reader
Stop owning a drawing
The problem
The architecture diagram lives in a wiki, it was accurate the day it was made, and nobody has opened it since.
With Cycloid
The graph is materialised from declarations and references and refreshed on every sync. The only edges you maintain are the ones no detector could have inferred.
The outcome
A map people trust, because nothing about it is anyone’s side job.
Check before you change
a shared thing
The problem
You ask in a channel who depends on the thing you’re about to change, and hope the person who knows is online.
With Cycloid
The relationships tab on your resource shows one hop by default and expands as far as you want, with the cloud assets it manages grouped underneath.
The outcome
You answer the question yourself, in the tab next to the action.
Change risk assessed
the same way twice
The problem
Risk is judged by whoever happens to be in the room, and the assessment is as good as their memory of the estate.
With Cycloid
The blast radius an engineer sees at execution is the one behind the approval decision, and it covers shared Terraform state as well as declared dependencies.
The outcome
Two people assessing one change see the same picture.
How it works
From your estate to a blast radius
01 · Detect from five sources
Terraform references give you the spine. Cloud metadata, Kubernetes and your tags fill in what the code never said.
02 · Follow references across accounts
Where both accounts are connected, a cross-account reference becomes a link. Where only one is, it’s labelled unresolved.
03 · Join the two layers
Cloud assets and catalog resources share one vocabulary, so depends_on means one thing everywhere.
04 · Check the blast radius
Before a day-2 update or a destroy, the graph shows what’s downstream, including assets in the same Terraform state.
05 · Look the other way
The reverse view shows what depends on this. Ask it before you deprecate something, not only before you change it.
Everything renders under your permissions. A resource you can’t see shows as a placeholder, with a type icon and no name. You learn a dependency exists in another team’s estate, which is what a change decision needs, without learning what it is.
From your estate to a blast radius
The short version
The graph at a glance
5
places edges come from. No questionnaires
8
built-in relationship types, plus your own
2
layers, cloud and catalog, joined up
1
meaning for depends_on, everywhere
Resize the payments database.
That’s a change, so here’s what it can reach first. This includes assets in the same Terraform state, not only the declared edges.
Confirm · resize payments-db
Blast radius shown
Co-managed
3 assets in the same state
State
Nothing changed yet
Runs as you, no assistant role.
Working with your assistant
"What breaks if I change this", asked in one line
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 what depends on the payments database and your assistant walks the graph as you, and says how far out it went. It’s the question you’d normally ask a colleague, answered from the record.
Before a consequential action, the blast radius comes back in the confirmation. Nothing runs until you acknowledge it.
Frequently asked questions
Yes. Every linked provider lands in one graph. Cross-account references resolve into links when both accounts are connected, and show as unresolved when only one is, so the gap stays visible.
Everything downstream, with the depth shown, plus assets sharing the same Terraform state. A plan and apply can move those with nothing declared, and that’s where most surprises come from.
Yes to both. Drawn edges survive the syncs that replace detected ones. Custom types work for the whole tenant or one Blueprint, and graph queries treat them exactly like depends_on.
Archive an asset and its edges hide with it, then come back on restore. Detected edges rebuild every sync, so dead connections disappear on their own. Drawn edges stay until someone removes them.
Bring one account and we'll draw it
Twenty minutes, one cloud account, and the graph it produces. Then pick the resource you’d be most nervous to change, and we’ll show you what the blast radius says about it.