## Regenerate the pair

The key and the encrypted file are a matched set. A new key cannot read an old file, so both go:

```bash
rm config/credentials.yml.enc config/master.key
bin/rails credentials:edit
```

That opens an editor on a fresh encrypted file and writes a new `config/master.key` beside it.
`master.key` is gitignored; the `.enc` file is committed. Commit the new one.

## Then re-enter every secret

Nothing is recoverable from the old file, so work from the sources instead. Each service has its own
route back:

- **Stripe.** Roll the secret key in the dashboard and copy the new one. The old key keeps working
  until you roll it, so this is safe to do calmly.
- **Resend.** Same shape: create a new API key, delete the old one.
- **OAuth.** Google and Apple client secrets can be regenerated from their consoles.

`docs/BRING_YOUR_OWN_KEYS.md` lists every key the app reads and which ones are optional. Most of
them are, and an app that only has `RAILS_MASTER_KEY` still boots and runs on the local fakes.

## Get the new key to production

```bash
bin/kamal secrets print
bin/kamal deploy
```

`RAILS_MASTER_KEY` reaches the server through `.kamal/secrets`, which is not committed. Update it
there, confirm the secrets listing shows a value, then deploy. A deploy with the wrong key fails on
the health check, because Rails raises during initialization before any route exists.

## Why there is no recovery

The file is encrypted with the key and nothing else. No escrow, no reset link, no support channel
that can decrypt it. That is the property that makes it safe to commit the ciphertext to a
repository, and it is the same property that makes a lost key final.

## Keep the next one

Put the value in a password manager the day you generate it, not the day you need it. One Shot reads
`ENV` first and falls back to credentials, so a team can also skip the encrypted file entirely and
set each secret as an environment variable instead.