The scariest changes in infrastructure are almost never the big ones. They are the one-line edits to a shared resource: widening a rule on a security group, retagging a subnet, tightening an IAM role, or bumping a shared variable. The change looks trivial, and the plan shows one modified attribute. You apply it, and minutes later a database you never touched stops accepting connections because it lived behind that security group, and the services behind the database start failing. Nobody expected it, because nobody could see the full set of things that resource was holding up.
That is the gap between what a plan tells you and what a change does. A plan tells you what will change; it does not tell you what will break. Blast radius is the missing piece: the set of things a change or a failure can touch, made visible before you apply.
Why a plan diff alone does not tell you impact
A Terraform or OpenTofu plan is a diff. It compares desired state in code to recorded state and lists what will be created, updated, or destroyed. But a diff is scoped to the resources named in the change. It says nothing about the resources that depend on them, or the live consumers that were never written in your code at all.
Change an ingress rule on a shared security group and the plan shows one modified resource: the security group. It will not show you that a database sits behind that group, that several services route through it, or that another account references it across a peering connection. Impact lives in the relationships, which a diff does not carry.
What a blast radius is
A blast radius is the set of resources a change or a failure can reach, in two directions. Upstream are the providers a resource depends on: the network, identity, and shared configuration it needs to function. Downstream are the consumers that depend on it: the databases, services, and workloads that break if it changes or disappears.
So the blast radius of that shared security group is not one resource. It is the group plus the database that uses it, the services that reach the database, and anything upstream the group relies on. That full set is what is at risk, and seeing it turns a one-line edit from a guess into a known quantity.
Built from live state and code, kept drift-aware
A blast radius is only trustworthy if it reflects reality, and a diagram drawn by hand in a wiki is out of date the day after someone draws it. ops0 does not ask you to draw anything. It builds the resource graph from your Terraform, OpenTofu, or Oxid code and the live state of your cloud accounts at once: code supplies the intended relationships, and live state supplies what is deployed, including resources created by hand and never captured in any module. Because the graph is grounded in live state, it stays drift-aware: when something changes outside of code, the dependency it created or removed shows up in the graph, so the blast radius reflects the cloud as it is now, not as a plan file remembers it.
Variable impact tracing
Some of the widest blast radii come from a single variable. A shared value like a CIDR block, an environment name, or an instance size can be referenced across dozens of resources and several modules, so changing it in one place ripples everywhere it is used. ops0 traces variable impact directly: it shows every resource and module where that value flows, so you see the full reach of the edit before you make it.
Cross-account relationships that hide dependencies
The dependencies that cause the worst surprises are the ones that cross an account boundary: a security group referenced over a peering connection, a role assumed from another account, a shared bucket policy. These links are invisible if you look at one account at a time. Because ops0 reads live state across all connected accounts, it surfaces these relationships in the same graph, so a change that looks contained in one account shows its downstream consumers in another instead of hiding them until they fail.
Shown in the deploy plan, used to order safe imports
The blast radius is not a separate report you have to remember to open; it is attached to the deploy plan. When you review a change in ops0, the plan shows the diff and the blast radius together, so the resources that will change and the resources that depend on them are visible in one place at the moment you approve.
The same dependency information orders operations that have to respect relationships. When ops0 imports existing resources into management, it uses the graph to sequence imports so upstream providers come before their downstream consumers, instead of breaking references along the way.
From a risky change to a reviewed one
The point of a blast radius is not to stop changes. It is to make sure the person approving one sees the real scope, not the narrow slice a diff shows. When the reviewer can see that a security group edit reaches a production database and several services, the change becomes a decision made with the consequences in view.
A diff tells you what you are changing. A blast radius tells you what you are risking. Know the blast radius, not only the diff.
What is blast radius in infrastructure?
Blast radius is the set of resources a change or a failure can reach. It spans upstream, the providers a resource depends on, and downstream, the consumers that break if the resource changes or disappears. Knowing it tells you the real scope of a change rather than just the single resource you edited.
How is blast radius different from a Terraform plan?
A Terraform or OpenTofu plan is a diff scoped to the resources named in the change. It tells you what will be created, updated, or destroyed. A blast radius adds the resources that depend on those resources, including live consumers never written in your code, so you see what the change risks, not just what it edits.
How does ops0 compute the blast radius?
ops0 builds a resource graph from your Terraform, OpenTofu, or Oxid code and the live state of your cloud accounts at the same time. Code supplies intended relationships, live state supplies what is actually deployed, and the blast radius is derived by walking the dependencies upstream and downstream from the resources a change touches.
Does blast radius work across accounts?
Yes. Because ops0 reads live state across all connected accounts, it surfaces cross-account relationships such as peering references, assumed roles, and shared policies in the same graph. A change that looks contained in one account can have downstream consumers in another, and the blast radius shows them.
Can I see impact before deleting a resource?
Yes. Before a delete or an edit is applied, the deploy plan shows the blast radius alongside the diff, so you can see every downstream consumer that would be affected. That way a destructive change is reviewed with its consequences in view rather than discovered after the fact.
Is the blast radius based on live state or code?
Both. ops0 combines code and live cloud state so the graph reflects intended relationships and what is actually deployed, including resources created by hand outside of code. Because it is grounded in live state, the blast radius stays drift-aware and reflects the cloud as it is now.