CONFIGURATION
Everything you can tell DVT lives in one of three small files: profiles.yml for connections, sources.yml for where raw data lives, and dvt_project.yml for DVT's own project settings. This page is the map — what goes where, with a guide for each.
PROFILES.YML
Every engine and bucket DVT can talk to, each a named output. Targets, environment switches vs engine shifts, and how connections resolve.
SOURCES.YML
Bind every source to its engine with meta.connection — one rule, no exceptions. Common patterns and common mistakes.
LEAST-PRIVILEGE PREREQUISITES
Before the connection works, someone has to grant it. Exactly what DVT needs on every engine, per use case — and what it never asks for.
DVT_PROJECT.YML — DVT'S OWN PROJECT FILE
dvt_project.yml is scaffolded by dvt init, git-tracked, and lives beside dbt_project.yml— which stays byte-pure dbt forever. DVT never reads its own keys from dbt's file: a DVT key found there is a named configuration error telling you the key, where it sits, and its right home — never a silent merge.
The scaffold's keys are meant to stay in the file. dvt config-checkup flags a missing one as an unhealthy project, and dvt config-fix restores it with its explanatory comment, keeping a .bak.
Both files have full reference pages: dvt_project.yml and dbt_project.yml.
# dvt_project.yml — beside dbt_project.yml, one flat key per line # The one port this project's app suite serves on. suite_port: 46100 # Push eligible compute down to the source engine (true) # or compute in DVT's engine (false). federation_direct: true
suite_port
The one port this project's app suite serves on — hub, catalog, api-portal, chat, profiling, scheduler, explorer, dashboards, executions, every app a path on that one origin.
- ▸ Lives in dvt_project.yml and nowhere else — no environment variable, no sticky record, no dynamic allocation. The file is the single source of truth for where this project serves.
- ▸ Default 46100, scaffolded by dvt init. A missing key falls back to that default — and config-checkup flags the project unhealthy until the key is restored, because a silent fallback must never be a project's only record of where it serves.
- ▸ An occupied port is a hard error naming the holder (which project or pid has it). DVT never hops to a free port, never evicts the holder, never picks a port for you — so your api-portal URLs never move. Free the port, or change suite_port.
- ▸ Running several projects side by side? Set a different suite_port in each project's dvt_project.yml. That is the whole story — one deliberate key per project, no magic.
# dvt_project.yml suite_port: 46100 # project A # ../other_project/dvt_project.yml suite_port: 46110 # project B — side by side, no collision
federation_direct
The project-wide compute default for federated models: push eligible work down to the source engine, or compute in DVT's own engine.
- ▸ true — pushdown. Eligible compute runs on the source engine itself, and DVT streams the (smaller) result. This is the default, and the fast path.
- ▸ false — the federation pipeline. Data is streamed out and the compute happens in DVT's engine instead — the lane to pick when a source is too precious or too slow to burden with query work.
- ▸ Resolution order is fixed: a model's own config beats the project value, the project value (dvt_project.yml) beats the built-in default (true). Only an explicit false opts out — anything unset keeps pushdown's speed.
- ▸ The run result line names which level decided, so you always know which file to edit.
# dvt_project.yml — the project-wide default
federation_direct: true
-- models/silver/heavy_join.sql — one model opts out
{{ config(federation_direct=false) }}suite_port matters the moment you run dvt serve — the suite and every app in it live on that one origin. federation_direct's two lanes are explained in full on the pushdown page.