Every other credential on this docs site is optional. This one isn't: Rails will not boot in
production without a secret key base, since it's what signs sessions and cookies. It's also the
single most common first-deploy failure, precisely because it never shows up locally: development
and test each generate a temporary key automatically, so a fresh clone runs perfectly right up
until the first real `kamal deploy` fails with no obvious clue why.

The kit ships with no credentials file at all, so you generate your own. There are two ways; pick
one.

## Option 1: encrypted credentials, recommended

```bash
bin/rails credentials:edit
```

This creates `config/master.key` and `config/credentials.yml.enc`, with a `secret_key_base` value
already inside. Commit the `.enc` file; never commit the key itself, which is gitignored by
default. Ship `RAILS_MASTER_KEY` to production, already wired through `.kamal/secrets`. You'll want
encrypted credentials anyway if you're setting up Google or Apple sign-in, since both need
credentials stored the same way; see
[Sign in with Google and Apple](/docs/bring-your-own-keys/sign-in-with-google-and-apple).

## Option 2: a bare environment variable

Skip credentials entirely:

```bash
bin/rails secret
```

Add the output as `SECRET_KEY_BASE` in `env.secret` inside `config/deploy.yml`, and supply it like
any other deploy secret.

## Secrets resolve ENV first, then credentials

Everywhere in the app, a secret resolves from the environment first, falling back to Rails
encrypted credentials. In production, inject secrets through Kamal secrets (see
[First Deploy Checklist](/docs/deployment/first-deploy-checklist)); locally, use a `.env` file,
copying `.env.example` as a starting point.

## Next

Turn on real transactional email: [Email with Resend](/docs/bring-your-own-keys/email-with-resend).