# Secrets

The Markdown copy of <https://yeeted.ai/docs/secrets.html>.

API keys, signing secrets, that SECRET_KEY_BASE your framework wants: store them as secrets instead of hard-coding them.

Secrets are injected into your app as environment
variables on its next deploy.

```
"Set a secret STRIPE_API_KEY on my app."
"List my secrets."
"Delete the STRIPE_API_KEY secret."
```

Or use the **Secrets** tab in the dashboard. Two things to know:

- **Values are write-only - not even Yeeted can read them.** Once set, a secret's value can
  never be read back: not from the dashboard, not by your agent, and not by anyone at Yeeted - support
  engineers and administrators included. No one at Yeeted can ever view a secret's value or your database
  passwords. You'll see the name, when it changed, and what uses it; never the value. Keep your own copy if
  you'll need it elsewhere.
- **Names become env vars**, so they're UPPER_SNAKE_CASE (e.g. `STRIPE_API_KEY`).
  Setting an existing name replaces the value; the change lands on your next deploy.

The Secrets tab also shows the credentials Yeeted manages *for* you - your database passwords and
platform-held keys - so you always know what exists, even though no one can view the values.

A secret is shared by both environments or set for development or production only. Who may set which is in
[Who can do what](https://yeeted.ai/docs/who-can-do-what.html#data).