Tool Alternatives

Brainboard alternative: when you want the diagram without moving where infrastructure is authored

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

Brainboard is an infrastructure platform with a canvas on the front. You design visually, it generates Terraform, and it carries the rest of the lifecycle: an embedded CI/CD, policy checks, cost estimation, drift detection, and git integration. That is a coherent product and a real category. It is also a much bigger commitment than most teams realize they are making when what they wanted was an accurate diagram.

Try it free
6 min readFor teams who want infrastructure documentation without changing how infrastructure is written

See it as a diagram

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

152/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

What Brainboard offers

The core loop is design first, code second. Draw the architecture on a canvas and production-ready Terraform is generated from it, across AWS, Azure, Google Cloud, Oracle Cloud, and Scaleway in one workspace. Existing Terraform modules and repositories can be imported, which is how teams migrate onto it.

Around that sits the rest of a platform: a visual CI/CD engine with pipeline components maintained for you, policy and security scanning through Checkov, tfsec, Terrascan and OPA, cost estimation through Infracost, drift monitoring against the cloud provider, and native git across GitHub, GitLab, Bitbucket and Azure DevOps. For a team that wants one place to design, review, and ship infrastructure, that bundle is the argument.

The commitment underneath the canvas

A tool that generates your Terraform wants to be the place your Terraform lives. That is a platform decision, with the usual questions attached: how the generated code reads to someone reviewing it in a pull request, what happens to the module conventions your team already standardized on, how it fits with Terragrunt or Atlantis or whatever runs your applies today, and how you leave if you want to.

Most teams asking for an architecture diagram are not asking to change any of that. They author in an IDE, they review in pull requests, they apply in a pipeline they trust, and the missing piece is a picture that is true and a document that is current. Adopting an authoring platform to solve a documentation problem is a large lever for a small screw.

There is also a scope limit. An authoring platform documents the infrastructure it manages. Repositories you did not build, client repositories, legacy stacks nobody is migrating, and non-Terraform parts of the system stay outside it.

Documentation only, and deliberately so

Datadef never writes to your repository, never generates infrastructure code, and never applies anything. The connection is a read-only token, and the scopes are small enough to name exactly: on GitHub a fine-grained token limited to the one repository with Contents set to read-only, which GitHub pairs with read-only Metadata by itself; on GitLab a personal access token with read_api; on Azure DevOps a token with Code set to Read. A public repository needs no token at all. The token is validated on the spot by listing the repository branches, then stored encrypted with AES-256-GCM, and afterwards only its last four characters are ever shown.

From that read it generates a diagram and an architecture.md and keeps them current: modules as zones, real provider icons, per-environment counts from tfvars, registry modules recognized with their versions, a daily sync that skips commits with no structural change, and refresh on demand or from an agent over MCP.

Because it only reads, it works on repositories you do not control. Consultants point it at a client repo with read access and get an architecture doc without touching the client cloud account or the client workflow, which is not something an authoring platform can do.

Not a competitor on authoring

If you are choosing where to build and deploy infrastructure visually, Datadef is not in that race. It produces documentation from whatever repository you already have. See how repository sync works.

What comes out of a read-only pass

One read of the branch produces two artifacts: a diagram on an editable canvas, and an architecture.md. For a Terraform repository that document ends with a module reference table which is composed from the parse rather than written by a model, so every row is a module that exists, with the source string it was called with and the number of resources it declares.

None of it requires the repository to move, to be restructured, or to adopt a module convention. That is the whole difference in commitment: an authoring platform wants to own where infrastructure lives, and a documentation pass only wants read access to where it already lives.

The table below is the counterpart to the curation on the canvas. The diagram rolls repeated resources up so a person can read it in one sitting; the table keeps the full inventory so nobody has to take the rollup on trust. A row marked external is a registry or git module whose body is not in your repository, counted as external rather than guessed at, and drawn on the canvas as a single node carrying its source and version. The environments line comes from the tfvars layout rather than from configuration.

## Module reference

| Stack | Module | Source | Resources | Notes |
| --- | --- | --- | --- | --- |
| platform | (root) | - | 9 | backend azurerm |
| platform | networking | `./modules/networking` | 14 | |
| platform | databricks | `./modules/databricks` | 22 | per lakebase_projects (DEV 2, QUAL 1) |
| platform | vpc | `terraform-aws-modules/vpc/aws` | external | |

Environments: DEV, QUAL (tfvars).

FAQ

Does Datadef generate Terraform code?

No. It reads repositories and produces a diagram and an architecture document. It never writes to the repository, never opens a pull request, and never provisions or applies anything. Where infrastructure is authored, reviewed, and applied stays exactly as it is, which is the point of choosing a documentation pass over an authoring platform.

What access does the repository connection need?

Read-only, with named scopes. On GitHub, a fine-grained token scoped to one repository with Contents read-only. On GitLab, read_api. On Azure DevOps, Code set to Read. Public repositories need no token at all. A stored token is encrypted with AES-256-GCM, and only its last four characters are ever displayed again.

Can it document a repository my team does not own?

Yes, and that is a common case. Read access is the entire requirement: no cloud account, no pipeline change, no repository restructuring. Consultants point it at a client repository and get a diagram and an architecture document without touching the client cloud or the client workflow, which an authoring platform cannot do.

Does it detect drift between the code and the deployed cloud?

No. It documents what the connected branch or tag declares, which is intent rather than runtime state. Comparing that against the live cloud needs a tool with access to the account. A resource created by hand in a console will not appear, and infrastructure merged but not yet applied will.

What does the generated documentation contain?

A diagram on an editable canvas and an architecture.md describing what the repository builds. For Terraform repositories the document ends with a module reference table, one row per module with its source, its resource count, and its multiplicity, composed from the parse rather than written by a model, plus the environments discovered in the tfvars layout.