FAQ

What will it cost?

Free for one person, forever. $8 per user per month for a team, from the second person. Every security feature — audit log, rotation, the key ceremony, both recovery paths — is in both tiers. See pricing.

But you cannot pay us yet. Billing is not built (roadmap item 8, not started), so early access is free and unbilled, and nothing will start charging you without an email first.

We publish the number now so it is not a surprise later, not because there is a checkout behind it.

Why is it cheaper than Doppler or Infisical?

Because it does less, deliberately. Those are platform products: CI injection, dynamic secrets, dozens of integrations, SOC 2. All of that needs a service that can read your values, and this one structurally cannot. Charging platform prices for a tool that does no CI would be indefensible — see what $8 doesn’t buy.

Why not price per secret?

Because we can’t count them. The number of entries is inside the ciphertext; the server sees a payload’s size, not its contents. Counting would mean either reading them, which the architecture forbids, or trusting a number your own client reported. So the meter is people, which is the one thing we can count honestly — and it happens to be what the value actually tracks.

Is it open source?

The licence is chosen — MIT or Apache-2.0, at your option — and the licence files are in the repository. The repository is not public yet.

Publishing the client is on the roadmap, and the reason it matters is specific: it is the only way to verify the zero-knowledge claim instead of taking our word for it. Until then, the security section is what we can offer — written precisely enough that it can be checked against the code later, which is the point.

We are not going to describe the product as open source before that is true.

Can I use it in CI?

No, deliberately. See when not to use Cendarum.

cendarum run assumes a human types a master password. A runner has nobody. Doing it properly needs a machine identity — a service-account key pair granted access like any other member, with its key delivered out of band — which is a load-bearing change to the key hierarchy rather than a flag, and it is tracked separately.

The wrong version of this feature is easy: put the password in an environment variable, or let the server decrypt. Both discard the property the product exists for.

Has it been audited?

No. No third-party cryptographic audit, no SOC 2. Both are on the roadmap and neither has started.

What exists instead: every construction is frozen, versioned, and pinned by a named test vector, cross-validated against libsodium and the relevant RFCs rather than against ourselves. That is not a substitute for an audit and we are not presenting it as one.

Can I self-host the server?

Not supported and not planned for now.

Worth noting what you would be trusting the hosted server with: ciphertext, wrapped keys, public keys, and metadata. It cannot decrypt any of it. That is a smaller ask than most services make — but it is still an ask.

Is there a mobile app? A browser extension?

No, and neither is planned. Decryption requires your keys, which live on your desktop.

What happens if you shut down?

The honest answer, in order:

1. Run cendarum export for every environment and you have your values as plain files. That command exists partly for this.
2. Your local vault file holds your pins, version markers, and encrypted account keys — but not your secrets, so it is not a backup. Export is the backup.
3. We would give notice before shutting anything down, and the export path is one command.

We would rather tell you the exit exists than pretend the question is rude. A secrets manager you cannot leave is its own risk.

Why do I need two secrets — a password and a Secret Key?

So that a weak password is survivable.

If your keys derived from your password alone, everything stored server-side would be only as strong as that password against an offline attack on a stolen database. The Secret Key is 32 bytes of CSPRNG output generated on your device, never transmitted, so server-side data is unbrute-forceable regardless of what you chose as a password.

You need it when unlocking on a new device. On a device you already use, your password alone is enough.

Why won’t you just email me a password reset?

Because we cannot. A reset requires decrypting your data with a key we hold, and we hold no such key.

That is the same fact that makes a breach of our infrastructure worthless to an attacker. You cannot have one without the other, and we picked the side that protects your secrets at the cost of protecting you from yourself. See what is unrecoverable.

What if I lose my Recovery Kit but remember my password?

You’re fine on this device. Change your master password promptly — that mints a fresh Kit — and write the new one down. Until you do, you cannot unlock on a new device, because that path needs the Secret Key.

Does it work offline?

Unlocking does, with zero server calls. Reading secrets does not: environments are pulled from the server, and nothing decrypted is cached on disk. See what works offline — including why we haven’t added a local cache.

Does it phone home?

No. Zero telemetry, no analytics SDK in the client, and no crash reporter. Not disabled — absent from the dependency manifests.

This website sets no cookies and loads nothing from a third party, including fonts. See telemetry and privacy.

Which platforms?

macOS, Windows, and Linux for the app and the CLI. One real caveat: auto-lock on sleep and screen-lock is macOS-only today. The 15-minute idle timer works everywhere.

When can I try it?

Email us. We are looking for roughly fifteen to twenty developers, and what we mostly want is conversation — whether the project-and-environment model matches how your team actually works, and whether zero-knowledge is worth having fewer integrations.

If you’d try a v0.1.0, that is the profile.