Company password manager · self-hosted · end to end
Passwords your company shares. The server keeps only ciphertext.
TessariDB Vault keeps a company’s passwords, keys, notes and small files as records encrypted in each member’s browser, shared with exactly the people, teams and departments named. The server stores and moves ciphertext in TessariDB, and neither it nor the database can read a record.
git clone https://github.com/tessaridb/tessaridb-vault0.0.1
What it keeps from whom
What the server never holds.
Sealed before it leaves the browser
Contents, titles, field names and files are encrypted on the device that writes them, each revision under a key used once.
An unlock password the server never sees
Signing in and unlocking are separate. Argon2id runs in the page, and the unlock password never leaves it.
Writing a row adds no reader
A browser wraps a record key only to a key the company owner's signature chain vouches for, so the server cannot add a reader.
A second layer in the database
Each company's ciphertext is kept in its own TessariDB vault, opened by a key the database never stores.
Shared by structure
A record is shared with a person, a team, a department or the whole company, and a change of team changes who can read it.
Removal at the next request
Taking back a share or removing a member stops them at their next request and marks the keys they held for rotation.
Recovery the member sees
Owners can hand a member's keys back when the unlock password is forgotten, and every reach of those keys is shown to the member.
Every change on the trail
Each admin change and each read of a sealed record is recorded in the same transaction, so an act that cannot be recorded does not happen.
- records
- 11 types · 15 field types · files to 256 MiB
- sign-in
- password + TOTP · OpenID Connect · passkeys
- keys
- X25519 · Ed25519 · AES-256-GCM · Argon2id
- store
- TessariDB 0.39.3 or later
The panel
One page in the server, nothing to install.
The web application is built into the server. Members sign in, unlock with a password the server never sees, and work with records their browser opens.
Layers
Opened in one place only.
A record is sealed in the browser, kept by the server in the company’s own TessariDB vault, and stored by TessariDB encrypted again. Each layer holds its own keys, and none below the browser holds one that opens a record.
The keys at each layer →- the member's browserholds the unlock password, and the keys it unwrapsthe record, opened
- tessaridb-vaultholds the service key file; each company's vault key, derived per requesta sealed revision, its size, its readers
- TessariDBholds the company's vault, encrypted againa vault entry it can open only with a presented key
Limits
What it does not protect against.
Eleven things are outside what TessariDB Vault defends. They are written down with the design, and the first four are below.
All eleven →- An unlocked browser and the device it runs on.
- The code the server delivers.
- Your company's owners and admins.
- Metadata: who shares what with whom, sizes, counts and times.
Status
Version 0.0.1.
TessariDB Vault 0.0.1 runs on TessariDB 0.39.3 or later. The configuration and the HTTP surface may still change before 1.0, so pin the version you run.
cp .env.example .env
docker compose up -d --wait
docker compose run --rm vault enrolment-link
# enrolment token for ops@example.com, valid for one use within 24 hours