The questions we get before you trust us.
Most of them are about what we can see. The short answer is nothing — here is the long one.
No. Your password is turned into a key on your own device using Argon2id, and the password itself is never sent to us. Values are encrypted before they leave, so what reaches our servers is ciphertext we hold no key for. This isn't a policy we promise to keep — it's the shape of the system. We couldn't hand over your secrets if we were asked to, because we don't have them.
Not from your repository, because there is nothing there to read. 'bippass run -- npm start' decrypts in your terminal and passes values straight into the process environment, so no .env file is written — an assistant that indexes your working directory finds no plaintext, and there is nothing to accidentally paste into a prompt, a bug report, or a commit. 'bippass scan' and the pre-commit hook catch hardcoded secrets before they reach git, including ones an agent added while fixing something else. Being precise about the limit: this protects what an assistant reads, not what it can execute. An agent with a shell on your machine, running as you, can run 'bippass run' exactly as you can, and a process can read its own environment. If you let something run arbitrary commands with your session unlocked, it has your access — that is true of every secrets manager, ours included. What we remove is the standing plaintext file that survives on disk whether anything is running or not.
Ciphertext, and the metadata needed to organise it: which project and environment a secret belongs to, its key name, who changed it and when. Key names and structure are not encrypted — we can see that a secret called DATABASE_URL exists, and never what it says.
Every project has its own key, and that project key is sealed individually to each member's public key. When you add someone to a project, a copy of the project key is created that only they can open — nobody has to share a password, and no plaintext key ever passes through us.
Because a password alone should not be enough. A new device announces itself and waits for approval; until that happens the sign-in does not complete and no session is issued. Someone who has only your password, on a machine you have never used, gets nowhere.
Yes. Every reveal, change and rollback is written to an append-only audit log with the actor and timestamp. How far back it goes depends on your plan — 7 days on Free, 90 on Basic, 365 on Professional.
You use your recovery key. Because your password is what encrypts your data, we cannot reset it for you the way an ordinary service would — there is no copy of it here to reset. The recovery key is generated in your browser when you sign up and wraps your private key independently, so it can let you back in without us ever being able to.
Then your secrets are gone, permanently, and there is nothing we can do about it. That is the honest cost of us not holding your keys. It is the one thing in this product that cannot be undone later, which is why setting up a recovery key is part of signing up rather than a setting you might find eventually.
Yes. Changing it re-wraps your private key with a key derived from the new password. Your secrets are never re-encrypted and never decrypted on our side — only the wrapper around your key changes.
Single sign-on is available on the Professional plan.
A workspace is your team. A project is one codebase or service. An environment is a copy of that project's secrets for a particular deployment — development, staging, production. A secret lives in exactly one environment of one project, which is why a new project needs an environment before it can hold anything.
Yes, on Basic and above. Someone asks for access to what they need, an approver decides, and both the request and the decision land in the audit log. It replaces the pattern where a developer pastes a production key into chat because asking was too slow.
One project with up to 10 secrets, one environment, and 7 days of audit history — it is a single-person tier, so there is no one to add but you. The encryption is exactly the same as on the paid plans: paying moves the limits, never the security model.
The action that would cross the limit is refused and we tell you which limit you reached. Nothing already stored is deleted, hidden, or held hostage — you keep full access to what's yours.
No. The free plan needs no payment details.
Didn't find it?
If the answer isn't here, ask us. A real engineer reads support@bippass.dev — and if you've found something that looks like a security issue, security@bippass.dev goes straight to the people who can fix it.