secrets

Secrets · Can change or delete · actions: request, set, delete, list

For reading use secrets_read, which is read-only and needs no approval: "list" here is deprecated (still works). Environment variables with secret values (API keys) per environment. action "request" (names, env, note): a link for the user to paste the values in the portal, one by one or as a .env block; prefer it whenever the user would otherwise paste a key into the chat, so the value never passes through you. "set" (name, value, env; build: true also exposes it to production builds; generate instead of value makes a random one here, e.g. a session secret, so it never passes through you; values are never shown back, so for a key that encrypts stored data use "request" instead: the owner makes the key and keeps a copy, or nothing can decrypt an export), "delete", "list" (names only; values are never shown). Preview sandboxes get preview secrets only, production gets production secrets only. Moving keys, passwords or salts found written in the code (deploy preflight and project_scan list them as secrets_in_code): ask the user once for the whole batch first; after a yes, set the ones marked generatable with generate, and use request for real third-party credentials (payment, API, mail and database passwords), which you never type; then change the code to read them from the environment. Setting one restarts nothing: a preview service gets it when restarted (service restart) or at the next wake, production when its services restart (service restart with environment production), or at its next publish or wake.