Configuration

Generate local environment values, add provider keys, and prepare the managed Vercel and Supabase deployment path.

Configure local development

Local development reads .env.local. Start Supabase first, then let the template CLI write the matching local URL, Auth keys, service-role key, and Postgres connection. You do not need to copy values from supabase status by hand.

Start local Supabase

bunx supabase start

Keep the local Supabase stack running for the next two steps.

Sync `.env.local`

./coremvp env sync

The command reads the running local Supabase instance and updates the template's ignored .env.local file.

Start the Next.js app

bun run dev

Open http://localhost:3000. Restart this process after changing an environment value.

Stripe is a separate billing step. Add test API keys to .env.local, run stripe login, then keep stripe listen --forward-to localhost:3000/api/webhooks/stripe running. Copy the displayed signing secret to STRIPE_WEBHOOK_SECRET in ignored .env.local and restart bun run dev.

Runtime variables

Prop

Type

Only variables beginning with NEXT_PUBLIC_ may be exposed to browser code. Never commit .env or .env.local.

Prepare managed deployment

Production deployment uses Vercel for the single Next.js runtime and Supabase for Auth and Postgres. Provider CLIs and dashboards own those projects and their environment values; ./coremvp only checks template-owned results.

bunx supabase login
bunx supabase link --project-ref <project-ref>
bunx supabase db push

Put that project's hosted DATABASE_URL in ignored .env, then verify the application database:

./coremvp db verify

Compare the configured connection identity—endpoint, configured db, and configured user—with the connection shown in that project's Connect panel. For a Shared Pooler URL, configured user must contain postgres.<project-ref>. Stop if any configured field differs. Continue only when every expected app table is present. The verifier does not query Supabase project metadata.

Then select the intended Vercel project and deploy after its Production values are complete:

bunx vercel whoami
bunx vercel teams ls

For a personal-account project, omit --scope:

bunx vercel project ls
bunx vercel link --project <project-name>

For a team project, use its team slug:

bunx vercel project ls --scope <team-slug>
bunx vercel link --project <project-name> --scope <team-slug>

Vercel rejects a personal username passed as a scope. Stop if the identity, team, or project list does not match the deployment you intend to configure.

Then continue with the linked project:

bunx vercel env ls production
bunx vercel deploy --prod

Use Vercel Deployment for the provider checkpoints and hosted verification path. Use Environment Variables when you need the complete key reference.

Was this page helpful?