Configuration
Generate local environment values, add provider keys, and prepare the managed Vercel and Supabase deployment path.
Was this page helpful?
Local development reads .env.local. Start Supabase first, then let the
template CLI write the matching local URL, publishable key, secret key, and
Postgres connection. You do not need to copy values from supabase status by
hand.
For a new installation, complete the first-run migration check before following this configuration sequence.
bunx supabase startKeep the local Supabase stack running for the next two steps.
.env.local./coremvp env syncThe command reads the running local Supabase instance and updates the
template's ignored .env.local file.
bun run devOpen http://localhost:3000. Restart this process after changing an
environment value.
When updating an existing checkout, rename
NEXT_PUBLIC_SUPABASE_ANON_KEY to NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY and
SUPABASE_SERVICE_ROLE_KEY to SUPABASE_SECRET_KEY anywhere you manage
application environment variables. ./coremvp env sync writes the current
names locally, but it does not change hosted provider configuration. Supabase
can keep both key generations active while you migrate every consumer; the
template does not read the old names or rotate or deactivate provider keys. See
the Supabase API-key migration guide.
Choose Polar Billing for Polar sandbox setup, offer mappings and webhook forwarding. A Polar-only app does not need Stripe keys or catalog IDs. Keep Stripe configured when it still handles retained billing or outstanding deliveries.
For Stripe billing, 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.
Set NEXT_PUBLIC_STRIPE_MODE=test and your test account's public Product/Price
inputs from Environment Variables
before testing billing. You can start the app before this step; checkout stays
unavailable for any test Price ID you have not configured.
Only variables beginning with NEXT_PUBLIC_ may be exposed to browser code.
Never commit .env or .env.local.
Read public settings through explicit import.meta.env.NEXT_PUBLIC_* access.
Vite loads them for development and replaces them during a production build.
Keep process.env reads for server-only runtime settings. A public-value
change needs a rebuild; see Hosted Environment Variables.
See the hosted deployment status before following the managed deployment steps.
Production deployment uses Vercel for the single TanStack Start 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 pushPut that project's hosted DATABASE_URL and the other required application
values in ignored .env for local operator use.
Then select the intended Vercel project and deploy after its Production values are complete:
bunx vercel whoami
bunx vercel teams lsFor 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 --prodUse Vercel Deployment for the provider checkpoints and hosted verification path. Use Environment Variables when you need the complete key reference.
Prop
Type