glyf

Build visualizations the way you build pipelines.

An open source, code-first build step for charts and dashboards from your dbt models.
Define charts in SQL, compose dashboards in YAML, publish anywhere.

Install · Quickstart · How it works · CLI · Examples · Docs · Community

  ┌──────────────────────┐   ┌──────────────────────┐   ┌──────────────────────┐
  │     dbt project      │   │     glyf sources     │   │      glyf build      │
  ├──────────────────────┤   ├──────────────────────┤   ├──────────────────────┤
  │ models/*.sql         │   │ charts     *.ggsql   │   │ resolve  ref()       │
  │ target/manifest.json │──▶│ dashboards *.yml     │──▶│ execute  SQL         │
  │ warehouse relations  │   │ macros     *.py      │   │ render   Altair      │
  └──────────────────────┘   └──────────────────────┘   └───────────┬──────────┘
                                                                    │
      ┌─────────────────────────┬───────────────────────┬───────────┘
      ▼                         ▼                       ▼
      site/index.html           charts/*.png *.svg      export --zip
      static dashboard          chart artifacts         zip for CI

The last mile

Every stage of the modern data stack has declarative, version-controlled, testable artifacts. Every stage except visualization.

Your models are versioned. Your jobs are automated. Your data quality is tested. Visualization is still the last artifact outside the pipeline.

• Dashboards live outside the workflow. Your dbt models are in Git. Your charts are usually configured in a browser, stored elsewhere, and maintained by whoever last touched the UI.
• Columns rename, charts break silently. When dbt models change, dashboard failures show up late. glyf moves chart definitions into a build step that validates earlier.
• Publishing should not require a vendor. For internal portals and product dashboards, rendered HTML and chart assets are usually enough.

glyf is artifact-driven, not dbt-runtime-driven: run dbt first, then run glyf against the resulting artifacts and relations.

Install

glyf is published on PyPI as glyf-core. The package installs the glyf command and the glyf Python module; only the distribution name differs.

uv tool install glyf-core
glyf --version

curl -fsSL https://raw.githubusercontent.com/glyf-data/glyf/main/install.sh | sh

brew tap glyf-data/glyf
brew trust --tap glyf-data/glyf
brew install glyf

pipx install glyf-core
python -m pip install glyf-core

sha256sum --check --ignore-missing checksums.txt
uv tool install ./glyf_core-<version>-cp311-abi3-<platform>.whl

Prebuilt wheels cover Linux (x86_64, aarch64), macOS (Intel, Apple Silicon), and Windows (x86_64). They target Python 3.11+ through the stable ABI, so one wheel per platform covers every supported Python version and no Rust toolchain is needed. Upgrade with uv tool upgrade glyf-core.

Quickstart

In an existing dbt project:

glyf init      # scaffold glyf.yml, visualisations/, dashboards/
dbt build      # produce the dbt artifacts glyf reads
glyf doctor    # check artifacts, charts, and SQL execution
glyf build     # compile, render, and export the site
glyf serve     # preview it locally

doctor reports whether the dbt artifacts, chart files, and SQL execution are ready before your first build, so the first failure is a readable message rather than a stack trace.

How it works

01. Write charts in GGSQL

SQL you already know, then a few lines saying what to draw. The format is GGSQL; glyf reads it as is and adds chart types and interactions of its own, marked in the syntax guide. Use ref() to reference dbt models directly, exactly as a dbt model would:

SELECT month, revenue
FROM {{ ref('fct_orders') }}

VISUALISE month AS x, revenue AS y
DRAW line
LABEL title => 'Monthly Revenue'
LABEL subtitle => 'Revenue trend from dbt model'
CONFIG width => 900

glyf resolves each reference to its schema path from target/manifest.json and validates the query before it renders anything.

02. Compose dashboards in YAML

Lay charts out into sections. Use Python macros for labels, thresholds, and reusable components, so a dashboard change is a one-line diff in review:

name: executive
title: Executive Dashboard

summary:
  - "{{ ui.label_value('Owner', 'Analytics Engineering') }}"
  - "{{ ui.label_value('Generated', time.now('%Y-%m-%d %H:%M')) }}"

layout:
  columns: 3

sections:
  - title: Revenue overview
    columns: 3
    items:
      - metric:
          label: Sample revenue
          value: "$7.6k"
      - chart: revenue
        title: Monthly revenue
        width: 2

03. Build once, publish anywhere

One command resolves dbt artifacts, validates chart specs, executes chart SQL against your warehouse, renders charts with Altair, and emits files you can publish:

target/glyf/
├── compiled/     resolved chart SQL
├── charts/       rendered PNG / SVG, and chart metadata
├── data/         chart rows and Vega specs, internal and never published
├── dashboards/   generated dashboard pages
├── assets/       CSS and fonts
├── index.html    landing page
├── bundle.json   manifest of everything built
└── site/         self-contained static site  ← publish this

No BI server to maintain. Drop site/ into S3, GitHub Pages, a docs site, or a CI artifact. Publish site/ rather than target/glyf/: the rest is working output, and data/ holds the raw rows.

A published site carries the data behind its charts unless you ask otherwise. See what a published site exposes.

CLI

Point any command at another project with --project-dir:

glyf build --project-dir examples/sales_dashboard

Examples

Four runnable projects live in examples/: simple_dbt, sales_dashboard, product_analytics, and finance_metrics.

uv sync
cd examples/simple_dbt
uv run dbt seed --profiles-dir . --full-refresh --no-partial-parse
uv run dbt run --profiles-dir .
uv run dbt compile --profiles-dir .
uv run glyf build
uv run glyf serve

Then open examples/simple_dbt/target/glyf/site/index.html.

Who it's for

Status

See the roadmap for the longer view.

Documentation

The full docs site is built from docs-site/ and published at glyfdata.com. These guides are also readable directly in the repository:

Community

Questions, ideas, or something not working? Come and ask.

React components for embedding glyf output in a web application are in glyf-js. They are experimental.

Contributing

Contributions are welcome, and small ones most of all: a bug fixed with a test, a clearer error message, a better example. CONTRIBUTING.md takes you from a fresh clone to a merged pull request in five steps.

git clone https://github.com/<you>/glyf.git && cd glyf
uv sync --all-groups      # needs Python 3.11+, uv and a Rust toolchain
make ci                   # everything CI runs

Signing the CLA is one comment on your first pull request, once. You keep the copyright in your work.

cd docs-site
npm install
npm start

Paths in glyf.yml and dashboard YAML use forward slashes on every platform.

License and attribution

glyf is licensed under Apache 2.0. Use it, modify it, ship it, at no cost, for any purpose.

If you copy or adapt this code, keep the LICENSE and NOTICE files with it and credit the project. The Apache License requires both files to travel with the code. Visible credit is what keeps open source working, and a line like this is enough:

Based on glyf (https://github.com/glyf-data/glyf), Copyright Kannan Kalidasan, Apache 2.0.

The name "glyf" and the logo are trademarks and are not covered by the code license. Forks and derived products need their own name. See TRADEMARK.md.

The chart file format is GGSQL, an open source project from Posit, which glyf adopts and extends. Chart SQL is parsed with sqlparser-rs (Apache 2.0).

Copyright 2026 Kannan Kalidasan.