Built for floors where the internet isn't invited.
Air-gapped activation, credentials that never leave the machine, a published port map for your network team, and AI that runs against local models. DVT does its whole job without phoning home.
Three answers, before they're asked.
Nowhere you didn't choose
Federation extracts run engine-to-engine over your network; cross-engine compute happens in-process on the machine running dvt. No SaaS in the data path, no third-party compute, no telemetry riding along.
In profiles.yml, on your disk
Credentials stay in the same file dbt has always used — chmod 600, timestamped backups on every managed write. The Settings UI shows secrets masked, treats them write-only, and its endpoints answer loopback only.
A signed key, verified locally
Paste a machine-bound activation key on the air-gapped server: signature checked locally, bound to that hardware, expiry enforced — no callback. Seats managed from your account when a connected machine exists; keys issued for the ones that never will be.
Every port, every posture, published.
DVT owns one documented range — — far from anything that usually squats on a data engineer's machine. Every app binds by default; exposing one is an explicit decision. Credential and job writes stay loopback-only no matter what.
Reverse-proxy one app inside the VPN, or none. The map is in the product itself — hub → Settings → Hosting — so what your admins read is always the version they run.
| PORT | APP | AUTH POSTURE | STATUS |
|---|---|---|---|
| :46100 | DVT Hub + Settings | settings writes answer loopback only — even with --host | live |
| :46101 | Data Catalog | read-only documentation | live |
| :46102 | API Portal | optional bearer key on /api/v1; management loopback-guarded | live |
| :46104 | Chat with Martin | ask & save answer loopback only; keys never round-trip; offline via Ollama | live |
| :46105 | Data Profiling | profile runs answer loopback only | live |
| :46106 | DVT Scheduler | writes loopback-only; jobs are verb-whitelisted, never a shell | live |
| :46103, 46107–46109 | Builder · Notebooks · Dashboards | same posture, one port each | roadmap |
Hand out endpoints, not credentials.
The API Portal turns any model into a governed REST endpoint: per-endpoint column allow-lists, locked row filters callers can't override (row-level security in one move), identifier quoting from catalog ground truth, and bearer-key enforcement when you want it. Consumers get answers; your databases stay yours.
How the portal governs →AI features that respect the air gap.
DVT's AI features (Chat with Data, Build with AI) take your keys — or skip the cloud entirely: point them at local models via Ollama, or route through AI-Proxy to use the subscriptions you already pay for instead of per-token APIs. Model metadata goes to the model you chose; credentials never do.
About AI-Proxy →One package on your mirror. That's the install guide.
MIRROR IT
dvt-core ships as compiled wheels on PyPI — mirror them to your internal index and pip install from there. Isolated adapter environments build on the machine, from the same mirror.
SIZE IT
Cross-engine compute runs on the machine executing dvt — the hub's Machine tab shows cores and RAM next to that exact warning. Size the box like the warehouse it's replacing for transformation runs.
SCHEDULE IT
The scheduler is honest: jobs fire while the suite runs, under your process supervision — not a hidden daemon. Kill everything, keep the schedule alive with --exclude scheduler, or wire it into your own cron.
Bring the questions your security team will ask anyway.
We'd rather answer them before the pilot than after.