BUILD AND RUN
Secrets
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.