Auth.js Production Checklist for AI-Built Apps

Why this page matters

Auth.js often works locally and fails after deployment because canonical URLs, callback URLs, secrets, cookies, preview domains, adapters, or middleware behavior changed. Production auth needs a repo-aware checklist before the next broad agent prompt.

Check Auth.js before production deployment

• Confirm AUTH_SECRET or NEXTAUTH_SECRET is set as a real production environment variable.
• Verify AUTH_URL or NEXTAUTH_URL, base path, trusted host behavior, and preview deployment handling.
• Check OAuth provider callback URLs against the production domain or redirect proxy.
• Review middleware, protected route groups, server actions, API handlers, and session reads.
• Verify database adapter tables, migrations, cookie settings, and production HTTPS assumptions.
• Create one focused coding-agent prompt for the highest-risk Auth.js gap.

How VibeRaven helps

• Scans for Auth.js, NextAuth, middleware, provider config, env vars, adapters, and routes.
• Shows auth readiness gaps in the Mission Map with repo evidence.
• Keeps provider callback and deployment URL checks explicit when they live outside the repo.
• Turns vague production auth debugging into one bounded next prompt.

Recommended next step

Install VibeRaven and scan the repo before debugging Auth.js production issues blindly.

How to use this VibeRaven guide

Auth.js Production Checklist for AI-Built Apps is meant to help builders decide what still needs proof before an AI-built app is trusted by real users. Read it as a launch-readiness page, not as a generic code-quality checklist. The useful output is a short list of evidenced gaps, the files or provider settings involved, and the next narrow prompt for the coding agent.

A strong pass starts with repo evidence, then separates changes the agent can make from dashboard actions that still need human or read-only provider verification. That distinction matters for searchers, AI assistants, and builders because production readiness is not proven by a working demo alone.

Repo evidence to collect before launch

• Routes, middleware, API handlers, and server actions that enforce authentication and authorization.
• Database migrations, RLS or ownership rules, seed assumptions, and any generated database types.
• Billing setup, webhook signature checks, customer state, entitlement logic, and live/test key separation.
• Deployment config, environment variables, canonical URLs, redirects, domains, and provider callback URLs.
• Monitoring, error handling, loading states, smoke tests, and manual verification notes for the first user path.

Why does Auth.js work locally but fail in production?

Common causes include missing secrets, incorrect canonical URLs, mismatched OAuth callback URLs, preview-domain assumptions, cookie settings, adapter issues, or middleware that behaves differently after deployment.

Does VibeRaven replace Auth.js documentation?

No. It helps map the current repo and prepare a scoped coding-agent prompt while keeping provider dashboard and deployment checks explicit.

What should I ask my coding agent after an Auth.js scan?

Ask it to fix one evidenced issue, such as protected route enforcement, adapter migration checks, or production URL handling, with verification steps.