Introduction
Twins lets you clone a Supabase project to another in just a few clicks. Database, files, users, functions — everything is copied automatically.
Why use Twins?
The problem: dev and production share the same project
Today, most developers using Supabase work directly on their production project. When you modify a table, add a column, change an Edge Function, or adjust an RLS policy — you're doing it on the database where your users are connected right now.
This is risky. A migration that breaks a schema, a misconfigured trigger, an overly permissive RLS policy — and your users are immediately affected. No safety net, no simple rollback.
With the rise of vibe coding and AI-assisted development tools, this problem is amplified. We iterate faster than ever — generating code, testing ideas, modifying schemas on the fly. It's powerful, but it makes the lack of separation between dev and production even more dangerous. The faster you move, the higher the risk of impacting your live users.
The solution: separate staging and production
The principle is simple: never develop on production.
- You have a production Supabase project — that's the one your users rely on
- You create a staging project — that's your development and testing environment
- You develop, test, break, and rebuild freely on staging
- Once everything is solid, you deploy to production with confidence
The problem is that Supabase doesn't offer a built-in feature to duplicate a project. Creating a staging environment that faithfully mirrors production — with the same schema, data, functions, RLS policies, Edge Functions — is manual, time-consuming, and error-prone work.
That's exactly what Twins solves.
Twins clones your entire production project to a staging project in just a few clicks. And when you need to refresh your staging with the latest production data, you run a new clone — or schedule one to run automatically.
What it changes in practice
| Without Twins | With Twins |
|---|---|
| You test your changes directly in production | You test on a staging environment identical to production |
| A mistake immediately impacts your users | A mistake stays isolated on staging |
| You hesitate to modify the schema or functions | You experiment freely, without consequences |
| You manually recreate tables, data, and config | Everything is cloned automatically in minutes |
| No visibility into differences between environments | Post-clone verification to confirm consistency |
What Twins can clone
| Component | What is copied |
|---|---|
| Tables | Full structure: columns, types, constraints, indexes |
| Data | All rows (or a subset with a limit) |
| Views | SQL views |
| Functions | PostgreSQL functions and stored procedures |
| Triggers | Triggers on tables |
| RLS Policies | Row Level Security — row-level access rules |
| Edge Functions | Supabase serverless functions |
| Storage | Buckets and files |
| Auth Users | User accounts with metadata |
| Cron Jobs | Scheduled tasks (pg_cron) |
| Webhooks | Database event notifications |
| Realtime Config | Real-time publication configuration |
| Project Config | Authentication providers, PostgREST settings |
How it works, in brief
- Connect your Supabase account to Twins
- Choose a source project and a target project
- Preview what will be cloned
- Start the clone
- Monitor progress in real time
- Verify that everything was copied correctly
Available plans
| Plan | Clones per month | Price |
|---|---|---|
| Free | 3 | Free |
| Pro | Unlimited | See Billing |
Next steps
- Quickstart — Run your first clone in 5 minutes
- Key concepts — Understand Twins terminology