Use a generator for the feature you want, review its changes, and run the host checks afterward.
Before running a generator
Use the development checkout described in the quickstart. The host must have the Rails authentication generator’s account, session and authentication files. Make your host changes reviewable before generating migrations.
Choose a command
Command after bin/rails | What it changes |
|---|---|
generate latchkey:install | Checks host files, writes configuration if absent and runs doctor. Enables no features. |
generate latchkey:session_upgrade | Adds session migrations, lifecycle wiring, password sign-in and session-management routes. |
generate latchkey:email_link | Invokes session adoption and token persistence, adds delivery/binding migrations and email routes. |
generate latchkey:challenge turnstile | Writes provider configuration for Turnstile. |
generate latchkey:challenge recaptcha --version=v2 | Writes reCAPTCHA configuration for the selected version. |
generate latchkey:views --only=email_link | Copies sign-in partials and dedicated layouts, preserving existing files. |
generate latchkey:views --only=sessions | Copies session-management views, preserving existing files. |
Inspect the host with doctor
bin/rails latchkey:doctorDoctor checks enabled session, email, passkey, reauthentication, recovery, notification and challenge wiring, plus generated-file drift. Fix reported issues and run it again. It does not replace delivered-email/browser checks or establish production readiness.
Recover pending delivery
bin/rails latchkey:deliver_pendingSchedule at least once a minute for deployed hosts. See delivery operations for retry, cancellation and monitoring responsibilities.
After generation
Review the file and migration diff, run bin/rails db:migrate, restart the app and check the actual route. Rerunning supported generators is intended to preserve your edits; inspect conflicts in customized Rails hosts rather than assuming an exact template match.