About

CloudOps Toolkit is a growing set of free tools for the config files cloud work runs on. Paste a Terraform file, a Kubernetes manifest, an IAM policy, an ARN or a CIDR block, and find out whether it is valid, exactly where it is wrong, and what it will actually do.

Everything runs in your browser

Not as a privacy gesture, but because of what these tools take. An IAM policy is a map of what your credentials can reach. A Kubernetes Secret is a credential. An address plan is a diagram of your network. None of that should be posted to a stranger's server, and none of it needs to be: parsing a file is something a browser does perfectly well.

So there is no request carrying your input, no storage, and nothing to delete afterwards. Disconnect from the network and the tools still work.

No account, no email

No sign-up wall, no gated export, no "enter your work email to see your results". If a tool cannot be useful without a form in front of it, it is not a good enough tool.

Validators first

Every tool leads with the same answer: is this valid, and if not, which line and column, and what is the likely cause in plain language. The security and cost analysis is a second act you can filter away. That order matters, because "does it parse" is the question people arrive with and most tools bury it.

Generators follow the same rule from the other direction: each one feeds its output back through the matching validator on this site and reports the result, so safe defaults are demonstrated rather than claimed.

Who builds it

CloudOps Toolkit is built and maintained by working engineers, for working engineers. Every rule here comes from a specification, an upstream source or a published vector rather than from received wisdom: Kafka's own generated ConfigDef data, the Avro and protobuf specifications, Kubernetes' deprecated API migration guide, RFC test vectors. Where a fact could not be checked against something external, the page says so rather than implying it was.

There are no accounts, no analytics, no cookies, no paid tier and nothing to buy. That is a deliberate choice rather than a stage we have not reached yet: a site with nothing to sell has no reason to want your data, and that is the whole argument for pasting a config into it.

That narrowing is the real distinction between the two. Config describes what you meant to build. A scan describes what is actually running: resources created by hand, drift since the last apply, snapshots nobody claimed, and what every one of them costs. These tools cannot see any of that, and say so where it matters.