Doppler

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a secrets manager that replaces Doppler — and read this first, because it is one of the few places where paying is defensible.

A secrets manager with an unpatched hole hands over everything at once, and a managed instance is patched by somebody whose job it is. What the fee buys beyond that is **sync into every platform you deploy on** — hosting, CI, containers — which is a maintained integration per platform. If you deploy to one place, that is an afternoon. If you deploy to six, consider paying. And for many people the right answer is SOPS with an age key in the repository: no server, nothing to attack.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- Cryptography from libsodium or the platform's own. Never a hand-rolled construction
- A CLI that fetches secrets and injects them into a child process
- Caddy in front, reachable only over a private network or a VPN

THE DATA MODEL
- projects, environments — development, staging, production
- secrets: id, project_id, environment_id, key, value_encrypted, nonce, version, comment, is_deleted, created_by, created_at
- secret_versions: append-only, so a rotation keeps its history and a rollback is possible
- machine_identities: id, name, project_id, environment_ids_json, token_hash, expires_at, ip_allowlist_json, revoked_at
- access_rules: principal, project, environment, path_prefix, permission — default deny
- audit_log: id, actor_kind, actor_id, action, project_id, environment_id, secret_key, ip_hash, at — append-only, enforced by a trigger, and never containing a value
- syncs: id, project_id, environment_id, target_kind, config_encrypted, last_synced_at, last_error

ENCRYPTION
- Authenticated encryption with a fresh nonce per record
- Envelope encryption: a per-project data key, itself encrypted under a master key from the environment or the host's key store — never from the database
- Decryption only when serving an authorised read, never in a background job that logs
- The threat model written out in the README in three sentences: what somebody with the database file gets, what somebody with the machine gets, and what somebody with a leaked token gets. If you cannot write those, the design is not finished

THE CLI, WHICH IS HOW IT IS USED
- `run -- <command>`: fetch, put the values in the child process's environment, execute. Nothing touches the disk
- An encrypted local cache with a short life, so a brief outage does not stop a deploy, and a flag to require freshness
- Export to a dotenv file only behind a deliberate flag and a warning, because that file is the thing you were trying to stop existing
- A diff between environments, which is how the variable missing in production gets found before a customer finds it

SYNC, THE PART THAT IS THE FEE
- One adapter per target: push the current values into a hosting provider's configuration, a CI system's secret store, or a container platform
- Each is an API call, credentials to hold, and a rate limit to respect. Write the one or two you actually deploy to and no more
- Sync is one-way, from here outward, always. A two-way sync means two sources of truth and eventually a silently reverted rotation
- Every sync recorded with its result; a silent failure means a service running on last week's key
- After a sync, the target usually needs a restart to pick up the change. Trigger it or say plainly that it must be done, because a secret rotated and not deployed is worse than one not rotated

ROTATION
- Write the new value as a new version, deploy, confirm, retire the old one. The tool tracks that lifecycle rather than pretending a swap is atomic
- A last-rotated date per secret with an optional maximum age, and a report of what is overdue

LEAK PREVENTION
- Values never in a log, an error, an audit row, or any response that was not an authorised read
- Redaction by value match in every log path, including encoded forms
- A pre-commit hook and a CI check for anything that looks like a secret in the repository

OPERATIONS
- .env for the server: DATABASE_PATH, BASE_URL, MASTER_KEY_SOURCE, SESSION_SECRET, OIDC_*
- Migrations on boot, each once; not exposed to the public internet
- Nightly backup — ciphertext, which makes it safe to store off-site — and a tested restore
- Patch dependencies promptly. Write that in the README as an operational requirement, not a suggestion

WHAT MATTERS MOST
The threat model, the audit log, and where this runs. If you will not keep it patched, use SOPS and a key file instead — it has no server to attack.