AUTH STARTER · DEPLOYING TO VERCEL
Deploying to Vercel
Vercel is the path we ship on. Self-hosting works fine — bring your own URL and DKIM.
The Vercel path
- Push to GitHub.
- Import the repo on Vercel — framework auto-detected.
- Paste env vars from .env.local (BUT use prod values — see below).
- Deploy. Custom domain? Add it, DNS will tell you the records.
Env vars for production (the values that CHANGE)
# Generate a NEW secret for prod (do NOT reuse the local one)
BETTER_AUTH_SECRET="$(openssl rand -base64 32)"
# Both URLs are the deployed origin
BETTER_AUTH_URL="https://yourdomain.com"
NEXT_PUBLIC_APP_URL="https://yourdomain.com"
# DATABASE_URL — your prod Postgres, not the dev one
DATABASE_URL="postgresql://...prod..."
# Everything else stays the same shape, just the production values.OAuth on prod
Go back to Google Console / GitHub Developer Settings and ADD the production redirect URI. Keep the dev one too — different OAuth apps if you want stricter separation.
https://yourdomain.com/api/auth/callback/google
https://yourdomain.com/api/auth/callback/githubSelf-hosting
It's a standard Next.js app. Render, Railway, Fly, your own VPS — all fine. Make sure DATABASE_URL is reachable from the container, BETTER_AUTH_URL matches the public origin, and HTTPS is terminated somewhere (passkeys need it).
Migrations run BEFORE the app starts in prod
Set up a deploy hook that runs bun run db:migrate before bun start (Vercel: a build step or a pre-deploy hook). If migrations run AFTER the app boots, the first traffic hits a DB schema your code doesn't match.