Glyf is an open source, code-first build step for defining, testing, and shipping charts from your dbt models: as dashboards you host, or drawn live inside your own product.
curl -fsSL https://glyfdata.com/install.sh | shmacOS and Linux. Other ways to install are in the installation guide.
Glyf buildValidate · render · exporthow it works
Glyf keeps authoring close to the project: charts as SQL plus a chart block in the ggsql format, dashboard composition in YAML, reusable logic in Python, and outputs from the CLI.
The query you already know, then a few lines saying what to draw. .ggsql files, the ggsql format with Glyf's chart types, and ref() to reach dbt models.
SELECT plan, sum(sessions)
FROM {{ ref('fct_usage') }}
GROUP BY 1
VISUALISE plan AS x
DRAW pie
LABEL title => 'Sessions by Plan'Lay out charts into sections. Use Python macros for conditional logic, thresholds, and reusable components.
sections:
- title: Activation
items:
- component:
{{ activation_health(0.82) }}
- chart: sessions_by_plan
- chart: active_usersGlyf resolves dbt artifacts, validates chart specs, renders charts, and emits the files you can publish.
$ glyf build
✓ Resolved 6 ref() calls
✓ Compiled 8 charts
✓ Built product.html
✓ Wrote chart assets
✓ Build complete in 2.1sfeatures
Glyf turns visualization into a build step engineers can validate, review, and ship with the rest of the data pipeline. Charts and dashboards stay inside the engineering workflow instead of drifting into disconnected BI tools.
Charts reference models with ref(), the way dbt models reference each other, and every reference is checked at build time. No copied SQL and no schema drift.
-- reference dbt models directly in chart SQL
SELECT
date_trunc('week', o.created_at) AS week,
sum(o.revenue_usd) AS revenue,
p.plan_name
FROM {{ ref('orders') }} o
JOIN {{ ref('plans') }} p
ON o.plan_id = p.id
GROUP BY 1, 3
────────────────────────────
✓ resolved orders → analytics.orders
✓ resolved plans → analytics.plans
✓ query valid — 0 errorsUse {{ ref('model') }} in chart SQL exactly as you would in a dbt model. Glyf resolves each reference to its schema path and validates the query before publish.
$ git diff main..feat/q3-charts
charts/revenue_weekly.ggsql- GROUP BY date_trunc('week', created_at)+ GROUP BY date_trunc('month', created_at)
dashboards/growth.yaml+ - id: new_mrr_cohort+ sql: ./new_mrr_cohort.sql2 files changed, 3 insertions(+), 1 deletion(-)
✓ glyf build passed — 14 charts
Ready to merge.Chart definitions, layouts, and macros live in Git alongside your dbt project. Reviewers see exact SQL and YAML diffs, not just screenshots.
glyf mcp serves a project to an agent over the Model Context Protocol: the charts, what each one draws, which charts a model or column change reaches, and whether an edit still validates. It never runs a build and never fetches rows.
Six tools built on the CLI's own functions: list charts and dashboards, read a chart's spec, impact for a model or column, validate with a LIMIT 0 dry run, and diff between two builds. An agent can name every downstream chart in the pull request it opens.
Describe a chart change in plain language. Glyf will translate it to a SQL diff, validate the build, attach the visual diff, and open a pull request.
No BI server to maintain. Glyf builds self-contained artifacts that teams can host in docs, apps, CI pipelines, or static storage.
$ glyf build --target prod
Building 12 charts...
✓ revenue_weekly
✓ signups_by_plan
✓ churn_cohort
... 9 more
Exporting static assets...
✓ dist/revenue_weekly.html 42kb
✓ dist/signups_by_plan.html 38kb
✓ dist/index.html 8kb
✓ dist/charts.zip 180kb
No server required.
Drop into S3, Notion, GitHub Pages, or CI artifacts.Each glyf build produces self-contained HTML files with data and rendering logic inlined. Drop them into any static host and they just work.
import { GlyfChart, GlyfFilters, GlyfProvider } from '@glyf-data/react'
export function Analytics() {
return (
<GlyfProvider bundleUrl="/glyf/bundle.json" theme="dark">
<GlyfFilters dashboard="insights" />
<GlyfChart name="spend_by_model" />
</GlyfProvider>
)
}
✓ npm install @glyf-data/react · live charts · no BI SDK@glyf-data/react draws the charts from the bundle.json every build writes, live in your own app: tooltips, your theme, the dashboard's filters. On npm. No BI SDK and no server.
Thresholds, color mappings, and conditional labels all live in Python macros and YAML specs. Reusable, testable, and visible in code review.
from glyf import macro, ChartContext
@macro
def plan_color(ctx: ChartContext, plan: str) -> str:
return {
"starter": "#94a3b8",
"growth": "#6366f1",
"enterprise": "#0ea5e9",
}.get(plan, "#e2e8f0")
@macro
def alert_threshold(ctx: ChartContext) -> float:
return ctx.config["alert_pct"]
{{ plan_color('growth') }} -- → "#6366f1"Define reusable chart logic like color mappings, thresholds, and conditional labels as Python functions that are typed, tested, and reviewed.
title: Growth Overview
layout: 2col
charts:
- id: revenue_weekly
sql: ./revenue_weekly.sql
title: Weekly Revenue
color_macro: plan_color
- id: churn_cohort
sql: ./churn_cohort.sql
visible_if: "user.plan == \'enterprise\'"
✓ dashboard spec validated — 3 chartsDefine layout, chart ordering, visibility conditions, and macro bindings declaratively in YAML. Changing a dashboard becomes a one-line diff.
A change to a model or a chart can move a number on a dashboard without touching any file a reviewer would open. Glyf compares every chart in a pull request with the base branch and reports which changed, how much of each picture moved, and why.
$ git diff main -- models/fct_finance.sql
from {{ source('raw', 'finance') }}
+where department != 'Partners'
group by 1, 2
$ glyf diff --baseline ../base
~ bookings_trend: 6.1% of the picture moved (the rows changed)
points: 12 lower
sum of bookings 1,079,700 → 974,000 (-9.8%)
~ expenses_by_department: 50.8% of the picture moved (the rows changed)
bars: 12 gone (Partners)
rows 48 → 36
gone from department: Partners
sum of expenses 576,000 → 527,500 (-8.4%)
~ gross_margin_trend: 7.4% of the picture moved (the rows changed)
points: 12 lower
sum of gross_margin 503,700 → 446,500 (-11.4%)
~ margin_rate_by_department: 35.0% of the picture moved (the rows changed)
rows 48 → 36
gone from department: Partners
~ margin_share: 31.3% of the picture moved (the rows changed)
rows 4 → 3
gone from department: Partners
sum of gross_margin 503,700 → 446,500 (-11.4%)
~ margin_vs_expenses: 0.9% of the picture moved (the rows changed)
rows 48 → 36
gone from department: Partners
✓ 6 changed, 2 unchanged
✓ wrote target/glyf/diff/index.htmlFirst in the chart's terms: bars gone, points higher or lower, and which series. Then the rows: a missing category, a column total, the row count. Then why: the query changed, the rows changed, or only the chart definition did. The same data renders to the same bytes, so an unchanged chart is never reported.
Every changed chart is drawn three times: as it was, as it is, and as it is over its old self, the baseline in grey behind the new marks and every category that moved boxed. A series that disappeared stays in the legend with nothing under it. One workflow file puts a summary on the pull request and the full report in its artifacts.
A published dashboard is a file anyone with the link can read. Glyf treats what that file contains as part of the build: which rows it holds, which columns count as personal data, and what happens when a chart reaches for one. Every rule is in glyf.yml, reviewed like the rest.
# glyf.yml
privacy:
pii_columns: [customer_email]
on_pii: deny
$ glyf build
✓ validated project
Render failed - visualisations/overdue_invoices.ggsql returns a PII column: 'customer_email'. Drop it from the query, or set privacy.on_pii: redact to publish it masked.# with on_pii: redact, the build passes and the rows carry
# {"customer_email": "I***", "amount": 16391.88, "days_to_pay": 102}Columns tagged pii in your dbt schema, or listed in glyf.yml, are known to every build. A query that returns one fails the build naming the chart and the column, or, with on_pii: redact, publishes it masked. A value scan warns about the columns nobody tagged that look like emails, phone or card numbers.
# one 8-chart dashboard, exported three ways
export.row_data: include finance.html 106 KB
every row behind every chart, for interaction
export.row_data: minimal finance.html 105 KB
only the columns each chart draws; bookings and
gross_margin were selected, not plotted: gone
export.row_data: exclude finance.html 26 KB
rendered images only. No rows, no specs, no SQL.
# bundle.json records it, every build
"security": { "row_data": "excluded" }export.row_data sets what a published site carries. include keeps the rows behind each chart for interactive use. minimal keeps only the columns a chart draws, so a query that selects more than it plots does not publish the rest. exclude ships rendered images and nothing else. bundle.json records which one the build used, so a reviewer can check.
Roadmap
View roadmapAlert conditions declared in dashboard YAML, evaluated against query results at build time and routed by severity.
Discuss on GitHubDescribe the chart or workflow you need. Feature requests land on the public roadmap, where anyone can add a 👍.
who it's for
You know SQL. You version-control everything. You should not need LookML or a BI platform UI to publish a declared dashboard artifact.
Write SQL-style chart definitions that run in the pipeline, stay current, and live beside the models they query.
Glyf is open source, runs locally, and produces outputs your team already knows how to deploy and review.
The data team owns the spec. You fetch bundle.json and show the SVG or PNG it points to, without an embedded analytics vendor.