Production Checklist

Stop the release on any FAIL below.

Secrets and crypto

• Generate high-entropy secrets outside source control; isolate environments.
• Separate enabled secret domains or derive scoped keys from one protected root.
• Confirm the production runtime provides the intended cryptography layer. Workers should use Web Crypto, not an assumed Node implementation.
• Document rotation, emergency revocation, and session impact.

FAIL: a default, development, logged, shared, or missing secret can reach production. Review Installation and the Workers runtime.

Cookies, origins, CORS, and proxies

• Prefer same-origin /auth/*. Otherwise test credentialed CORS with exact origins; never use credentials with Access-Control-Allow-Origin: *.
• Keep session cookies HttpOnly and Secure; verify SameSite, domain, path, and the __Host- constraints against the real HTTPS hostname.
• Configure an exact allowed-origin list. Origin checks protect mutations; they do not emit CORS headers.
• Trust forwarded IP/protocol headers only from a proxy boundary you control, and test a spoofed direct request.

FAIL: a hostile origin can mutate state, cookies disappear, or clients choose the policy IP. See Browser Client and Security Policies.

Durable storage

• Put auth and limiter state in durable services, never process or isolate memory.
• Apply ordered migrations before code that depends on them; verify the production migration ledger.
• Schedule encrypted, access-controlled backups and rehearse restore.

FAIL: rollback needs an incompatible down-migration, restore is unproven, or an enabled store is absent. See Storage Overview.

Abuse limits and email

• Exercise limits for sign-in, registration, verification, reset, MFA, passkey, and recovery paths by IP, identity, and user where configured.
• Verify 429 behavior and shared coordination across instances/regions.
• Authenticate the sending domain; test delivery, expiry, replay, and provider failure without logging sensitive values.

FAIL: limits reset on restart or required email reports success before durable delivery responsibility exists.

Optional integrations

• Passkeys, if enabled: verify RP ID, origin, HTTPS, one-time challenges, counters, enrollment, and revocation on production domains. Follow Passkeys.
• OAuth, if enabled: register exact production redirect URIs; verify state/PKCE, account-linking rules, provider error handling, and encryption of provider tokens. No wildcard redirects.
• Disable unlaunched routes, bindings, credentials, and UI.

FAIL: preview and production RP IDs, callbacks, or provider credentials are interchangeable.

Sessions and step-up

• Test issuance, refresh, rotation, logout, expiry, revocation, and revoke-other-sessions against durable rows.
• Require recent, sufficient assurance for factor, recovery, billing, and other sensitive actions.
• Authorize every backend operation independently of route or UI guards.

FAIL: a revoked token remains usable or sensitive actions accept stale AAL1 evidence. Review Sessions and Step-up.

Observability and privacy

• Alert on elevated failures, abuse-limit hits, email/provider errors, migration failures, and storage latency using stable reason codes.
• Redact cookies, credentials, codes, secrets, raw email/IP values, OAuth tokens, and hostile headers from logs, traces, analytics, and support tooling.
• Set retention/access policies; keep health checks read-only.

FAIL: operators cannot distinguish attack, dependency failure, and regression without exposing auth material.

Tests, deployment, and rollback

backup + restore drill -> migrate -> deploy canary -> auth smoke tests
        -> observe error/abuse signals -> promote OR roll back code safely

• Run unit, contract, concurrency, HTTP, browser, and production-domain smoke tests, including hostile origin, replay, expiry, and revocation.
• Canary the release, preserve the prior artifact/configuration, and define an owner and abort threshold.
• Prefer additive, backward-compatible schema changes so old and new code overlap safely.

On Cloudflare, D1, a rate-limit Durable Object, and email bindings are common; Alchemy can provision them but does not make them safe. Pin compatibility and tested Alchemy versions, protect state/logs, and review Cloudflare Workers and Alchemy v2. Other runtimes need equivalent guarantees, not identical resources.

FAIL: smoke tests fail, telemetry is blind, migrations outrun compatible code, or rollback depends on deleting production auth data.