Why we encrypt on the client, not the server
Server-side encryption is easier to build and easier to use. We still chose client-side. Here is the threat model that made the decision for us.
Most "encrypted" storage products encrypt on the server. The data arrives in plaintext over TLS, the server encrypts it at rest, and the server holds the key. It is simple, it is fast, and for a lot of data it is completely reasonable.
For a vault whose entire contents are production credentials, it is not enough. Here is why.
Server-side encryption protects against one thing
It protects against theft of the storage medium — someone walks off with a disk or a database backup. That is worth having. But it does not protect against:
- A compromise of the running application, which has the key in memory and the data flowing through it in plaintext.
- A malicious insider with production access.
- A subpoena or legal order compelling the operator to produce plaintext.
- A misconfigured log, error tracker, or debugging session that captures a request body.
- A supply-chain compromise of a server dependency.
In every one of those cases, the plaintext and the key are both on the server, so the plaintext is available.
Client-side encryption removes the server from the trust boundary
If the bytes are already ciphertext when they leave your machine, and the key is derived from a passphrase the server never receives, then none of the scenarios above yield secrets. The server genuinely cannot help an attacker, because it never had the material.
The strongest guarantee you can give a user is one you are technically unable to break yourself.
What it costs
- No passphrase recovery. Covered honestly everywhere we can — the server has nothing to reset.
- Server-side search is limited. We can search names and metadata, not values, because we cannot read values.
- Key management moves to the client. The browser and CLI have to derive, hold, and zero keys carefully. That is real engineering, and it is where we spend effort.
We did not stop there
Client-side encryption is the primary defense, but we still add a second, independent encryption layer on the server so that a database dump alone is inert even before the client layer is considered. That is Defense in depth: the second encryption layer.
Your development environment, available anywhere.
Create a vault, push your first project, and restore it anywhere.