Overview

You can deploy the app to any hosting provider that supports Node.js. Since Next.js is developed by Vercel, deploying to Vercel offers the most seamless and optimized developer experience.

Choose a hosting model

The starter kit ships as one Next.js service. It does not include a separately deployed API server or persistent worker process.

Choose based on the operations you are prepared to own, not only the initial deployment cost. If the product needs durable background work, use a managed background provider or operate a separate worker service. Do not depend on a Next.js web instance remaining alive after an HTTP response.

Production checklist

Complete these steps before sending production traffic to a new environment:

1. Create an empty PostgreSQL database and set its production DATABASE_URL.

2. Add the required server and browser variables from the environment variable guide.

3. Replace the development BETTER_AUTH_SECRET with a unique production value.

4. Add https://yourdomain.com/api/auth/callback/google to the Google OAuth client if Google sign-in is enabled.

5. Configure the Stripe webhook endpoint at https://yourdomain.com/api/webhooks/stripe if billing is enabled.

6. Apply the committed database migrations once as a release step:

   Terminal

   npm run db:migrate

7. Build the same revision that will be deployed:

   Terminal

   npm run build

8. Verify sign-in, email delivery, organization access and one billing flow in the deployed environment before announcing the release.

Public launch checklist

A successful build only proves that the application compiled. Complete this second pass before directing customers to it:

• Connect the final domain, set NEXT_PUBLIC_SITE_URL to its HTTPS URL and redeploy so generated links and authentication callbacks use that origin.
• Replace the starter name, logo, contact details, legal text and sample marketing content with your own product information.
• Verify the sender domain and review the authentication and invitation email templates using real inboxes outside your company domain.
• Enable automated database backups and perform a restore rehearsal before the database contains customer data.
• Configure provider budgets and alerts for every usage-based service, including OpenAI, email, storage and monitoring.
• Test a failed payment, canceled subscription and Stripe webhook retry in test mode, not only a successful checkout.
• Confirm that a non-admin user cannot open admin routes or another organization's resources.
• Check the privacy policy and terms against the data and providers your deployed product actually uses.

Control third-party spend

Treat every server-side provider key as access to a billable account. Use a separate provider project or account for each environment so a development or demo incident cannot consume the production budget.

For the included AI chat:

1. Set an OpenAI project budget and provider-side usage alerts before adding OPENAI_API_KEY to production.
2. Keep model selection restricted to the allowlist in config/billing.config.ts.
3. Configure application credits deliberately. Organization credits limit what the product permits, but they do not replace the OpenAI project budget.
4. Do not fund an unrestricted key for an anonymous public demo. Disable live generation or add a durable per-user and per-IP limiter first.
5. Monitor provider usage after launch and keep a documented way to revoke the key quickly.

To learn more about deployment, explore the following guide: