Self-hosted secrets management for a small team
Self-hosted secrets management for a small team: one-time links encrypted in the browser, so the server holds what it cannot read.
Secrets management for a small team is a category that sounds like it belongs to somebody else. The enterprise version is a vault with policies, rotation and an audit department attached. The version a team of six actually needs is smaller and more urgent: how do I hand this database password to a colleague without leaving it in a chat log forever.
That is the problem this page is about, and it has a clean answer.
Why the chat log is the actual threat
A credential pasted into a messaging tool does not expire. It sits in the history, in the search index, in whatever the company's retention policy keeps, and on the laptop of anybody who has ever been in that channel. Two years later somebody leaves and the password is still there.
The same is true of email, of a shared document, and of a sticky note photographed for convenience. The leak is not the moment of sending; it is the permanence.
What a one-time link changes
Secreta is built on a narrower promise than a vault: a secret becomes a link, the link works once, and then it is gone. The interesting part is where the encryption happens. The secret is encrypted in the sender's browser before anything is transmitted, so what the server holds is ciphertext it has no key for. The product's own phrase for it is that your server cannot read what it stores, and that is a design property rather than a policy promise.
Try the Secreta demo ↗Live, on sample data, no sign-up.
Add a passphrase and the arrangement becomes genuinely two-factor: the link travels one way -- chat, email, whatever is convenient -- and the passphrase travels another, by voice or by a different channel. Neither alone opens it.
What to look for
Encryption in the browser, not on the server. This is the whole difference. If the server can decrypt, then a server compromise is a secrets compromise, and the vendor's promise is the only thing between the two.
Burn after reading, with an expiry as well. A link nobody opens has to die on its own.
A passphrase that the server never sees. Otherwise it is a second field, not a second factor.
An honest statement about what the server can tell you. Secreta warns recipients before revealing a secret because opening a link spends a view even if the passphrase attempt was wrong -- the server genuinely cannot tell whether decryption succeeded, which is the cost of not holding the key.
Team accounts with an audit log, managed in the application, for knowing that a secret was shared without knowing what it was.
No file uploads. Which sounds like a missing feature and is a deliberate one.
The limits, stated plainly
Text secrets only -- there is no file sharing. The reasoning is in the product's own limits: a file carries metadata about whoever made it, and a product whose entire claim is that the server learns nothing has no business storing documents it cannot read but can still leak.
HTTPS is part of the arrangement in production, because the encryption happens in the browser and browsers only expose the cryptography API on a secure origin. A lost passphrase cannot be recovered: there is no reset, because the key never reached the server. And Secreta sends no email at all -- invitations and share links are handed over by you, through whatever channel you choose.
That last one matters for the small team this page is about. There is no notification system to configure and nothing that can accidentally mail a secret to a distribution list.
Questions people ask
Can the server administrator read a stored secret? No. The plaintext never reaches the server: encryption happens in the sender's browser, and the server holds ciphertext without the key.
What if the recipient opens the link and the passphrase fails? The view is spent. The server cannot distinguish a failed decryption from a successful one, so recipients are warned before revealing -- and the secret is sent again rather than recovered.
Is this a password manager? No. It is a way to hand one secret to one person once. A vault for storing credentials long term is a different product with a different shape, and this deliberately is not it.
Where to look next
The product page is Secreta, with the whole feature record and its limits in the product's own words. The alternatives page covers the sharing feature people usually arrive from, another covers a second, and the side-by-side sets them next to each other. For what the hosted password platforms charge per user per month -- which is the comparison most teams are really making when they only wanted the sharing half -- read the observatory: each figure is quoted verbatim beside the date it was read and a link to the page it came from. Prices are on the observatory; read them on the date shown there.