When not to use Cendarum

If any of these describes your situation, Cendarum is the wrong choice today. Not “with some workarounds” — the wrong choice. Better you learn that here than three weeks in.

You need CI/CD secret injection

This is the most common disqualifier by a wide margin.

cendarum run assumes a human is present to type a master password. A build runner has nobody. Supporting it properly requires a machine identity — a service-account key pair, granted access like any other member, with its private key delivered to the runner out of band — and that is a load-bearing change to the key hierarchy, not a flag.

Doing it badly is easy and we are not going to: any scheme where a runner can decrypt without a human either puts a decryptable key on our server or puts a master password in an environment variable, and both discard the property the product exists for.

If your secrets need to reach a pipeline, use something built for that.

You need compliance paperwork

No SOC 2. No ISO 27001. No third-party audit. No penetration-test report. No DPA template, no security questionnaire on file.

If procurement needs artefacts, we have none, and “the architecture is better” is not an artefact. This is on the roadmap and has not started.

You need dynamic or short-lived cloud credentials

Cendarum stores values you give it. It cannot mint a 15-minute AWS credential, because doing so requires holding credentials to your cloud and being able to use them — which means being able to decrypt.

If short-lived credentials are your model, you want the category that can do it.

You need browser or mobile access

Neither exists. Decryption requires your keys, which are on your desktop. There is no web app to read a secret from someone else’s machine, and no phone app.

You need to self-host

Not supported and not planned for now. You would be trusting our hosted API to store ciphertext — which is a smaller ask than most services make, but it is still an ask, and if your policy is “no third-party storage at all” then it is a no.

You cannot tolerate a real lock-out risk

There is no server-side password reset. Lose your master password and your Recovery Kit and the data is gone — permanently, with no support path.

If the people who would use this cannot be relied on to store a recovery code, that risk is real and it is yours. See what is unrecoverable.

Your team won’t do the fingerprint ceremony

Sharing requires two people to compare a 20-character string out of band, every time a key is wrapped to someone new.

If your team will click through that without reading it, you get the friction and lose the protection — the threat model says so explicitly. A tool whose central safeguard your team will not perform is worse than one that never claimed it.

You need it to run on Windows or Linux and lock on sleep

The app and CLI work on all three platforms. But the sleep and screen-lock hooks are macOS-only today: on Windows and Linux, closing the lid does not lock your vault — the 15-minute idle timer catches it later.

If unattended-machine risk is your primary concern and you are not on macOS, wait.

You need it to be public and audited before you’ll trust it

Reasonable, and currently disqualifying. The client source is not public, so nothing on the security pages is independently verifiable. Publishing it is on the roadmap precisely because you shouldn’t have to take our word for it.

If your bar is “show me the code”, the honest answer is: not yet.

You are one person with one project

Then a .env file in a gitignored path is fine, and you do not need any of this. See vs a .env file.

---

Who it is for

Small teams doing local development, sharing environment variables between real people on real machines, who want per-environment access, revocation that actually revokes, and a server that cannot read their values — and who can live without CI injection, compliance documents, and a mobile app.

That is a narrower group than “everyone who has secrets”. We would rather be right for them than plausible for everyone.