vs cloud secret managers

The category: a hosted service that stores your secrets encrypted at rest and decrypts them server-side to serve them, integrate with things, and inject them into pipelines.

The architectural difference is one sentence. They hold a key that can decrypt your secrets. We do not.

Almost everything else follows from that, in both directions.

What server-side decryption buys them

This is a real list, and it is why the category exists:

CI/CD injection. A build runner with no human present can fetch secrets. This is the big one, and we cannot do it today.
Dynamic secrets. Short-lived cloud credentials minted per request and expired automatically. Requires a service that can talk to your cloud provider on your behalf, which requires it to hold usable credentials.
Automatic rotation integrations. Rotate the database password and update the places that use it.
Breadth of integrations. Dozens of platforms, because a server that can read your values can push them anywhere.
Server-side search, policy, and templating over secret values.
SSO, SCIM, and compliance paperwork. SOC 2 reports, access reviews, the artefacts an enterprise procurement process asks for.
Web access. Read a secret from a browser, on any machine.

If you need any of those, you need that architecture. We are not going to pretend otherwise, and we are not going to claim parity — see when not to use Cendarum.

What it costs them

The same key that enables all of the above is a key that exists:

A breach of their infrastructure can expose plaintext. Encrypted-at-rest does not help when the decryption key is on the same platform.
An insider with production access can read your secrets. Policy and audit logging are the mitigation, and both are policy.
A subpoena can compel plaintext. They can be made to produce it, because they can produce it.
“We promise not to look” is the strongest guarantee available. Usually kept, and structurally unverifiable.

What refusing it costs us

No CI. A headless runner has nobody to type a master password. Supporting it needs a machine identity — a service-account key pair granted access like any other member — which is a load-bearing change to the key hierarchy and deliberately not bolted on.
No dynamic secrets. We cannot mint cloud credentials, because we cannot hold credentials to your cloud.
No server-side anything. No search over values, no templating, no policy engine that inspects a secret.
Fewer integrations. By construction, not by roadmap.
No browser access. Decryption needs your keys, which are on your device.
A real lock-out risk. No server-side reset, ever. See what is unrecoverable.

Where we are honestly weaker

Beyond the architecture: they are mature products with audits, compliance certifications, support contracts, and years of production use. We are v0.1.0, unaudited, pre-launch, with source that is not yet public.

Architecture is not the only thing that matters, and if you are choosing infrastructure for a team that depends on it, maturity is a legitimate reason to pick something else today.

Where the trade favours us

If your actual need is local development — the environment variables your team runs their apps with, on their own machines — most of what server-side decryption buys is unused. You are not asking a vault to mint dynamic credentials for npm run dev.

In that case you are paying the full cost of a decryptable key to gain integrations you do not use. What you want instead is the workflow (cendarum run), per-environment access, real revocation, and a guarantee that does not depend on anyone’s promise.

That is the bet: for local development specifically, zero-knowledge is worth more than breadth. Whether that is true is exactly what early access is for finding out.