Why we built Docglow
dbt docs serve was built for the analytics engineer who wrote the model. We built Docglow for everyone else who has to use it.
If you run a dbt project past about 200 models, you already know the bit where someone in #analytics-help asks “where does fct_orders come from” for the fourth time this week. You ping them the link to dbt docs serve. They click around for ninety seconds. They come back. They ask you again.
That is the problem we built Docglow to solve.
dbt docs serve, in fairness
dbt docs serve is a remarkable piece of free tooling. It parses your manifest.json and gives you a browsable graph of every model, source, seed, and test in your project. It is exactly the right surface area for the person who already knows the project: an analytics engineer auditing lineage before a refactor, or a DRE confirming that an upstream change does not break a downstream test.
It is also the only documentation tool a lot of data teams have ever had. So when the rest of the company starts asking questions, the analytics engineer hands them the same URL they use themselves and says “it is all in there.”
What dbt docs serve was never trying to be
Search is not friendly. If you’ve ever searched for a model name, but there’s no exact match, the most relevant result often doesn’t show up at all. The default UI is a tree view, which is fine if you can guess the model name and roughly where it sits in the project. It is bad if you are a finance analyst who has heard the phrase “active customers” three times in three different Slack threads and is not sure which model owns the definition.
It is not column-level lineage. You can see that fct_orders depends on stg_orders. You cannot see that the is_active column on dim_customers traces back to a CASE statement six models upstream.
Hosting is your problem to solve. The recommended deployment is “run a Python web server on your laptop.” Teams that want it shared end up wiring it into S3, GitHub Pages, an internal Vercel project, a Streamlit app, or a Notion page someone copy-pastes into every quarter.
It is not multi-tenant or governed. Anyone with the URL sees everything. There is no concept of “this finance model is sensitive” or “this PII column should be redacted from the docs.”
None of those things are bugs. dbt docs serve was never trying to be them. It is a developer tool that ships in a developer CLI.
The other audience
Talk to a dozen data teams and the same picture forms. Engineering wants the lineage graph. Everyone else wants something more like a wiki search bar. They do not care that fct_orders is materialized as an incremental table. They care that there is a column called gross_revenue and they want to know whether it is net of refunds.
The tools that have grown up around this problem are mostly catalogs. Atlan, Collibra, Alation, Castor. They are real products, and at the high end they do real work for real money. They are also a category sale. You do not buy a catalog because three analysts cannot find a column. You buy a catalog because your CDO has signed off on a six-figure data governance initiative and you have a year to roll it out.
There is a gap in the middle. A team running 200 to 2,000 dbt models, where the analytics engineers are tired of being a human search engine and the rest of the company has given up on docs entirely, but where nobody is buying a catalog this quarter.
What we are building
Docglow is a drop-in replacement for dbt docs serve aimed at that gap.
You point it at your manifest.json and catalog.json. You get back a hosted documentation site with full-text search over models, columns, descriptions, and tests, and column-level lineage that traces every transformation back to its source. The UI is built for non-engineers: search-first, link-shareable, with the kind of “explain this column to me like I am new here” hover cards that the catalog vendors charge five figures a year for.
If your team already runs dbt docs serve, switching to Docglow takes about thirty seconds:
$ pip install docglow
$ docglow generate --target-path ./target
✓ Parsed 142 models
✓ Built column lineage
✓ Site ready at ./docglow-site
$ docglow serve
✓ Running at http://localhost:8080We are early. We are talking to teams that fit this shape, and we are shipping fast. If that sounds like you, the waitlist is below.