Docs · Bring Your Own Keys

Secret Key Base

The one required secret, and the two ways to set it.

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.

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.

Option 2: a bare environment variable

Skip credentials entirely:

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); locally, use a .env file, copying .env.example as a starting point.

Next

Turn on real transactional email: Email with Resend.