Tool Alternatives

Hava alternative: two honest answers to what does our architecture look like

By the engineer who builds Datadef, from client work on data platforms · Reviewed August 21, 2026

Hava connects to your cloud accounts and draws what is running. That is a legitimate and useful answer, and for some questions it is the only correct one. It is not the same answer as reading the repository that produced the cloud account, and choosing between the two is mostly about which question your team actually has.

Try it free
7 min readFor platform and consulting teams choosing between a cloud scanner and a repo parse

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

158/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

What Hava does well

It connects securely to AWS, Azure, Google Cloud, and Kubernetes and generates interactive diagrams from the live configuration, laid out by VPC or resource zone rather than dumped as a flat list. That is a lot of value for a connection you set up once.

The views around it are the real product. A security view showing security groups, subnets, and ingress and egress paths, which is how you spot the port someone opened for a test in March. Cost estimates broken down by VPC, region, instance, tag, or project. Container support alongside the cloud resources. Exports to Visio, PNG, CSV, and JSON, and an embeddable interactive viewer.

And it keeps watching. Hava polls the cloud configuration, updates diagrams when something changes, and archives the previous version, so you can compare across time and see drift as it happens. For an operations team, that history is worth more than the first diagram.

What a live scan structurally cannot show

It cannot show what is not deployed. A module written last week, an environment that exists only in the release branch, a change waiting in review: none of it is in the account, so none of it is in the diagram. For teams reviewing infrastructure before it ships, that is the wrong end of the pipeline.

It cannot show the parts of the system that are not cloud resources. The dbt models, the CI pipelines, the API contracts, the service manifests that describe how the application is composed, all of that lives in the repository and is invisible to a cloud API.

And it needs access to the account. An IAM role in a production subscription is a conversation with security, a change ticket, and sometimes a hard no. Consultants and platform teams working across client environments often have read access to a repository and nothing else, and that is precisely the case where a repo parse works and a scanner does not.

How the repository parse works instead

Datadef connects read-only to GitHub, GitLab, or Azure DevOps, tracks one branch or tag per diagram, and generates the architecture from the files that declare it, including Terraform, containers and orchestration, schemas and dbt models, API specs, and CI pipelines. Terraform repositories get a dedicated parse: every .tf file, modules drawn as zones, per-environment counts read from tfvars, registry modules recognized with their versions, and no init, no state, and no cloud credentials.

Two behaviours are worth naming, because they are exactly where a live scan and a source parse diverge. Environments are discovered from the tfvars layout, so a repository holding environments/DEV and environments/QUAL produces one drawing of the platform annotated with the real counts, something like per lakebase_projects (DEV 2, QUAL 1), rather than two near-identical copies of the same architecture. And a module pulled from the registry cannot be expanded from source, so the call becomes a single node carrying its source and version, with its inputs drawn as edges: a module.eks consuming module.vpc.vpc_id draws eks to vpc even though neither module body lives in your repository.

The document produced by the same read carries the inventory the diagram compresses: a module reference table with one row per module, its source, its resource count, and its multiplicity, composed from the parse rather than written by a model. Directories named examples, tests, or fixtures are dropped from the model first, on the grounds that they describe how to use the repository rather than what it is.

The diagram and a generated architecture.md refresh on a daily sync, skip commits that change nothing structural, and can be refreshed on demand or by an agent over MCP. The output goes where readers already are: an editable canvas, PNG and JPEG export, and a live embed for the README or wiki.

Intent versus reality

A repository parse shows what the code declares. A cloud scan shows what is deployed. Teams that care about the difference between the two are describing drift, and both instruments are useful. See how to detect stale diagrams.

Picking the right one

Choose a cloud scanner when the questions are operational: what is running right now, which security group is open, what does this VPC cost, what changed in the account overnight.

Choose a repository parse when the questions are architectural: what does this platform build, how are the modules composed, what is different between environments, and what will exist after the next merge. Also choose it when the access conversation is the blocker, because read access to a repository is a much smaller ask than a role in a production account.

FAQ

Does Datadef connect to AWS, Azure, or Google Cloud accounts?

No. It connects to repositories on GitHub, GitLab, and Azure DevOps with read-only access, and nothing else. No cloud credentials are involved at any point, and Terraform repositories are parsed file by file with no init, no plan, and no state access, which is what makes it usable when the cloud account is off limits or belongs to a client.

Will the diagram show what is actually deployed?

It shows what the connected branch or tag declares. That is the intent rather than the runtime state, so it includes infrastructure that has not been applied yet and it will not detect a resource created manually in the console.

Can it draw environments that differ, like dev and prod?

Yes. Environment names are read from the tfvars layout, so environments/DEV and environments/QUAL are discovered without being configured. A resource or module created once per environment is drawn once, annotated with the real counts per environment, instead of appearing as duplicated copies of the same platform on one canvas.

Is there version history when the architecture changes?

Each sync regenerates the diagram and the architecture doc from the current ref, and a sync whose structure hash matches the previous one regenerates nothing, so the history stays quiet while the code does. Publishing a version preserves a state deliberately, and a second diagram can track a release tag alongside the one tracking main.

What happens to the diagrams if the subscription lapses?

Nothing is deleted. Diagrams and documents stay viewable, and existing embeds keep rendering the last synced version, so a README does not break. Background syncs and manual refreshes pause until the plan is active again, at which point the next sync picks up from the current head commit.