pealdevDOCS
Back to peal.dev

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)

Terminal
# 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.

Terminal
https://yourdomain.com/api/auth/callback/google
https://yourdomain.com/api/auth/callback/github

Self-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.