Skip to content

Latest commit

 

History

459 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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.

PyPI Tests Python Rust License Slack

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
Other ways to install: one-line script, Homebrew, pipx, pip, offline

One-line script (macOS and Linux). Installs uv first if it is missing, never uses sudo, and accepts --update, --version X, and --help:

curl -fsSL https://glyfdata.com/install.sh | sh

Homebrew. brew trust is required. Homebrew 6.0 refuses to load formulae from untrusted third-party taps:

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

pipx or pip. Prefer uv or pipx for a CLI tool; use pip when you want glyf inside an existing project virtualenv, next to dbt-core:

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

Offline or air-gapped. Every release ships platform wheels, an sdist, and a checksums.txt:

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

Command What it does
glyf init Scaffold glyf config, chart, and dashboard directories
glyf doctor Check dbt artifacts, chart files, and SQL execution
glyf build Full pipeline: compile, render, and export
glyf serve Serve the generated site locally
glyf list List discovered charts and dashboards
glyf validate Validate chart and dashboard specs without rendering
glyf render Render charts only
glyf dashboard Build dashboards only
glyf export Export the publishable site (--clean, --zip)

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

Analytics Engineer You work in dbt and version-control everything. You should not need LookML or a BI platform UI to publish a declared dashboard artifact.
Data Scientist Write SQL-style chart definitions that run in the pipeline and stay current, instead of one-off notebooks that drift.
Data Leader Open source, runs locally, and produces outputs your team already knows how to deploy and review.
Application Engineer The data team owns the spec; you consume rendered output without negotiating with an embedded analytics vendor.

Status

Capability
dbt ref() and source() resolution from manifest.json shipped
GGSQL chart definitions, SQL execution, Altair rendering shipped
Warehouse execution through the dbt profile (DuckDB, Trino, Snowflake, BigQuery) shipped
Dashboard YAML, Python macros, self-contained static site shipped
PNG / SVG chart artifacts and --zip export shipped
Visual diff between builds, on the pull request (glyf diff) shipped
Data protection: row_data modes, PII deny/redact, value scan, per-audience builds, build provenance shipped
React components (@glyf/react, experimental) preview
MCP server so agents can reason about the chart graph planned

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:

Quickstart First build, end to end
Configuration glyf.yml reference
Visualisation syntax The GGSQL format, and glyf's additions to it
Dashboard YAML Layout, sections, macros
dbt integration Artifacts, ref(), adapters
CI/CD Building glyf in a pipeline
Troubleshooting Common failures

Community

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

Join the Slack community The quickest way to get help, and where glyf gets built in the open. Ask in the help channel.
Discussions Questions and ideas that others will want to find later.
Issues Bugs and feature requests.
Support Where to ask what, and what to check before you ask.
Roadmap What shipped recently and what is planned.

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.

More on developing from this repository

Dev dependencies include dbt-core and dbt-duckdb for the bundled examples.

make on its own lists every target. Individual steps: make install, make test, make coverage, make build, make rust, make dashboard-ci. make test runs pytest with coverage and writes coverage.xml, which CI uploads to Codecov. make ci PYTHON_VERSION=3.12 runs against a specific Python.

Run the docs site locally with Node.js installed:

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.

About

Open Source Visualization build tool to data pipeline

Topics

Resources

Code of conduct

Contributing

Security policy

Stars

4 stars

Watchers

0 watching

Forks

Releases

Packages

Used by

Contributors

Languages