## Ask the app, not the config

```bash
bin/kamal app exec --interactive --reuse 'bin/rails console'
```

```ruby
Billing.for(Account.first).class
ActiveStorage::Blob.service.name
ActionMailer::Base.delivery_method
Rails.application.config.x.app_host
```

Four lines, four of the things most likely to be silently wrong. Each returns what is live rather
than what you believe you configured.

## Why reading the variables is not enough

Three failure modes all look identical from the outside:

- The variable is misspelled, so it is unset as far as the app is concerned.
- It is set on your laptop and not on the server.
- It is set in `.kamal/secrets` but that file did not export it, so the value is empty.

In every case the adapter falls back to its fake, the app works, and nothing reports a problem. That
graceful degradation is exactly what makes a fresh clone usable and exactly what hides a
misconfiguration in production.

## The two that fail loudest

`RAILS_MASTER_KEY` is missing: the app does not boot, so you find out on the first deploy.

`MAIL_FROM` names an unverified domain: the provider rejects the send, which raises in the job and
lands in the log rather than passing silently.

Everything else degrades quietly.

## Make it a habit after each deploy

```bash
bin/kamal secrets print
curl -sI https://yourdomain.com/up | head -1
curl -s https://yourdomain.com/sitemap.xml | head -3
```

The third one is the cheap check for `APP_HOST`: if the first URL in the sitemap is localhost, several
other things are wrong in the same way, including every link in every email.

## Check the list itself

`docs/BRING_YOUR_OWN_KEYS.md` lists every variable the app reads. Going down it once after the first
deploy, deciding which you want live and confirming each, takes about ten minutes and is the only
time you will have the whole picture in your head.