Deploy your Leefy plan to Vercel

How do I deploy an AI-built app?

Once your AI coding agent has built out a project from your Leefy plan, you need somewhere for it to actually run. Vercel is the fastest path for a Next.js app: connect your GitHub repo, set a handful of environment variables, and every push gets its own live URL. This guide walks through a full production deploy, including the database, payments, and error tracking — skip the sections you don't need yet.

You'll be doing every step yourself in your own dashboards. Nothing here runs automatically from Leefy.

What accounts do I need before I start?

• A Vercel account (the dashboard works fine, or install the CLI with npm i -g vercel).
• A Supabase project if your app has a database or authentication — the same one you've likely been using locally during development.
• A Stripe account if your app takes payments, with both test and live modes enabled.
• Optionally, a PostHog project for analytics and a Sentry project for error tracking.

How do I connect my database to production?

If your project uses Supabase:

1. Create a cloud project and note its project ref, URL, anon key, and service-role key.

2. Link your local project and push your schema:

   supabase link --project-ref <ref>
   supabase migration list --linked   # anything with an empty "remote" column
                                       # hasn't reached the cloud yet
   supabase db push                   # applies every pending migration
   

   db push is the only supported path to cloud schema changes — avoid hand-editing tables in the dashboard, since that drifts from what your migrations describe.

3. In Authentication → URL Configuration, set your production domain as the Site URL and add https://<your-domain>/auth/callback to the redirect allow-list (plus your Vercel preview URL pattern if you want previews to support login too).

4. If you use Google sign-in, add your production callback URL to the Google Cloud console's OAuth settings as well.

5. Turn on Point-in-Time Recovery backups before you consider yourself launched — this typically requires a paid Supabase tier.

How do I connect my GitHub repo to Vercel?

1. From the Vercel dashboard, import your repository. Vercel auto-detects Next.js and picks sensible build defaults — you generally don't need a custom vercel.json.
2. Add your environment variables under Settings → Environment Variables, separately for the Production and Preview environments. Use your project's .env.example file as the checklist of what's needed — things like your Supabase URL and keys, any AI provider API keys, and payment keys.
3. Deploy. Vercel builds and serves your app; pages that don't need a server render as static, and everything else runs as a function automatically.

How do I take payments live?

If your project uses Stripe:

1. Switch Stripe to live mode and create your real prices there, then copy their ids into your production environment variables.
2. Create a live webhook endpoint pointing at https://<your-domain>/api/stripe/webhook, and copy its signing secret into your production environment variables too.
3. For local development and preview deploys, keep using Stripe's test mode — the stripe listen CLI command forwards test webhooks to your machine.
4. Before telling anyone your product is live, run one real purchase and refund yourself to confirm the whole loop works end to end.

How do I add analytics and error tracking?

Both are optional, but worth doing before you start sending traffic:

• PostHog — set your PostHog project key (and host, if self-hosted) as an environment variable. Once set, both the browser and server sides of most apps will start sending events automatically.
• Sentry — set your Sentry DSN as an environment variable to start capturing runtime errors. Uploading source maps for fully readable stack traces is a nice-to-have, not a requirement to launch.

What should I check right after deploying?

• Sign in to your live app end to end, using every auth method you support.
• Walk through your product's core flow once, live — not just in a test environment.
• Visit a URL that doesn't exist and confirm you get a real 404 page rather than a broken one.
• If you have automated end-to-end tests, run them against your new production or preview URL before telling anyone it's ready.