Every project collects secrets: database passwords, Stripe and payment keys, cloud tokens, webhook secrets, SMTP passwords. They tend to end up in the worst places: a pasted Slack message, a sticky note, a .env file committed by accident.
The rules that matter most
- Never commit secrets to git. Add your env files to .gitignore from the first commit. Keep a .env.example with names only, no values.
- One secret, one purpose. Separate keys for development, staging and production, and per service where you can. A leaked test key then can't touch real money.
- Least privilege. Use restricted or scoped keys (read-only, one project, one bucket) instead of an all-powerful account key.
- Know where every copy lives. If you can't list the places a key is stored, you can't rotate it confidently.
Where secrets should live
| Where | Good for |
|---|---|
| Your hosting's secret store or environment settings | Keys the running app needs in production |
| A local .env file (git-ignored) | Keys you need while developing |
| An end-to-end encrypted vault | The master copy you can always find, plus keys you only need now and then |
Your servers need secrets at runtime, so a secret store on the platform is the right home for those. But you also need a source of truth you can open from anywhere, which is not a Slack thread or a .txt file. That is what a vault is for.
Keeping the master copies in Potent Cipher
- Save each key as a secret with a clear label ("Stripe live secret key, shop") and a note saying where else it is configured.
- Use tags for projects or clients so you can find everything for one project at once.
- Everything, labels included, is encrypted on your device with a key we never see. (Why that matters.)
- On Pro, set a rotation reminder on a secret, so you get a nudge every few months to replace it.
Sharing a key with a teammate
Don't paste it into chat, where it stays in history and search forever. Use a one-time secret link that deletes itself after it is opened, and send it over a different channel than the context ("the link is in your email").
If a key leaks
- Revoke or rotate it first, at the provider. Deleting the commit is not enough: bots scan public repositories within minutes.
- Check the provider's logs for use you don't recognise.
- Update every place the key lived: your hosting settings, local env files, and the master copy in your vault.
- Find out how it leaked, and fix that.