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.