Shared two-factor, self-hosted
The codes your whole team needs, in one place you own
Nobody should have to text a six-digit code at midnight. Put the shared accounts in one vault, give everyone their own login, and keep the encryption key on your own server.
Three layers, one secret
What stands between a QR code and a leak
Each layer does one job, and none of them trusts the layer above it.
Your browser reads the QR
Upload a screenshot and it's decoded locally into issuer, label and secret. Only those parsed fields are sent — the image never leaves the tab.
client-side decodeThe server seals it
Secrets are encrypted with a master key that lives in the environment, not the database. Somebody who walks off with the file gets nothing readable.
AES-256-GCMThe log remembers
Added, edited, deleted, copied, signed in — every action lands in the activity feed with a name against it. Shared access without shared anonymity.
activity logOpen by default. Everyone sees every code, unless you say otherwise.
Shared visibility is the default for shared infrastructure accounts — an admin can still restrict any one entry to specific people when it shouldn't be that wide open.
No round numbers
The specifics, as built
- Code window
- 30 secondssix digits, TOTP
- Secret storage
- AES-256-GCMkey held outside the database
- Password hashing
- argon2idminimum twelve characters
- Login 2FA
- TOTP + recovery codesrequired for every account
- Session cookie
- httpOnly · SameSite=Strictre-checked on every request
- Failed sign-ins
- 5 then locked15 minutes, plus per-IP limiting
- Duplicate rule
- name + issuer + secretall three must match to reject
- Entry visibility
- open by default, admin can restrictadder and admins always keep access
- Bulk import
- Google Authenticator exportone QR, several entries
Two secrets and one command
Generate an encryption key and a session secret, then bring it up. Back the key up somewhere that isn't the same disk as the database.