Single secrets

Set one secret#

envpilot secrets set                                   # guided: key → masked value → sensitive?
envpilot secrets set STRIPE_SECRET_KEY -e production   # key given, value prompted masked
envpilot secrets set API_URL=https://api.example.com   # inline — CI only

Two-step by default: the key is validated first, then the value is typed into a masked prompt, so it never reaches your shell history or ps output. The inline KEY=VALUE form exists for CI and prints a history warning when you use it interactively.

envpilot var … is an alias for the same command.

Options — -e, --env <environment> · -p, --project <name-or-id> · -d, --description <text> · --sensitive · --all-envs

Behaviour worth knowing:

• Role-aware. If your role cannot write directly, the same flow files a variable request instead of rejecting you.
• Shared values need consent. A value shared across several environments lives on one variable, so updating it changes all of them — the CLI asks first, and --all-envs answers non-interactively.
• Idempotent. Setting a key to the value it already has is a no-op, reported as such.
• Plan limits are enforced server-side and reported readably; envpilot usage shows where you stand.

Delete one secret#

envpilot secrets rm OLD_FLAG
envpilot secrets rm OLD_FLAG -e staging --yes

What happens depends on how widely the key is scoped:

Limits#

• secrets set writes one key in one environment per invocation. For bulk work use push.
• secrets rm never bypasses the trash: recovery is via the dashboard, not the CLI.
• --value inline forms land in shell history. Prefer the masked prompt; in CI prefer stdin, see CLI in CI.

Next#

• Requests
• Variables — trash, versions, rollback