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
┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ 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://raw.githubusercontent.com/glyf-data/glyf/main/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, extended with a visualization grammar. 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 |
| Generated typed React components | planned |
| MCP server so agents can reason about the chart graph | planned |
| Visual diff between builds as a CI artifact | planned |
See ROADMAP.md for the longer view.
Documentation
The full docs site is built from docs-site/
and published at glyf.pages.dev. These guides are also
readable directly in the repository:
| Quickstart | First build, end to end |
| Configuration | glyf.yml reference |
| Visualisation syntax | The GGSQL grammar |
| Dashboard YAML | Layout, sections, macros |
| dbt integration | Artifacts, ref(), adapters |
| CI/CD | Building glyf in a pipeline |
| Troubleshooting | Common failures |
Contributing
Developing from this repository
uv sync
Dev dependencies include dbt-core and dbt-duckdb for the bundled examples.
The Makefile runs the same checks locally and in GitHub Actions:
make ci # the full pipeline
make ci PYTHON_VERSION=3.12 # against a specific Python
make on its own lists every target. Individual steps: make install,
make test, make coverage, make build, make dashboard-ci. make test
runs pytest with coverage and writes coverage.xml, which CI uploads to
Codecov.
Run the docs site locally with Node.js installed:
cd docs-site
npm install
npm start
Issues and pull requests are welcome. Paths in glyf.yml and dashboard YAML use
forward slashes on every platform.
License
Release files for glyf-core 0.7.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| glyf_core-0.7.0.tar.gz | 285.6 kB | Details |
Built distributions (wheels)
| File | Reset | |||
|---|---|---|---|---|
| glyf_core-0.7.0-cp311-abi3-win_amd64.whl | CPython 3.11 | abi3 | Windows x86-64 | Details |
| glyf_core-0.7.0-cp311-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl | CPython 3.11 | abi3 | Linux glibc 2.17+ x86-64 | Details |
| glyf_core-0.7.0-cp311-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl | CPython 3.11 | abi3 | Linux glibc 2.17+ ARM64 | Details |
| glyf_core-0.7.0-cp311-abi3-macosx_11_0_arm64.whl | CPython 3.11 | abi3 | macOS 11.0+ ARM64 | Details |
| glyf_core-0.7.0-cp311-abi3-macosx_10_12_x86_64.whl | CPython 3.11 | abi3 | macOS 10.12+ x86-64 | Details |
Total release size: 21.1 MB
Release files / glyf_core-0.7.0.tar.gz
| Download URL | glyf_core-0.7.0.tar.gz |
|---|---|
| Size | 285.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
0ee8317ff18b843669f93c55800f2eee1bec266b90d920f5df083195f247cda3
|
|
BLAKE2b-256 checksum How to use checksums |
d9748f5992d8727d97ea499d034c391ca75d3861b4b25712ee6f82de34cbe0a5
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 20, 2026.
Transparency logRelease files / glyf_core-0.7.0-cp311-abi3-win_amd64.whl
| Download URL | glyf_core-0.7.0-cp311-abi3-win_amd64.whl |
|---|---|
| Size | 3.9 MB |
| Tags | CPython 3.11 Windows x86-64 abi3 |
|
SHA-256 checksum How to use checksums |
361e09c9c29941a3e9b1ebac21e7af951bcfac57f81bd0437a5ab58524954a0c
|
|
BLAKE2b-256 checksum How to use checksums |
03c4c8358f2846f72401a9c4b4dd4bc4f92c73cca4d05d2ca55fb44f60832bfa
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 20, 2026.
Transparency logRelease files / glyf_core-0.7.0-cp311-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
| Download URL | glyf_core-0.7.0-cp311-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl |
|---|---|
| Size | 4.5 MB |
| Tags | CPython 3.11 Linux glibc 2.17+ x86-64 abi3 |
|
SHA-256 checksum How to use checksums |
e84c3033a0bf4706b67a993436396bea666026b80d39af0a273483df1df6914d
|
|
BLAKE2b-256 checksum How to use checksums |
ce2b1ab742dcc648b23cb20a7ba1cc7480bd58342893b8d31f3acd12d4b074e6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 20, 2026.
Transparency logRelease files / glyf_core-0.7.0-cp311-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
| Download URL | glyf_core-0.7.0-cp311-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl |
|---|---|
| Size | 4.4 MB |
| Tags | CPython 3.11 Linux glibc 2.17+ ARM64 abi3 |
|
SHA-256 checksum How to use checksums |
42fc3577549f89aaf472b16509e4a69236f8586a238ca80e2c90c7d7ce76a3ba
|
|
BLAKE2b-256 checksum How to use checksums |
9983e0387e52db9127cd4b01bd1a87076a35e9779ead6e377897e61fa4288232
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 20, 2026.
Transparency logRelease files / glyf_core-0.7.0-cp311-abi3-macosx_11_0_arm64.whl
| Download URL | glyf_core-0.7.0-cp311-abi3-macosx_11_0_arm64.whl |
|---|---|
| Size | 3.8 MB |
| Tags | CPython 3.11 abi3 macOS 11.0+ ARM64 |
|
SHA-256 checksum How to use checksums |
7a061a20fe9a6ecac7d3dfc5e4d2f9e9cebb5eae1c6721caffc65e56c84d83e5
|
|
BLAKE2b-256 checksum How to use checksums |
280c0919f675a631488a77f94dfbe29bce4adff834b81d6e5a3fd03dab720c28
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 20, 2026.
Transparency logRelease files / glyf_core-0.7.0-cp311-abi3-macosx_10_12_x86_64.whl
| Download URL | glyf_core-0.7.0-cp311-abi3-macosx_10_12_x86_64.whl |
|---|---|
| Size | 4.1 MB |
| Tags | CPython 3.11 abi3 macOS 10.12+ x86-64 |
|
SHA-256 checksum How to use checksums |
ad24ce65a3861f03021cd01bd30ef0f80d17371af08f1b6082654ee96792fbfb
|
|
BLAKE2b-256 checksum How to use checksums |
57a57469efa96d464d16fec22e9588a26b8f8f8a4638a2230130af0012ffb70c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 20, 2026.
Transparency log