# DAC: Dashboard-as-Code for AI Agents, YAML, and Warehouse SQL

> DAC is a Go binary that turns YAML and TSX files into interactive, database-connected dashboards. It includes a semantic layer for defining metrics once, and ships with built-in authoring skills for AI coding agents.

**bruin-data/dac** — DaC is a dashboard-as-code tool. Build interactive dashboards using YAML and JSX. Built-in semantic layer. Get your agents to build standardized, reviewable dashboards.

- Repository: https://github.com/bruin-data/dac
- Website: https://getbruin.com/docs/dac/
- Stars: 771 · Forks: 36
- Language: Go
- License: AGPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/bruin-data-dac

## What Problem DAC Solves: Reviewable, Agent-Built Dashboards

Most dashboard tools are GUI-driven: a user clicks to add a chart, drags to resize it, and the result is stored in a proprietary database that is difficult to review in a pull request or version in git. When AI coding agents generate dashboards, they need a format that is both machine-writable and human-reviewable.

DAC addresses this by defining dashboards as text files in YAML or TSX. A dashboard lives in a git repository alongside the SQL it queries. Changes are diff-able, reviewable, and revertable using standard git tooling. The README describes DAC as "built for AI agents to build dashboards in a reliable and reviewable way."

DAC connects to existing data warehouse connections through Bruin, a data engineering tool also published by bruin-data. The README states that DAC currently shells out to `bruin query` for query execution. This means DAC is not a standalone dashboard server: it requires Bruin to be installed and configured with the relevant warehouse connections.

## YAML and TSX as Authoring Formats

DAC supports two authoring formats for dashboards. YAML defines a dashboard declaratively with named widgets, connection references, SQL queries, and display configuration:

```yaml
name: Sales Overview
connection: warehouse

rows:
  - widgets:
      - name: Revenue
        type: metric
        sql: SELECT SUM(amount) AS value FROM sales
        value:
          field: value
          type: number
          format: "$,.2f"
        col: 4
```

TSX allows dynamic layouts using JSX syntax. The same dashboard in TSX looks like:

```tsx
export default (
  <Dashboard name="Simple Dashboard" connection="my_db">
    <Row>
      <Metric
        name="Total Revenue"
        col={4}
        sql="SELECT SUM(amount) AS value FROM sales"
        value={{ field: "value", type: "number", format: "$,.2f" }}
      />
    </Row>
  </Dashboard>
)
```

The TSX format uses Goja (a JavaScript engine in Go) and esbuild to execute the TSX at server startup and produce the dashboard definition. This enables dynamic layouts: a TSX dashboard can run load-time queries to generate widget lists from the database, which a static YAML file cannot do.

The two formats can reference the same semantic models, and four example projects in the `examples/` directory demonstrate each combination: `basic-yaml`, `basic-tsx`, `semantic-yaml`, and `semantic-tsx`.

## Installing DAC and the Quickstart Workflow

Install the latest stable release with:

```bash
curl -LsSf https://getbruin.com/install/dac | sh
```

The install script also installs the Bruin CLI if it is not already available on your PATH. For the latest build from the main branch:

```bash
curl -LsSf https://getbruin.com/install/dac | sh -s -- --channel edge
```

After installation, create a new starter project:

```bash
dac init my-dashboards
cd my-dashboards
dac validate --dir .
dac validate --dir . --with-database
dac serve --dir . --open
```

The `dac init` command also installs DAC's bundled dashboard authoring skill for Claude and Codex at `.claude/skills/create-dashboard/SKILL.md` and `.codex/skills/create-dashboard`. For existing projects, run `dac skills install --dir .` to add the same skills.

To run one of the bundled example projects from a clone of the repository:

```bash
dac serve --dir examples/basic-yaml
```

DAC sends anonymous usage telemetry by default. To disable it, set `TELEMETRY_OPTOUT=1` or `DO_NOT_TRACK=1` in your environment. Builds compiled with `make build` without a telemetry write key send nothing.

## The Semantic Layer: One Metric Definition, Used Everywhere

The semantic layer is DAC's mechanism for avoiding repeated SQL definitions across dashboards. Metrics and dimensions are defined once in a `semantic/` directory. Any widget in any dashboard can then reference a semantic model and DAC generates the SQL at serve time.

The `examples/semantic-yaml` example shows a YAML dashboard reading from semantic models. The `examples/semantic-joins` example (visible in the example file list) demonstrates how the semantic engine handles joins across tables.

This is meaningful for data teams where multiple dashboards track the same metric, such as monthly active users or revenue. Without a semantic layer, each dashboard repeats its own SQL for that metric. A change to the metric definition then requires finding and updating every dashboard. With DAC's semantic layer, the metric is defined once in `semantic/` and all dashboards pick up the change on the next serve.

DAC uses the `bruin-data/bruin/semantic-engine` package as a dependency (version `v0.0.0-20260922134708-9aeab44d7e4b` in go.mod). The semantic engine is part of the larger Bruin project, which means the semantic layer's functionality is coupled to the Bruin codebase.

## Limitations: AGPL License, Bruin Dependency, and No Standalone Mode

