THE DVT APP SUITE
DVT lives in your terminal — but some things are just nicer on a screen. One command opens a local workbench in your browser, with eight apps waiting behind it.
$ cd my_project $ dvt serve # → http://127.0.0.1:46100 opens with every app on it
That's the whole ceremony. dvt servestarts your project's suite and lands you on the hub; dvt kill shuts it down again. Everything in between is a click.
The apps
Every app is a path on the same origin — one port, one theme, one chrome. Each has its own docs page:
The front door: every app as a card, your account at a glance, and the way into Settings.
Read the docs →
The control plane: every connection in profiles.yml managed without writing YAML, your machine, and the one AI credential.
Read the docs →
The database room: browse any connection live, run SELECTs on the engine itself, edit rows through a grid that shows you the exact SQL first.
Read the docs →
Ask your project a question in plain language — Martin writes the SQL, DVT guards it and answers live through federation.
Read the docs →
Nulls, distincts, min/max and averages for any table on any connection — computed live, nothing added to your DAG.
Read the docs →
dvt commands on a cron, or saved for manual runs — kill switches, history, and honest per-run feedback.
Read the docs →
Any model becomes a governed REST endpoint — each call runs the model live through federation.
Read the docs →
The assets you save in Chat, arranged on boards — every card reruns live with one click.
Read the docs →
There's a ninth door on the same origin: the Data Catalog at /catalog — cross-engine docs and lineage for everything in your project.
One port per project
The whole suite answers on a single port — 46100 by default, sticky per project, taken from the suite_port key in dvt_project.yml. DVT's reserved range is 46100–46149, so two projects can run their suites side by side — give each its own pin.
The suite binds 127.0.0.1 unless you pass --host — reaching it from another machine is always an explicit decision, never a default.
Starting and stopping
There is exactly one way to serve and one way to kill — no per-app servers to babysit:
dvt serve # start this project's suite, open the hub dvt serve --no-browser # start it quietly, no tab dvt serve --host 0.0.0.0 # bind beyond loopback — an explicit decision dvt kill # stop this project's suite dvt kill --all # stop every project's suite on this machine
dvt kill only ever touches servers. A running dvt build is never signaled — Ctrl+C owns stopping runs — and suspended (Ctrl-Z) suite processes are reaped so nothing lingers. Full flag reference on the dvt serve page.
Security posture — the short version
- loopback by default — the suite origin binds 127.0.0.1; exposing it 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).