Overmind reads your live AWS, GCP and Kubernetes state to tell you whether a Terraform apply is safe. Riftmap parses source to tell you which other repositories consume what you are changing. Both call it "blast radius". They are not the same radius.
The line that anchors Overmind's homepage is a good one. The Terraform plan shows what is in the plan, it says, but "the real impact lives in the running infrastructure". It is the kind of sentence I wish more infrastructure tools were honest enough to write. A terraform plan shows you the diff. It does not show you what that diff does once it lands in an account full of resources that depend on each other in ways the plan never spells out. Overmind built a real product on closing exactly that gap, and I have spent the last few days in their docs, their CLI, and their own writing about it, because when a tool reaches for the words your product is built on, the responsible thing is to understand it properly before you say anything about it.
Here is where I landed. "Terraform blast radius" is not one question. It is at least three, and they are answered by three different kinds of tool that are easy to mistake for one another. Overmind answers one of them, and answers it well. It is not the one a platform team in a 50-to-300-repo polyrepo org runs into most often, and it is not the one Riftmap is built for. The two tools barely overlap once the three questions are clear. So this post is mostly about drawing that line precisely, and being fair to Overmind while I do it. It is the same exercise I ran recently with GitLab Orbit, on a different axis.
What Overmind actually does
I want to be generous here, because Overmind earns it, and because what it is good at and what Riftmap is for sit on different axes.
Overmind plugs into the Terraform workflow at plan time. You run overmind terraform plan locally, or you wire overmind changes submit-plan into CI so it fires on every pull request. From there it does the thing most tools with "blast radius" in the name do not: it reaches into your running cloud. Using read-only access to your AWS, GCP or Kubernetes, it queries the live account through the provider APIs, builds a dependency map from the resources that actually exist, and works out which of them your plan could disturb. The depth is real, with over 120 AWS resource types and all of Kubernetes supported. Crucially, that map includes resources Terraform does not manage at all. Something created by hand in the console, or by CloudFormation, or by another tool entirely, still shows up, because the map comes from the cloud and not from your state file. On top of it Overmind posts a machine-generated list of risks straight into the PR, and overmind terraform apply lets it snapshot before and after a deploy so you can confirm nothing reacted in a way you did not expect. There is also an LLM-driven investigator, overmind explore, for poking at infrastructure interactively. And to its credit, the credentials never leave your environment; the CLI talks to the cloud, not the other way around.
The example Overmind leads with on its own site is the right kind of example, so I will describe it rather than invent a worse one. A change adds a memory limit to a Kubernetes deployment, and it looks safe, because the pods normally sit comfortably under the new ceiling. The limit only bites during a traffic spike, when the JVM heap expands for garbage collection, the pods cross the ceiling, get OOMKilled, and the failures cascade as the load balancer keeps routing traffic to pods that are themselves restarting. That is a genuinely hard thing to catch in review. It is invisible in the diff, invisible in the plan, and it depends on how the system behaves under load in production. This is Overmind's home turf, and on it Overmind is doing something neither a config visualiser nor a source parser can do. If the question in front of you is "is this apply safe against my live account", Overmind is a real answer.
So let me be precise about the shape of what Overmind sees. It reasons about cloud resources, in the account a plan targets, at the moment that plan exists, including drift and live runtime relationships. Hold that shape in mind, because the line falls exactly along its edges.
"Terraform blast radius" is three questions wearing one phrase
The reason two engineers can both say "we use a Terraform blast radius tool" and mean completely different things is that the phrase has quietly absorbed three separate questions. They live at different layers. They need different machinery. And most arguments about "the blast radius tool" are really two people standing at different layers talking past each other.
One: the resource graph inside a single config
Ask "what is the dependency graph of this Terraform configuration, and in what order will things change", and you want the in-config graph. This is the oldest sense of the term, and it is the one the open-source tool literally named Blast Radius built: parse the HCL in a working directory, render the resource DAG with Graphviz, let you see what depends on what before you apply. Inframap, Rover and Terraform Visual live here too. It is good for understanding and documenting one configuration, and it is bounded to one configuration. It tells you nothing about the running cloud and nothing about other repositories. It is the resource ordering inside the directory in front of you, and no more.
Two: the live-cloud graph at apply time
Ask "given this plan, what in my running infrastructure could be affected, and is that safe", and you want the live-cloud graph. This is Overmind. The graph is not derived from the config, it is discovered from the cloud, which is precisely why it can include unmanaged resources and runtime relationships the config never mentions. It is bounded to one account's live state, and to the moment a plan exists. Overmind itself drew the first half of this line years ago, when it argued that blast radius is more than another plan-visualisation tool, and it was right to. The live-cloud graph is a genuine step beyond the in-config graph.
Three: the cross-repo graph across the whole org
Ask "which other repositories across my organisation consume the thing I am about to change, and at which version", and you want the cross-repo artifact graph. This is Riftmap. Its nodes are the things repositories share: a Terraform module, a base image, a Helm chart, a reusable CI template. Its edges are the references that bind them across repos: a Terraform source block, a terraform_remote_state lookup, a Dockerfile FROM line, a Helm chart dependencies entry, a GitLab CI include:project. It is built by parsing source across every repository in a GitLab or GitHub org, and it is bounded by nothing except the org itself. It does not look at the cloud and it does not need a plan to exist. It answers the question before you make the change.
Overmind did a real service by separating question two from question one. The thing worth noticing is that question three is a different axis again, and nothing about answering question two gets you any closer to answering it.
Where the edge that bites actually lives
Picture the change that actually causes the bad afternoon. You take a shared Terraform module from v3 to v4 and rename a variable on the way. The module is fine. Your plan is fine. The thing that breaks is two repos away, in a service owned by a team that has never read your module's changelog, whose Terraform pins source = "git::https://gitlab.example.com/platform/modules.git//network?ref=v3" and will fail to plan the next time anyone touches it, or the moment Renovate bumps the ref for them.
Walk that through Overmind's machinery and you can see why it cannot be the tool that catches it. Overmind runs on a plan, in the repo where the plan exists. The plan that exists is yours, in the module repo or wherever you made the edit. The consuming repo has not planned anything. There is no live-cloud signal there yet, because nobody has applied the breaking change, and the failure you actually care about is the one that has not happened. Even if that team also runs Overmind, Overmind will not connect your module edit to their future plan, because it does not model the dependency that links them. That dependency was never a cloud resource. It was a ?ref=v3 in a manifest, in a repository Overmind had no reason to look at.
There is a fair caveat here, and I would rather state it than skate past it. Within a single shared account, Overmind queries the live cloud, so a plan in one repo can surface a resource that another repo also manages, because both touch the same account. In that narrow sense it can cross an ownership boundary at the resource level. But that is one account, at apply time, between resources that already exist. It is not the cross-repo source edge. It is not the consuming repos that have not applied anything yet. And it does not reach across accounts or across platforms. A module pinned at ?ref=v3 in a GitHub repo, while the module is published from a GitLab repo, is an edge no live-cloud tool can draw, because it does not exist in any cloud. It only ever existed in the manifest.
Then there is the entire artifact layer that has no cloud footprint at all. A shared Go module other services require. An internal npm package. A Python library half your repos import. A reusable GitLab CI template that thirty pipelines include. None of these is an AWS resource, so none of them is visible to a tool whose graph is built from cloud state. They are visible to a tool that parses the manifest edge, whether or not the artifact ever becomes a running resource. That is the difference between discovering the graph from the cloud and parsing it from the source. Parsed, not inferred. And parsed across everything, not only the things that happen to run in a cloud Overmind can read.
Two access models, two moments
The split shows up cleanly in two practical places, beyond the layer question itself.
The first is what each tool has to be trusted with. Overmind needs read-only access to your cloud, because that is where its graph comes from. The credentials stay in your environment, which is the right design, but the access still has to exist and be approved. Riftmap needs read-only access to your Git, one token, because that is where its graph comes from. These are different surfaces to reason about, and for a security-conscious or regulated team the question of which systems a tool touches is rarely an afterthought. Neither model is universally better. They are answers to different questions, and they go through different approvals.
The second is when each tool can answer. Overmind answers when a plan exists, which in practice means in CI, on a pull request, at apply time. Riftmap answers from a standing graph of the whole org that is already there before you write the change. You can ask it the moment you are considering a breaking change, before there is a branch, let alone a plan. An AI coding agent about to edit a shared module can ask it before it opens the pull request at all, which is the whole point of treating the graph as runtime infrastructure for agents. Apply time is a good moment to check whether a change is safe. It is a late moment to discover who you needed to warn.
It is worth being precise about determinism too, because it is easy to be unfair on this point. Overmind's dependency graph is not guessed, it is read from real cloud APIs, which is solid. The part that is a judgement rather than a guarantee is the risk list, which is generated automatically from patterns and analysis of the change and reads as advice. Riftmap's graph is parsed deterministically from manifests, and the consumer set it returns is an enumeration: these repositories reference this artifact at these versions, full stop, not a confidence score. Both tools are honest about which of their outputs is a fact and which is a judgement. They simply draw that line in different places, because they are doing different jobs. The deterministic case for parsing rather than inferring is something I have made at more length elsewhere, and it applies to the graph, not to Overmind's risk narrative, which was never trying to be deterministic.
They stack
I have come to think of Overmind less as a competitor than as the tool that owns the layer directly beneath the one Riftmap owns. The honest version of "when would I use each" is not a contest, it is a sequence.
You are about to bump a shared module. Riftmap answers the first question: which repositories consume it, who owns them, what versions they pin, so you know whose pipeline you are about to touch and who needs to be in the loop before you merge. For the repos that take the change and apply it, Overmind answers the second question: against their live account, is the resulting plan safe, and does anything in the running infrastructure react badly. One is the blast radius across your source. The other is the blast radius inside a cloud. They are not the same radius, and they do not fire at the same moment.
I should be equally clear about where Riftmap stops, because a comparison that only lists the other tool's limits is not worth reading. Riftmap will never catch the OOMKilled-under-load example from earlier. That failure lives in runtime behaviour, in how a JVM uses memory during a traffic spike, and Riftmap does not watch your runtime. It does not know your cloud. It does not see drift. If your worst changes are the ones that look safe in source and only misbehave once they are live, Overmind is reaching a layer Riftmap deliberately does not. The two tools are not redundant. Each is blind exactly where the other sees.
The useful coincidence is that both expose their graphs to machines. Overmind has a CLI and posts into the PR. Riftmap ships an HTTP API and an MCP server with every deployment. An agent reviewing an infrastructure change could call both: Riftmap for the repositories downstream of the artifact it is editing, Overmind for the runtime safety of the plan it produces. This was always the shape of it. The agent is a consumer of whichever graph answers its question, and on a real infrastructure change it has more than one question.
So which one is "Terraform blast radius"
Both are, and that is the whole point. A terraform plan tells you what you are touching. Overmind tells you what that touches in the account you are about to apply to, drift and runtime included. Riftmap tells you who else was building on it, across every repository and every platform, before the plan exists. Three questions, three tools, one overloaded phrase.
If your pain is "the apply looked safe and production fell over anyway", that is the live-cloud question, and Overmind is built for it. If your pain is "we changed a shared module and three teams found out when their pipelines went red", that is the cross-repo question, and no amount of live-cloud analysis will answer it, because the edge that broke was never in the cloud. It was a pinned source block in a repo nobody thought to check. Same two words. Different blast, different radius.
A few questions, answered directly
Does Overmind show cross-repo Terraform blast radius?
No, and the reason is structural rather than a missing feature. Overmind builds its dependency graph from your live cloud state at plan time, scoped to the account a Terraform plan targets. The cross-repo edge that breaks when you change a shared module is a source block pinned to a version in a different repository that has not run a plan, often on a different platform or in a different account entirely. That edge exists only in source, so a tool whose graph comes from the cloud cannot draw it. Overmind answers blast radius inside a running account. Cross-repo consumer questions need a graph parsed from source across the whole org.
What is the difference between Overmind and Riftmap?
They answer different questions about a Terraform change. Overmind reads your live AWS, GCP or Kubernetes state at plan time and tells you what in the running infrastructure a plan could affect, including drift and resources Terraform does not manage, plus a machine-generated risk assessment in the PR. Riftmap parses source across your entire GitLab or GitHub org and tells you which other repositories consume the module, image, chart or CI template you are changing, and at which versions, before a plan exists. Live-cloud and apply-time versus source-derived and org-wide. They are complementary, not substitutes.
Does terraform plan show blast radius?
Not in any of the three senses people usually mean. terraform plan shows the diff between your configuration and your state: the resources this configuration will add, change or destroy. It does not render the resource ordering as a graph (the in-config tools do that), it does not show what in your running cloud could be affected including unmanaged resources (Overmind does that), and it does not show which other repositories consume what you are changing (Riftmap does that). The plan is the input to blast-radius analysis, not the analysis.
Can Overmind and Riftmap be used together?
Yes, and on a real infrastructure change they answer adjacent questions in sequence. Before you ship a breaking change to a shared artifact, Riftmap tells you which repositories and teams consume it, so you know whom to coordinate with and what to gate the merge on. For the repos that apply the change, Overmind tells you whether the resulting plan is safe against their live account. One maps the blast radius across your source. The other maps it inside your cloud. Both expose their graphs over an API or MCP, so an AI coding agent can call either or both during a review.
