THE DVT APP SUITE
DVT is a CLI first — and a workbench when you want one. dvt servestarts every app as its own detached process on DVT's reserved port range (46100–46109), each binding 127.0.0.1 unless you say otherwise. One theme cookie, one chrome, one off switch.
Commands
dvt serve # start the whole suite, open the hub dvt serve -s scheduler # start just one app dvt kill # stop everything (+ reap suspended runs) dvt kill -s api-portal # stop one app dvt kill --exclude scheduler # stop everything EXCEPT one app dvt kill --force # also terminate RUNNING dvt work
The apps — each on its own page
The front door and the control plane: app tiles, the roadmap, and DVT Settings — account, machine, connections, AI keys, hosting.
Read the docs →
Cross-engine docs and lineage — every model, source and column across all your connections, engine-stamped.
Read the docs →
Any model becomes a governed live REST endpoint — executed through federation per request.
Read the docs →
Martin, the DVT data agent: ask in English, he writes governed SQL and DVT answers it live through federation — charts, sessions, saved assets.
Read the docs →
Null bars, distincts, min/max and averages for every model and source — computed live through federation, no package, nothing added to your DAG.
Read the docs →
dvt commands on a cron or saved for manual runs — kill switches, history, honest per-run feedback.
Read the docs →
Security posture — the short version
- loopback by default — every app binds 127.0.0.1; exposing one is an explicit --host decision.
- writes never leave loopback — credential writes, job writes and settings writes answer only on 127.0.0.1 — regardless of --host.
- secrets are write-only — masked in every UI, never echoed back, never logged.
The complete map lives on the enterprise page and inside the product (hub → Settings → Hosting).