DVT LOGIN, ACTIVATE & STATUS
DVT is free for individuals — the whole product, every engine — and the only thing it asks is that you're signed in. dvt login, dvt status and dvt activate (plus dvt logout) are that entire surface: sign in once, see where you stand, and bind a license to machines that can't stay online.
SIGN IN ONCE — DVT LOGIN
One command, one browser approval, done:
$ dvt login Starting authentication with https://getdvt.net ... Open this URL in your browser to approve the login: https://getdvt.net/auth/cli?session=8f3a1c9e5b247d60f4e8a2c1d5b9370e6a1f4c8d2b5e9073a6c1f8e4d2b7560a Waiting for approval..... ✅ Logged in as amina@fielddata.io Account: amina@fielddata.io Tier: free Status: active Features: transactional_databases, local_files, cloud_buckets, cloud_warehouses
What happened: the CLI asked getdvt.net for a login session, opened the approval page in your browser (it also prints the URL, so a headless box over SSH works — paste the link into any browser where you're signed in), and polled every few seconds until you approved. The session lives for ten minutes; a transient network blip during polling is tolerated, the CLI just keeps waiting. If the session lapses you get one honest line — ❌ Login session expired. Run `dvt login` again. — and nothing is stored.
On approval the CLI receives an API key and stores it in DVT's machine store — ~/.dvt/home.db, permissions locked to your user — never a loose YAML file in your home directory. Running dvt login while already signed in is a no-op that tells you who you are:
$ dvt login Already logged in (as amina@fielddata.io). Use `dvt login --force` to re-authenticate.
IN PLAIN DBT
There is no login — the open-source CLI never asks who you are, and accounts are a hosted-platform concept that lives outside it. DVT asks exactly once, because sign-in is the price: the whole product is free for individuals, and one dvt login on a machine is the entire ceremony.
WHAT SIGN-IN GATES — AND WHAT IT NEVER TOUCHES
Signed out, a working verb doesn't half-run or degrade — it tells you the deal plainly and stops:
$ dvt debug ❌ DVT is free for individuals — it just needs you signed in. One time: dvt login (or hub → Settings → Account → LOG IN) Air-gapped server? Enterprise offline activation: https://getdvt.net/enterprise
The exemptions are deliberate: dvt init, dvt serve, dvt kill and the account verbs themselves never require sign-in — a fresh or broken machine can always scaffold a project, open the suite, stop it, and sign in. And help is never gated: dvt <command> --help answers on any machine, in any state.
WHERE YOU STAND — DVT STATUS
dvt status is the read-only mirror. Signed out, it says so and points at the fix:
$ dvt status Machine fingerprint: 3e91c07a5d2f48b6a1c9e05372d8f4b1 Not logged in — running DVT Community Edition. Run `dvt login` to connect your DVT account.
Signed in, it checks your key against the license service and prints the account block — the same one dvt login printed:
$ dvt status Machine fingerprint: 3e91c07a5d2f48b6a1c9e05372d8f4b1 Account: amina@fielddata.io Tier: free Status: active Features: transactional_databases, local_files, cloud_buckets, cloud_warehouses
The machine fingerprint prints every time: a stable hash over the hardware identity and hostname, truncated to 32 characters. No raw identifier ever leaves the box — the hash is the whole story, and it's what offline licenses bind to (below). The only tiers are free (individuals — everything included) and enterprise (team deployment, licensed by assessment), and the features list is the full surface for both.
dvt statusis also honest about the network. If the license service can't be reached it doesn't pretend you're signed out — it says the check failed and falls back to what it knows: Logged in as amina@fielddata.io (cached).And if your stored key has been revoked, that's a hard line, not a shrug: ❌ Stored API key is invalid or revoked. Run `dvt login`. When a machine holds an offline license, status leads with it:
$ dvt status 🔓 Offline license: plan enterprise · valid until 2027-08-03 · machine-bound Machine fingerprint: 3e91c07a5d2f48b6a1c9e05372d8f4b1 Account: ops@northwind.dev Tier: enterprise Status: active Features: transactional_databases, local_files, cloud_buckets, cloud_warehouses
DVT ACTIVATE — A LICENSE THAT WORKS OFFLINE
dvt activate re-validates your plan with the server and then binds a signed, machine-bound offline licenseto the machine you ran it on. It exists for machines that can't stay online — the air-gapped enterprise server being the archetype:
$ dvt activate --months 12 ✅ Subscription active — tier: enterprise Account: ops@northwind.dev Tier: enterprise Status: active Features: transactional_databases, local_files, cloud_buckets, cloud_warehouses 🔓 Offline license bound to this machine — plan enterprise, valid until 2027-08-03 (seat 1/3). DVT now verifies your plan locally; no network needed.
The token is signed by the server and bound to this machine's fingerprint — the CLI verifies the signature locally before saving it, and refuses a token it cannot verify. From then on, plan verification happens on the box: no phone-home, no network dependency, valid until the expiry you chose with --months (one to twelve; out-of-range values are clamped).
Seats are counted per account: up to three active machines, where re-activating the same machine extends its existing seat rather than consuming a new one, and expired or revoked activations free theirs. At the limit, activation refuses and names the fix:
$ dvt activate ⚠️ seat limit reached (3) — deactivate a machine at https://www.getdvt.net/dashboard/activations
Two more honest edges. A subscription that exists but isn't active is reported as exactly that — ⚠️ Subscription found (tier: enterprise) but status is 'suspended'. — with a pointer to your subscription dashboard. And if the server becomes unreachable after the plan re-validated, the offline binding is skipped with a warning rather than failing the command: the online half of the activation stood, and you can re-run for the offline half when the network is back.
DVT LOGOUT — REMOVE THE CREDENTIALS
$ dvt logout ✅ Logged out — credentials removed.
Removes the stored API key from the machine store (running it while signed out just says Not logged in.). An offline license already bound to the machine is not deleted — it's machine-bound and expires on its own schedule.
REFERENCE — EVERY FLAG
| COMMAND | FLAG | DEFAULT | WHAT IT DOES |
|---|---|---|---|
| dvt login | --force | off | Re-authenticate even if already logged in. Without it, a signed-in dvt login is a no-op that tells you who you are. |
| dvt activate | --months | 1 | Offline license validity in months (1-12; out-of-range values are clamped). Re-activating the same machine extends its existing seat rather than consuming a new one. |
| dvt status | — | — | No flags. Prints the machine fingerprint, the offline license if one is bound, and the account block (or the signed-out guidance). |
| dvt logout | — | — | No flags. Removes the stored credentials from the machine store; a bound offline license is left to expire on its own. |
Exit codes: dvt login returns 0 on success (or when already logged in) and 1 when the auth service is unreachable, the session expires, or the login times out. dvt status returns 0 signed in, signed out, or on the cached fallback, and 1 when the stored key is invalid or revoked. dvt activate returns 0 once the plan re-validates — even when the offline binding was skipped because the server became unreachable — and 1when not logged in, the key is revoked, the subscription isn't active, or the seat limit is reached. dvt logout always returns 0.