vaultterm --self-hosted --air-gapped
Run it on your own infrastructure.
VaultTerm self-hosts as a single Docker Compose unit — even fully air-gapped. Your secrets, sessions and AI stay inside your perimeter, with the same audited-broker model as the hosted product.
- One Compose unit, no Kubernetes
- Air-gapped install supported
- Bring-your-own Vault / HSM keys
- Offline license, no phone-home
why --self-host
Everything inside your perimeter
For teams whose data, compliance or air-gap rules mean VaultTerm has to run where they run.
One unit, not a cluster
VaultTerm is a modular monolith — a single Node process plus Postgres and Redis. The supported unit is Docker Compose: no Kubernetes, no service mesh, no per-service charts to operate.
Runs entirely on your network
Tenant data, sessions and brokered SSH stay inside your perimeter. The same image runs in a cloud VM or on hardware in your own rack — only the .env changes.
Air-gapped supported
Build a self-contained bundle on a connected machine, carry one tarball across, and run it on a disconnected host. The license verifies offline — nothing has to phone home.
AI stays on the LAN
Point assistance at a self-hosted Ollama model on your own network. Terminal output never leaves the LAN; the cloud fallback is opt-in, per-organisation and redaction-gated.
Your keys, your HSM
Seal the envelope-encryption master key under your own HashiCorp Vault Transit key — itself HSM- or auto-unseal-backed — so the master is unsealed only in memory at boot.
The same audited broker
Self-hosting changes where VaultTerm runs, not what it is. Envelope encryption, no plaintext at rest, just-in-time access and the tamper-evident audit trail are identical to the hosted product.
deploy --steps
From tarball to running broker
A connected install is four steps; an air-gapped one transfers a single bundle and runs the same way.
Bring up the stack
Copy the template, set your secrets and public URL, and start the stack. The container applies database migrations on every boot, so an upgrade is just a new image.
- docker compose up — app, Postgres and Redis in one unit
- Migrations run idempotently on boot; no separate step
- Verify with a single curl to /health
Terminate TLS in front
Put a reverse proxy in front of the app port to terminate TLS — WebAuthn and secure cookies require HTTPS.
- Ready nginx sample with post-quantum hybrid key exchange
- Tenant app on :4000, proxied publicly
- Admin plane on :4100 binds to loopback — kept off the internet
Install your license
Entitlements — tier, seats, term — come from a signed offline .vtlic file, verified locally against a vendor public key.
- Drop the file in, or paste a renewal in the admin console
- No restart: signature and counter re-verified, then hot-reloaded
- Fully air-gap-friendly — there is no phone-home
Bind, back up, recover
Make the license cryptographically load-bearing, then provision a recovery posture so the legitimate owner can always get back in.
- Bind the master to license + host so a clone can't decrypt
- Choose customer-only or managed escrow at provisioning
- 2-of-3 Shamir-split recovery key you control
protection --honest
How self-hosted licensing works — and what it doesn't do
Shipping software to run on someone else's hardware is a hard problem, and we're straight about how we approach it.
License-bound encryption, not a removable check
On-prem protection lives in cryptographic necessity, not an if-licensed branch an attacker could strip. With key-binding on, the master key is sealed under an unlock derived from the license signature, a hardware root and the host fingerprint — a cloned or forged instance boots but cannot open the vault, because it simply derives the wrong unlock.
Recovery you control
Because the key is bound to its host, we seal the master a second, host-independent way and 2-of-3 Shamir-split the recovery key. Customer-only mode means the vendor holds nothing and mathematically cannot read your vault; managed escrow keeps one break-glass share with us if you want a safety net. It's a choice you make at provisioning, not a default we made for you.
Honest about phoning home
An air-gapped install never contacts us — the license verifies offline. The optional connected heartbeat that helps us spot license over-deployment is off by default and only runs if you set its endpoint. It carries a signed per-install identifier, never your data, and we document exactly what each signal is.
Local integrity evidence
Decoy credentials and a tamper-evident, license-rooted audit chain run on your box, for your own assurance. They report nowhere; they let you prove the audit trail hasn't been edited, and raise an event locally if it has.
docs --guides
Self-hosting guides
Step-by-step documentation for deploying, air-gapping and protecting an on-premise install.
-
Self-hosting overview
The single Docker Compose unit, what runs where, and how the pieces fit.
Read guide -
Install with Docker Compose
A connected install end to end: env, TLS, health checks.
Read guide -
Air-gapped install
Build a bundle, carry one tarball across, run it offline.
Read guide -
Licensing & activation
Signed offline licenses, anti-rollback, and installing a renewal.
Read guide -
Backups & recovery
Master-key binding, recovery escrow, and what you must back up.
Read guide
Frequently asked
Do I need Kubernetes?
No. VaultTerm is a modular monolith, so the supported self-hosted unit is Docker Compose — one app container plus Postgres and Redis. There are no separate services to orchestrate.
Can it run with no internet at all?
Yes. You build an offline bundle on a connected machine, transfer one tarball, and run it on the air-gapped host. The license verifies locally and AI runs on your LAN, so a fully isolated install is a first-class case, not a workaround.
What happens when the license expires?
It degrades through a shared grace window to free-tier limits rather than going hard-down, so a late renewal in a slow-moving environment doesn't take production offline. A missing, forged or rolled-back license is refused at boot under production.
Who can read the vault if we use managed escrow?
Nobody, on one share alone. Managed escrow keeps a single break-glass share with us — never enough to read a vault by itself. Recovery always needs two of the three shares. In customer-only mode we hold nothing at all.
How do upgrades work?
Pull the new image (or transfer a new bundle for air-gapped), bring the stack up, and migrations apply on boot. They're forward-only, so take a database backup first — that backup is also your rollback path.
Need it on your own hardware?
On-prem and air-gapped deployments, licensing and bring-your-own-key options are arranged with our team.