Cendarum
Get early access
Zero-knowledge · macOS, Windows, Linux

Your .env,
without the .env.

Cendarum keeps your API keys, credentials, and environment variables encrypted on your device — then injects them straight into your app's process at launch. Nothing on disk. Nothing we can read.

Get early access How it works
zsh
$ cendarum run --env dev -- npm run dev Email: you@example.com Master password: Secret Key (SK1-…): > my-api@0.1.0 dev > vite VITE v7.0.4 ready in 412 ms Local: http://localhost:5173/
That's the whole integration. No SDK, no .env file, nothing written to disk.

the situation

You already have a secrets manager. It's a text file.

And it works, right up until it doesn't.

It multiplies

One .env becomes six copies on six machines, each slightly different, and nobody knows which one is right.

It travels badly

A new hire needs credentials today, so they arrive in a chat message. That message is now permanent, searchable, and backed up.

It can't be rotated

Someone leaves and you should rotate everything — but you don't know who had what, so you rotate the one key you remember.

how it works

Import it once. Run it forever.

Three commands, and the third is the one we'd rather you didn't need.

  1. Bring your .env in

    Comments, quotes, and export prefixes are all tolerated. Two lines setting the same key is an error that names both line numbers — never a silent last-one-wins.

    import
    $ cendarum import --env dev --file .env cendarum: imported 12 keys into dev (version 2)

  2. Give each teammate the environments they need

    Access is granted per environment, not per project, and a new member starts with no access to everything. Grant dev without granting production.

  3. Run your app

    cendarum run puts the values into the child process's environment through the spawn syscall itself. Your ambient PATH and HOME survive; managed keys win over same-named ambient ones. The child's exit code becomes Cendarum's, so run disappears inside scripts and Makefiles.

    For the rare tool that reads only a file and ignores its environment, there's an escape hatch. It warns you every single time, and refuses to write inside a git working tree without --force.

    export
    $ cendarum export --env dev --out .env.local cendarum: WARNING — this writes your secrets in PLAINTEXT, outside Cendarum's zero-knowledge protection. Do not commit the result; delete it when done. Prefer `cendarum run` (no plaintext ever touches disk).

the difference

Most vaults encrypt your secrets — then keep the keys.

Encryption isn't the hard part; everyone encrypts at rest. The question is who holds the keys and who can see the plaintext. For us, the answer is: not us.

A typical cloud vault
  • Encrypts your data at rest — but holds the master keys
  • Decrypts your secrets server-side to process them
  • A breach, insider, or subpoena can expose them
  • "We promise not to look"
Cendarum
  • Encrypts on your device, before anything is sent
  • Keys derive from your master password and a Secret Key that only exists on your device
  • Our servers hold ciphertext, public keys, and metadata — never a value
  • "We can't look" — by architecture, not policy

Where the keys come from

  1. Your master password + your Secret Key never leave the device
  2. Argon2id, in keyed mode 64 MiB · 3 passes
  3. unlocks your key pair stored encrypted, server-side
  4. which unwraps one key per environment wrapped per member
  5. which decrypts that environment's secrets the server only ever sees this, encrypted

Logging in and unlocking are separate operations. An API token proves who you are; it decrypts nothing.

Read the security model

built for how you work

A secrets manager that thinks like a developer.

Not an enterprise IAM platform you need a week to configure. Not a chat message you'll regret.

Projects and environments

Organised the way you already think: dev, staging, production. Production is marked in amber everywhere it matters.

Least privilege, by default

Read, write, or no access — per environment, per person. New members get no access until you grant it. Access is granted, never assumed.

Revoking re-keys

Removing access rotates the environment's key in one atomic operation. What someone already read, they still have — rotation is what stops the next read.

An audit log that answers the real question

Thirty-three recorded actions, including every read of an environment's secrets. "Who pulled production before the leak" is a query, not a guess.

the app

Masked by default. Revealed one row at a time.

Copy a value and it clears from your clipboard in about 20 seconds — the toast tells you so. The vault locks itself after 15 minutes idle, and on macOS when your machine sleeps or the screen locks.

compatibility

There's no integration to write.

Injection happens below every language. Process creation hands the new process an environment block — that's an operating-system concept, not a library — and every runtime reads from the same block.

Node process.env.X
Python os.environ["X"]
Go os.Getenv("X")
Ruby ENV["X"]
Rust std::env::var("X")
Java System.getenv("X")
PHP getenv("X")
shell / Make $X

Child processes inherit the block, so injecting at the top of a process tree — npm, which spawns node, which spawns webpack — flows down for free. Frameworks add naming conventions on top — VITE_, NEXT_PUBLIC_ — and those keep working, because we set exactly the names you chose.

the one people keep asking for

Give an AI agent a real key, not a copy of one.

You want the agent to make a real API call. Paste the key into the chat and the model refuses — correctly, because a credential in a transcript is a credential sent to somebody's server.

zsh
$ cendarum run --env dev --only STRIPE_SECRET_KEY -- claude curl -H "Authorization: Bearer $STRIPE_SECRET_KEY" ^ what the agent writes
The agent references the key by name; your shell resolves it. The value never enters the conversation.

The pattern, and the ways it can still leak

What we don't defend.

Real end-to-end encryption has costs. We'd rather list them than pretend them away.

Lose your master password and your Recovery Kit, and the data is gone.
We can't reset what we can't read. Setup makes you write the Kit down before it lets you continue.
A secret injected into your app is visible to your own user account while that app runs.
ps e, /proc/<pid>/environ. That's inherent to environment injection and true of every tool that does it. It trades "on disk indefinitely" for "in one process, while it runs."
A teammate with write access can lock you out of an environment.
A write grant is already the power to re-key. Every rotation writes an audit row with a name on it — that's the mitigation, and there isn't a cryptographic one. A server that could check would have to be able to read.
We can't read your values, but we see plenty.
Account emails, project and environment names, payload sizes, version counts, and when you read what. Content is opaque; existence and activity are not.
Four rows because this is the summary. The full list — every residual we've named, in the same words we use internally — is on the threat model page.

where this is

v0.1.0. Pre-launch. Here's the real state.

No installer, no audit, no price. You should hear that from us rather than find it out.

Working today

  • The crypto core — constructions frozen, versioned, and pinned by named test vectors
  • The zero-knowledge API, live over Postgres, storing ciphertext only
  • The desktop app — unlock, vault, members, grants, fingerprint ceremonies, recovery, conflict resolution
  • The CLI — run, import, export

Not yet

  • No installer. Nothing is signed or notarised, so there's nothing we'd tell you to run
  • The client source isn't public. Publishing it is on the roadmap — and the whole point of publishing it is that you shouldn't have to believe this page
  • No third-party audit. No SOC 2. Also on the roadmap, and not started
  • No pricing. The team tier isn't designed yet
  • Not for CI. Headless machine identity needs a different branch of the key hierarchy; it's deliberately out of scope for now
  • Sleep-lock is macOS only. The idle timer works everywhere; the Windows and Linux sleep hooks aren't wired up yet

See the roadmap

Your keys. Your environments. Zero knowledge.

The next thing we need is about fifteen developers who'd rather test the real thing than read about it. If your .env situation is bad enough that you'd try a v0.1.0, say hello.

Get early access Read the architecture

No telemetry. No newsletter. Just the build.