Keyboard shortcuts

jk
move through the list
↵
open the selected item
a
ask a question
nucw
tabs: new, unanswered, active, top
⌘↵
post the answer you are writing
/or⌘K
search
t
switch theme
?
this list
AskVibe
AskSign in
Demo, all content is generated
Question

Vercel preview deployments are writing to my production database

Open · 1102 views · asked by adaeze · edited
claude-codevercelsupabasedeploymentsecurity

I opened a PR, Vercel made a preview link, I tested the signup flow on the preview and... the test users are in my real Supabase project. Also a test order email went to a real customer because the preview ran against real data. How do people normally separate this? I only have one Supabase project.

What I’ve tried

Looked at the Vercel env var page, all my vars are checked for Production, Preview and Development.

Comment
That's the default when you add vars in the Vercel UI, it's caught many people. abby_ops · edited
Update: made a second free Supabase project for staging, scoped the vars. Separate question: how do I keep the schema of the two projects in sync without doing it by hand? adaeze · edited

3 answers

deploydan · edited

The checkboxes are the whole story. Each env var in Vercel can have a different value per environment:

  • Production: real Supabase project
  • Preview: a second Supabase project (free tier is fine) with fake data
  • Development: local Supabase (supabase start) or the same staging project

Edit each variable, uncheck Preview, then add it again with the staging value for Preview only. Do the same for anything that sends real emails or charges money: Resend key, Stripe key (test mode key for Preview).

Redeploy the preview afterwards, env vars are read at build time.

Comment
Doing this tonight. The email to a real customer was not a fun morning. adaeze · edited
jb_supa · edited

For keeping the staging schema in sync: put every schema change in migrations (supabase migration new ...) and apply them to both projects with supabase db push, staging first. Supabase also has branching, which spins up a database per PR, but that's a paid feature and more moving parts. A second project plus migrations is what I'd start with.

Comment
+1 migrations first. Branching is great once migrations are already clean, painful before. hannah_reyes · edited
katja_s · edited

For the fake data on staging: keep a supabase/seed.sql with a few test users and orders. Reset staging whenever it gets messy and you always have a known state to test previews against.

Comment
Ha, already started one after the email incident. adaeze · edited

Related

Moving my Lovable app to my own Vercel account, what do I need to change?solved
Bolt dashboard for warehouse pick rates, is the anon key in the browser a problem?0 ans.
Pricing page still shows old prices hours after I change them in Supabase4 ans.
Server action works locally, production just says 'An error occurred in the Server Components render'solved
Stripe live webhook never arrives, test mode was finesolved

Your answer

Sign in to write an answer