The license is AGPL-3.0-only. This means that any service built on top of DAC that is made available over a network must release its modifications under the same terms. For a commercial SaaS product that wants to include DAC as an embedded component without releasing its own code, AGPL-3.0 is a practical blocker without a separate commercial license.

DAC currently shells out to `bruin query` for query execution. This is a direct statement from the README, not a minor implementation detail. There is no embedded query engine in DAC itself: the database connection lives in Bruin's configuration, and DAC passes queries to Bruin to execute. A team without an existing Bruin installation must set up Bruin before any dashboard can run against a real database.

DAC is at version 0.21.1, released on 2026-09-28. The project uses the edge channel for pre-release builds (the `v0.0.0-edge.X.XXXXXXX` versioning scheme). With three releases on the same day the article was reviewed, the release cadence is clearly active. That said, the version number below 1.0 reflects that breaking changes in the YAML or TSX configuration format remain possible.

The frontend is embedded in the DAC binary using Go's embed functionality. The `embed.go` file at the repository root handles this embedding. There is no way to customize the frontend without forking the repository and rebuilding the binary, which requires the `make build` target rather than the install script.

DAC sends anonymous usage telemetry by default. The README describes exactly what is collected (command name, run duration, OS/architecture, DAC version, and an anonymous install ID) and what is not (SQL queries, connection names, dashboard contents). Teams with strict data policies should set `TELEMETRY_OPTOUT=1` before first use.

## Project Layout and Contributing to DAC

The repository layout reflects the separation of concerns in the binary. The `cmd/` directory contains CLI entrypoints. The `pkg/` directory holds dashboard loading, the semantic engine, the server, and query backends. The `frontend/` directory contains the React frontend that is compiled and embedded into the Go binary at build time. Documentation source lives in `docs/` as a VitePress site. The `testdata/` directory holds internal test fixtures.

The standard development workflow uses Make targets:

```bash
make deps
make test
make build
make dev
```

The README notes that `make` targets should be used rather than ad-hoc `go build` or `npm run build` commands, because the Makefile handles frontend embedding and build flags consistently. The `make dev` target starts a development server with hot reload. The `make build` target produces the binary without a telemetry write key by default, making development builds silent.

Contribution guidelines are in `CONTRIBUTING.md` and the security policy is in `SECURITY.md`. The `.agents/` and `.claude/` directories at the repository root contain AI coding agent configuration for contributors using those tools.

## Alternatives: Metabase and Grafana for Teams Without a Code-First Constraint

Metabase is a widely used open-source business intelligence tool. It provides a GUI query builder, dashboard editor, and a web-based interface that non-technical users can operate without writing SQL or editing files. Metabase stores its configuration in a database rather than in version-controlled text files. The practical difference: Metabase is better for organisations where business users build and maintain dashboards themselves, while DAC is better for organisations where dashboards live in a git repository and are reviewed in pull requests.

Grafana is an open-source observability and analytics platform with its own dashboard-as-code options (via Grafonnet or dashboard JSON provisioning). It targets infrastructure and operations metrics primarily but supports SQL data sources. Grafana's dashboard-as-code path requires either JSON files or Jsonnet/Grafonnet, which are less readable than DAC's YAML format for non-engineers.

DAC's specific advantage is the AI agent authoring skill and the semantic layer: the bundled skills for Claude and Codex give AI agents a defined format to produce dashboards in, and the semantic layer ensures the agent uses consistent metric definitions rather than inventing its own SQL for each widget.

## Conclusion

DAC suits data teams and AI agents that need to produce reviewable, version-controlled dashboards against warehouse connections already managed through Bruin. The AGPL-3.0 license is a meaningful constraint: any service that wraps or distributes DAC must release modifications under the same terms, which rules it out for proprietary SaaS products without a commercial arrangement. Teams evaluating DAC without an existing Bruin setup should factor in that DAC currently shells out to `bruin query` for query execution, so Bruin is a hard dependency and not an optional add-on.

## FAQ

### Does DAC require Bruin to be installed?

Yes. The README states that DAC currently shells out to `bruin query` for query execution. The install script installs the Bruin CLI if it is not already available on your PATH. DAC uses Bruin's existing connection configuration to reach databases.

### Can AI agents like Claude write DAC dashboards?

DAC ships with a dashboard authoring skill for Claude and Codex, installed automatically by `dac init`. The README describes the tool as built for AI agents to produce dashboards in a reliable and reviewable way. For existing projects, run `dac skills install --dir .` to add the skill files.

### What databases does DAC support?

DAC supports all databases that Bruin supports, including Postgres, MySQL, Snowflake, BigQuery, Redshift, and Databricks. The connection is configured in Bruin, and DAC routes queries through `bruin query`.

## Sources

- [bruin-data/dac on GitHub](https://github.com/bruin-data/dac)
- [License: AGPL-3.0](https://github.com/bruin-data/dac/blob/main/LICENSE)
- [Project website](https://getbruin.com/docs/dac/)
- [README](https://github.com/bruin-data/dac/blob/main/README.md)
- [Releases](https://github.com/bruin-data/dac/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bruin-data-dac