Your first environment

Five steps. The third one is the only one you cannot undo.

1. Create an account

You supply an email and a master password. The email is how teammates address invitations to you, and it is metadata the server sees. The master password never leaves your machine — not hashed, not encrypted, not at all.

Your device then generates a Secret Key: 32 random bytes from the operating system’s CSPRNG. Your master password alone is not what unlocks your vault; the password and the Secret Key are combined through Argon2id to derive the key that does. That is what makes a weak password survivable — server-side data is unbrute-forceable without a factor the server has never seen.

2. Write down your Recovery Kit

You are shown two codes, once:

• Secret Key (SK1-…) — needed alongside your password on any new device.
• Recovery Key (RK1-…) — decrypts a backup of your account keys if you forget your password.

Both are Crockford Base32 with a checksum, so a mistyped character is caught locally before the 64 MiB key derivation runs rather than after.

This is the step with no undo

Lose your master password and your Recovery Kit and your data is unrecoverable. Not “contact support” unrecoverable — mathematically gone. We cannot reset what we cannot read.

Setup makes you acknowledge this before it lets you continue. That gate is deliberate friction.

Print it, or put it in a password manager, or write it on paper in a drawer. Do not put it in the repository whose secrets it protects.

3. Create a project and an environment

A project is usually one codebase. An environment is a set of values within it — conventionally dev, staging, production, but the names are yours.

Creating an environment mints a fresh encryption key for it on your device, wraps that key to your own public key, and writes an encrypted empty payload. All three happen before the environment is usable, which is what lets another device verify later that the key it was handed is genuine.

4. Add a secret

Each entry has a key, a value, an optional note, and a type:

Type	Rendering	Use for
secret	masked	API keys, passwords, tokens
url	masked	connection strings — they usually embed credentials
env	shown	non-sensitive configuration like LOG_LEVEL=debug

The default is secret. Notes are treated as secret material too — revealed on demand, never fetched in bulk.

5. Run your app

cendarum run --env dev -- npm run dev

You will be prompted for your email, master password, and Secret Key. Then the decrypted values go into the child process’s environment through the spawn syscall, and your app starts. Nothing is written to disk.

$ 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

Cendarum prints nothing of its own on a successful run. After the prompts, the terminal belongs to your app.

Prove it worked

Compare these two:

cendarum run --env dev -- sh -c 'echo $DB_PASSWORD'   # prints the value
sh -c 'echo $DB_PASSWORD'                             # prints an empty line

The second one is the point. Nothing leaked into your shell, and nothing was written anywhere.

Next

• Import an existing .env instead of typing values in
• cendarum run in full — precedence, --only, signals, exit codes
• Invite a teammate