vs a .env file

Almost nobody switches to Cendarum from another secrets manager. They switch from a .env file, so this is the comparison that matters.

What a .env file does better

Genuinely, and it is not a short list:

• Zero setup. It is a text file. There is no account, no install, no onboarding.
• Zero dependencies. Nothing to be down, nothing to break your build at 2am.
• Works offline, completely. No network, ever.
• No trust in anyone. Not even us. That is a real security property and we cannot match it.
• No password to type. No unlock step in your workflow.
• No recovery story to take seriously. You cannot be locked out of a text file.

If you work alone on a hobby project, a .env in a gitignored file is a perfectly reasonable answer and you do not need this product. That’s not modesty, it’s the correct recommendation.

Where it breaks

Not on day one. On day forty, when:

• It has multiplied. Six machines, six slightly different copies, nobody knows which is canonical.
• It travelled through a chat message. A new hire needed credentials today, so they arrived in Slack. That message is permanent, searchable, and backed up.
• It got committed. Someone ran git add -A from the wrong directory. Now it is in history, and history is on GitHub.
• You cannot rotate. Someone left. You should rotate everything, but you don’t know who had what, so you rotate the one key you remember.
• Nobody knows who read production. There is no answer to that question. There was never anywhere for the answer to be recorded.

None of those are file-format problems. They are the consequence of a secret being a file — copyable, mailable, committable, and unauditable by construction.

Side by side

	.env file	Cendarum
Setup	none	account, install, master password
Offline	fully	unlock only; reading needs the network
In your repo	one mistake away	never
Sharing	copy and paste	grant per environment
Revoking	ask nicely	revoke, then rotate
Who read production	unanswerable	a log entry
Concurrent edits	last save wins, silently	3-way merge, asks you
Trust in a third party	none	our server holds ciphertext
Lock-out risk	none	real — see recovery

What you give up

Stated plainly, because it is the honest half:

A server dependency for reading secrets. Nothing decrypted is cached on disk, so pulling an environment needs the network. A .env never needs anything. See what works offline.

A master password to type. cendarum run prompts. That is friction a file does not have.

A recovery story you must take seriously. Lose both factors and your data is gone. A text file cannot do that to you.

Trust in us, for now. You are trusting that the architecture is what these pages say. Until the client source is public, that trust is not independently verifiable — which is why publishing it is on the roadmap and why we would rather say this than imply otherwise.

The bridge, not the cliff

You do not have to choose all at once. cendarum import reads your existing .env, cendarum export writes one back out if you need to leave, and cendarum run supplies values the same way your framework already expects.

The migration is one command and the exit is one command. That is deliberate: a secrets manager you cannot leave is its own kind of risk.