Create a separate Supabase project for development, copy your schema to it with migrations, and point local and preview builds at it.
Set up a separate dev database so I stop testing on production
How it works
- Create a dev project: Vovy creates a second Supabase project named yourapp-dev, so experiments never touch real customer data.
- Copy the schema, not the data: Vovy pulls migrations from production and pushes them to dev with the Supabase CLI. Tables and policies match; real user data stays put.
- Point local and preview at dev: Vovy puts dev keys in your local .env and in Vercel's Preview variables, and leaves Production pointed at the real database.
- Seed some fake data: Vovy fills the dev project with test users and records so every screen has something to show.
- Show the setup: A flow card shows which environment uses which database, and how a change moves from dev to production through migrations.
What you provide
- Your Supabase project
- Access to your host's env vars
What you get
- A separate dev database
- Matching schema in both
- Previews on dev, production on real data
- A clear environment map
FAQ
Does a second project cost more?
On Free, you get 2 active projects, so dev plus production fits. On Pro, each extra project adds its own compute cost.
What about Supabase Branching?
Branching creates a fresh database per Git branch automatically. It's a paid feature and each branch bills compute, so a single dev project is simpler to start.
Do I have to keep them in sync by hand?
No. Once changes go through migration files, pushing them to each project keeps both identical.
Related tasks
All tasks