← Terraform Plan Blast Radius Check

This checker vs. writing your own Sentinel or OPA policy

Same failure, different cost. Sentinel and OPA/Conftest can both stop an apply that destroys or replaces a stateful resource — once somebody writes and maintains a policy that says which resource types count. This tool ships that detection already built, with no policy language and no platform to adopt.

What each one is for

Sentinel is HashiCorp's policy-as-code engine, bundled with Terraform Cloud and Terraform Enterprise. OPA (Open Policy Agent) and Conftest are open-source alternatives that evaluate a plan against a policy written in Rego, usually wired into CI by hand. Both are general-purpose: an organization typically uses them for cost ceilings, region allow-lists, tagging rules, module version pins, and destructive-change checks, all as separate policies someone writes, reviews, and keeps current as providers add resource types.

This tool checks exactly one thing — whether a replace or destroy in the plan lands on a resource type that holds data — and ships that detection already built, as a zero-dependency Node.js CLI or a browser page that reads the same terraform show -json file. There is no policy to author, no Rego or Sentinel language to learn, and no Terraform Cloud or Enterprise subscription to adopt just to get this one check.

It exists because that one check is easy to write once and easy to let go stale. See why a replace destroys data, and why the plan text does not always say which attribute forced it for the mechanics this tool's token-matching heuristic is built against.

QuestionWhere to answer it
Is this apply about to destroy a database, disk, or bucket, right now?This checker — paste or load your plan, free, no account.
Do I already have a Sentinel or OPA policy for this?Check its resource-type list against this checker's report; a name-based heuristic catches types a hand-written list has not been updated for yet.
Do I need to buy Terraform Cloud/Enterprise for policy-as-code?Only if you want Sentinel specifically, or its other policy features. This one check needs no platform.
Should I replace my whole Sentinel/OPA policy set with this?No — those cover cost, tagging, region, and version rules this tool does not attempt. Run this alongside them for the destroy/replace question.
Is my plan uploaded anywhere?No. The browser page and the CLI both read the file locally and make no network call.

This checker is a narrow, zero-configuration alternative to one specific policy, not a policy-as-code platform. It does not evaluate cost, tagging, region, or version rules, and it does not integrate with Terraform Cloud's or Terraform Enterprise's policy sets.

This tool needs no account and no sign-in: the CLI reads a local file with no network call, and the browser page parses a pasted or loaded file entirely on your device.

Common questions

Should I use this checker or write a Sentinel or OPA policy instead?

They solve the same problem at different costs. Sentinel (bundled with Terraform Cloud/Enterprise) and OPA/Conftest can both block an apply that would destroy or replace a stateful resource — once somebody writes a policy in Sentinel's or Rego's policy language that enumerates which resource types count as stateful, keeps that list current as your providers add types, and maintains it across every workspace. This tool ships that detection already built, as a plain Node.js CLI or a browser page, with nothing to write and nothing to keep in sync.

Do I need Terraform Cloud or Enterprise to use this?

No. Sentinel policies only run inside Terraform Cloud or Terraform Enterprise, so adopting Sentinel for this one check means adopting that platform. This tool reads the same terraform show -json file open-source Terraform and OpenTofu already produce, so it runs in any CI system, any pre-commit hook, or a browser, with no platform requirement.

Can this checker replace an existing Sentinel or OPA policy set entirely?

Only for this specific question. Sentinel and OPA/Conftest are general-purpose policy engines organizations use for cost limits, tagging standards, allowed regions, module version pins, and many rules beyond destructive changes — this tool checks exactly one thing, whether a replace or destroy lands on a resource type that holds data. Teams already invested in Sentinel or OPA for other policies can still run this tool as a fast, zero-configuration second opinion on that one question, or port its token-matching approach into their existing Rego or Sentinel policy.

What happens when this tool does not recognize a new resource type?

It is biased toward flagging rather than staying silent: the heuristic matches on tokens in the resource type name itself (database, disk, bucket, DNS, and so on), not a hand-maintained list of exact type names, so a provider's new resource type is caught automatically if its name carries one of those tokens. A hand-written Sentinel or Rego policy that enumerates exact type strings has the opposite failure mode — it stays silent on any type nobody added yet, which is the gap this tool's name-based matching is built to avoid.

Open the Terraform Plan Blast Radius Check against your own plan, or read why a replace destroys data.