Infisical

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 the secrets manager I actually need instead of a hosted Infisical: environment variables per project and stage, injected into a process, with an audit log.

Read this first, and take it seriously. This is the one thing on the list where running it yourself is riskier than paying: a managed instance is patched by somebody whose job it is, and a secrets manager with an unpatched hole hands over everything at once. If you build it, keep it small, keep it off the public internet, and keep it updated. For many people the right answer is SOPS with an age key in the repository — no server at all, and nothing to breach.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- Encryption from libsodium or the platform's own primitives. Never a hand-rolled construction
- A small 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: id, slug, name, created_at
- environments: id, project_id, slug, name, position — development, staging, production
- secrets: id, project_id, environment_id, key, value_encrypted, nonce, version, comment, is_deleted, created_by, created_at
- secret_versions: id, secret_id, value_encrypted, nonce, version, changed_by, at — append-only; a rotated value keeps its history so a rollback is possible
- folders: id, project_id, environment_id, parent_id, name — secrets grouped by path
- machine_identities: id, name, project_id, environment_ids_json, token_hash, expires_at, ip_allowlist_json, revoked_at
- access_rules: id, principal_kind, principal_id, project_id, environment_id, path_prefix, permission
- 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
- approvals: id, project_id, environment_id, change_json, requested_by, status, approved_by, at

ENCRYPTION
- Every value encrypted at rest with authenticated encryption and a random nonce per record
- The master key comes from the environment or, better, from the host's own key store — never from the database, and never checked in
- Envelope encryption: a per-project data key, itself encrypted under the master key, so rotating the master key does not mean re-encrypting everything
- Decryption happens only when a value is served to an authorised principal, and never in a background job that logs
- The threat model written out in the README: what an attacker with the database file gets, what one with the machine gets, and what one with a leaked token gets. If you cannot write those three sentences, the design is not finished

ACCESS
- Human users through single sign-on where possible, with short sessions
- Machine identities with tokens that expire, are scoped to a project and environment, can be restricted by source address, and are revocable instantly
- Default deny, with rules by path prefix so a service reads only its own secrets
- Production is a separate environment with its own rules, and reading a production secret is always audited and optionally requires approval
- No shared accounts, because an audit log full of 'deploy' answers nothing

THE CLI, WHICH IS HOW IT IS ACTUALLY USED
- `run -- <command>`: fetch the secrets, put them in the child process's environment, execute. The values never touch the disk
- A local cache, encrypted, with a short life, so a brief outage of the server does not stop a deploy — and an explicit flag to require freshness
- Export to a dotenv file only with a deliberate flag and a warning, because that file is the thing you were trying to stop existing
- Diff between environments, which is how the missing variable in production gets found before it is found by a customer
- Everything works from CI with a machine token in the runner's own secret store

ROTATION
- A secret has a version; writing a new value keeps the old one
- Rotation is: write the new value, deploy, confirm, retire the old. The tool tracks that lifecycle rather than pretending a swap is atomic
- Dynamic secrets for databases if you want them — issue a short-lived credential on request and revoke it after. This is genuinely useful and genuinely a lot of work; skip it unless it earns its place
- Every secret has a last-rotated date and an optional maximum age, with a report of what is overdue

LEAK PREVENTION
- Values never appear in a log, an error message, an audit row or an HTTP response that was not an authorised read
- The API refuses to return a value in a URL, only in a body
- A pre-commit hook and a CI check scanning for anything that looks like a secret in the repository
- Redaction by value match in every log path

OPERATIONS
- .env for the server itself: DATABASE_PATH, BASE_URL, MASTER_KEY_SOURCE, SESSION_SECRET, OIDC_*
- Migrations on boot, each once
- Not exposed to the public internet. Behind a VPN or an identity-aware proxy, and if that is impossible, behind mutual TLS
- Nightly backup — encrypted values, which is what makes the backup safe to store off-site — and a tested restore
- Update discipline: dependencies watched and patched 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. Write the three sentences about what an attacker gets before writing code, keep it off the public internet, and audit every read. And be honest with yourself about whether you will keep it patched — if the answer is no, use SOPS and a key file, which has no server to attack.

Give me the repository, the CLI, migrations, .env.example, and a README that opens with the threat model and the honest recommendation.