Skip to main content

R2. Secrets

What this page helps you do​

Store and handle sensitive values safely enough for a real launch.

Why it matters​

Secrets are one of the easiest ways to accidentally hurt yourself in public. A leaked API key, database password, or admin token can create real damage fast.

You should already have​

  • an app that depends on keys, passwords, tokens, or service credentials

Skip this page if​

  • your app truly has no secrets at all

What to do​

Move secrets out of code and into your hosting provider or secret manager.

At minimum:

  • do not commit real secrets to git
  • do not paste secrets into screenshots or docs
  • use different values for local and production when needed
  • know how to replace a secret if it leaks

Also check common leak points:

  • old commits
  • example config files
  • CI settings
  • logs
  • screenshots in issues or demos

Use environment settings in your hosting platform and keep a safe .env.example file in the repo with fake values.

Common mistakes​

  • committing a secret once and assuming deleting the line fixes everything
  • reusing one secret everywhere
  • logging tokens or full headers by accident
  • sharing production values in chat threads

Next step​

Go to R3. Safer deploys or R8. Launch checklist.

Advanced notes​

If you already leaked a secret, stop treating it like a documentation cleanup. Rotate it, replace it, and then remove old references.