Skip to main content
General

Deployment

Learn how to deploy your Pro Next.js Drizzle application to production.

Open MarkdownFull AI corpusFeedback

We recommend deploying your application to Vercel for the most direct Next.js workflow, but you can use any provider that supports Node.js and PostgreSQL.

Prerequisites

Before deploying, ensure you have:

  • A GitHub repository with your project code.
  • A PostgreSQL database (Neon, Supabase, Railway, etc.).
  • The provider accounts required by the features you keep, such as Stripe, Resend or an S3-compatible storage service.
  • A unique production authentication secret.

Deploying to Vercel

  1. Push your code to a GitHub repository.
  2. Import the project into Vercel.
  3. Add the required environment variables for Production. Add them to Preview only when preview deployments should connect to separate preview services.
  4. Apply the committed database migrations once from CI or a one-off release task.
  5. Deploy the same commit that you validated locally.

Environment Variables

Start with the complete environment variable guide. The minimum application and database values are:

Vercel Settings
BETTER_AUTH_SECRET="generate-a-unique-production-secret"
DATABASE_URL="postgresql://user:pass@host:5432/db?sslmode=require"
NEXT_PUBLIC_SITE_URL="https://your-app.com"

Add provider variables only for the integrations you enable. Never copy live secrets into variables prefixed with NEXT_PUBLIC_.

Database Migrations

Both kits expose the same production migration command:

Terminal
npm run db:migrate

Run it once against the production DATABASE_URL before the new application revision receives traffic. A CI release job or a one-off task on your hosting provider is suitable. Do not add migrations to npm run build and do not run them from every application replica at startup.

Keep migration files in version control and review them with the code that depends on the schema change. Use development migration commands only while authoring a migration locally.

SSL and Database Connections

Most production database providers (like Neon or Supabase) require SSL. Ensure your DATABASE_URL includes ?sslmode=require.

.env
DATABASE_URL="postgresql://user:pass@ep-xxx.region.aws.neon.tech/neondb?sslmode=require"

Post-Deployment Checklist

Treat the first production deployment as a release, not only a successful build. Complete each applicable check before sending customers to the app.

Application and database

  • Run npm run typecheck, npm run lint, npm run test:unit -- --run and npm run build against the release commit. The explicit --run keeps Vitest non-interactive on a developer machine and in CI.
  • Run production migrations once and confirm the expected schema exists.
  • Confirm the production database has backups and a tested restore procedure.
  • Verify NEXT_PUBLIC_SITE_URL exactly matches the canonical production origin.
  • Verify the custom domain, HTTPS certificate, redirects, robots.txt and sitemap.

Authentication and email

  • Create a new account and complete email verification on the production domain.
  • Complete password reset and confirm its link returns to the production app.
  • Update Google OAuth origins and callback URLs for the production domain.
  • Confirm EMAIL_FROM uses a verified domain and replies go to a monitored address.
  • Test organization invitations with a second email address.

Billing

  • Replace every Stripe test key and Price ID with its live-mode value.
  • Configure the production webhook endpoint at https://your-domain.com/api/webhooks/stripe.
  • Subscribe the endpoint only to events handled by the shipped webhook route.
  • Complete a real or controlled live-mode purchase, then verify the local order or subscription state.
  • Open the customer portal and verify cancellation or plan-change behavior for your product.

Storage, monitoring and operations

  • Restrict storage credentials to the required bucket and object operations.
  • Upload and display an avatar or organization logo from the production domain.
  • Confirm Sentry receives a controlled test error without exposing secrets or personal data.
  • Confirm production logs use the intended level and do not contain credentials or tokens.
  • Add uptime monitoring for the application and any business-critical webhook path.
  • Document who receives billing, authentication and infrastructure alerts.

Features you have disabled do not need their provider checks. Do not configure production credentials for integrations the application does not use.