Answers
Every key the app reads, what happens without it, and the ones you can skip.
No. Billing, email, bot checking and error reporting each sit behind an adapter that returns a real client when its credential is present and a deterministic local fake when it is not. A fresh clone runs bin/setup and bin/dev with no keys, and checkout, sign-in and gated features all work end to end.
Wrap it in an adapter that returns a real client when its credential is present and a deterministic fake when it is not, the way app/adapters/billing.rb does. The test suite runs against the fake, so there are no network calls, no API keys in CI and no test that fails because someone else's service is down.
Create an OAuth 2.0 client in Google Cloud Console, add your callback URL as an authorized redirect URI, and set the client id and secret. One Shot already has the OmniAuth callback route and the user upsert, so no code changes. Google's host also has to be in the content security policy's form-action list.
One Shot uses letter_opener in development, so every deliver_later opens the rendered email in a browser tab instead of sending it. No key and no account are needed. That is how you read a sign-in code locally, and it means a seed script cannot accidentally email a real address.
Create the new key at the provider while the old one still works, set it, deploy, verify the app is using it, and only then revoke the old one. Most providers allow several active keys for exactly this reason. Revoking before deploying is what turns a routine rotation into an outage.
Set RESEND_API_KEY and MAIL_FROM, and ActionMailer delivers through Resend in production while development keeps opening messages in a browser tab. The code side is already wired. The real work is verifying your sending domain and publishing SPF, DKIM and DMARC, without which the mail sends and lands in spam.
Set TURNSTILE_SITE_KEY and TURNSTILE_SECRET_KEY. app/adapters/bot_check.rb returns a real Cloudflare Turnstile verifier when both are present and a pass-everything fake when they are not, so the form works in development with no account and starts blocking bots in production without a code change.
Set S3_BUCKET, S3_REGION, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, plus S3_ENDPOINT for a non-AWS provider. config/storage.yml already defines the service, so production uses object storage instead of the container's disk. Existing files on local disk do not move by themselves.
Ask the adapters at runtime rather than reading environment variables. Each one chooses a real client or a local fake based on whether its credential is present, so querying the adapter tells you what the app is actually doing. A variable that is set but misspelled looks configured and behaves like a fake.
Either. The app reads ENV first and falls back to Rails.application.credentials, so a value set in the environment wins and a value in the encrypted file is the default. Use credentials when you want secrets versioned with the code, and environment variables when a platform or a team already manages them elsewhere.
Three: an SPF record authorizing your sending provider, DKIM keys the provider gives you, and a DMARC policy. Your email provider publishes the exact values; you add them at your DNS host. Missing any of the three is the reason a correctly configured app still has its sign-in emails filtered, and no code change fixes it.
It is the root secret Rails derives every other key from: the one that signs session cookies, encrypts encrypted cookies, and verifies signed global ids and Active Storage URLs. Change it and every existing session becomes invalid, so every signed-in user is logged out at the moment of deploy.
RAILS_MASTER_KEY is the only one production will not boot without. APP_HOST is not a secret but belongs in the same pass, because without it every emailed link points at localhost. Add a Stripe key when you want to charge and a Resend key when you want mail to leave the building; both run on fakes until then.
The content security policy is blocking the navigation. form-action covers the whole redirect chain a form starts, so the provider's host must be listed in config/initializers/content_security_policy.rb. The form also needs data-turbo="false", or Turbo submits it by fetch and the cross-origin redirect is blocked as an XHR instead.
The client id and private key come from the Apple Developer Program, which is a paid membership at 99 dollars a year. There is no free tier for issuing Sign in with Apple credentials. Google's OAuth client is free, so if you only want one social provider to start, Google is the one with no standing cost.