Copy a Supabase Project to Another Account
Published Jul 8, 2026 · 6 min read
To copy a Supabase project to another account, first decide whether you want to transfer it (move the same project to a different organization - official, no duplicate) or copy it (recreate it in the other account as a new project). There's no one-click cross-account copy, so to recreate a project in another account you either run a manual pg_dump / pg_restore into a fresh project there, or use SupaClone to clone the project's schemas - and, if you want, their data - into a fresh target project in the other account over Supabase OAuth. This guide covers all three and when each one wins.
Transfer or copy: which one do you actually need?
These get conflated, but they solve different problems. A transfer relocates the exact same project to another organization - same database, same ref, no second copy. A copy produces a new, independent project that happens to start as a replica. If two teams need to keep working in parallel, you want a copy; if you're just moving ownership, you want a transfer.
| Transfer project (org → org) | Copy into another account | |
|---|---|---|
| Keeps the same project | Yes | No - creates a new one |
| Crosses accounts / orgs | Yes | Yes |
| Original keeps running | No - it moves | Yes - untouched |
| Copies data | N/A (same project) | Depends on method |
| Typical tool | Supabase Project Transfer | pg_dump, or SupaClone |
How to copy a Supabase project to another account with SupaClone
The official Restore to a new project creates the copy inside your own organization on a paid plan - it won't drop a project straight into a different account. SupaClone handles the cross-account case directly by authorizing both sides over OAuth and writing into a fresh project you control in the target account.
- Connect the source account. Sign in to SupaClone and authorize it against the account that owns the project you're copying. It looks up connection details through the Supabase Management API - you only provide the database password, which is stored encrypted.
- Authorize the target account. Connect the destination account the same way, so SupaClone can see a project to write into there.
- Create a fresh, empty target project in the destination account. SupaClone only ever writes into empty projects and only reads the source, so nothing on either side gets overwritten.
- Choose what to copy. The clone plan copies your own schemas - tables, RLS policies, functions, triggers, indexes, views, enums, extensions - and, if you want, their data. Storage, Edge Functions, and Auth config are native, selectable options - turn on only what you need. It skips the Supabase-managed schemas (
auth,storage,realtime) correctly, which is what makes a raw cross-accountpg_dumppainful.
- Run and verify. Every run ends in field-by-field verification and a report of what was copied, skipped, failed, or left as a manual step. Secrets and API keys are never copied - they show up as manual steps so you can set them in the new account yourself.
SupaClone copies your own schemas and, optionally, their data - you choose per run - so it suits a lean structure-only copy for a client or dev account as well as a full data copy. It skips the Supabase-managed auth schema, so auth.users never crosses over; anonymized data cloning is coming soon. Your first clone run is free at signup; see pricing if you want to run a full cross-account copy first.
How to copy a Supabase project to another account on the free tier
Both accounts on the free plan? Then the official restore is out, and you dump from the source and restore into a fresh project you've created in the target account. Use three passes so roles and schema exist before the rows arrive:
supabase db dump --db-url "$SOURCE_DB_URL" -f roles.sql --role-only
supabase db dump --db-url "$SOURCE_DB_URL" -f schema.sql
supabase db dump --db-url "$SOURCE_DB_URL" -f data.sql --data-only
psql --single-transaction --variable ON_ERROR_STOP=1 --file roles.sql --dbname "$NEW_DB_URL"
psql --single-transaction --variable ON_ERROR_STOP=1 --file schema.sql --file data.sql --dbname "$NEW_DB_URL"
Enable any Postgres extensions in the destination project before running schema.sql, or it will error, and exclude the managed schemas to dodge must be owner of. The Supabase pg_dump and pg_restore guide covers the exact flags and how to verify nothing dropped. Copying only the security layer? Copy RLS policies between Supabase projects drills into that.
When you should transfer the project instead
If you don't actually need two copies - you're handing the project to another org, a client, or a new company account - use the official Project Transfer in the source project's General settings. It moves the whole project (database, storage, functions, config) intact, so there's nothing to reconcile afterward. You must be a member of both organizations, and it's a move, not a duplicate: the project leaves the source account. For region- and org-level moves and their limits, see Migrate a Supabase project to another region or org.
What doesn't come across automatically
No matter which copy method you pick, these need attention in the new account:
- Secrets and API keys - never copied by any method; always manual.
- Storage objects and settings - not in the official restore; native in SupaClone, or download-and-reupload manually.
- Edge functions - redeploy via CLI, or include them natively in SupaClone.
- Auth settings and redirect URLs - reconfigure per environment; SupaClone can copy auth config (not secrets).
- Realtime - re-enable per table.
The Copy Supabase Storage buckets & edge functions post walks through the storage and functions pieces in detail.
FAQ
Can you move a Supabase project to another account?
Yes. To move the same project between organizations, use Supabase's Project Transfer in General settings. To land a copy in another account, create a fresh project there and restore into it with pg_dump/pg_restore, or clone the structure across accounts with SupaClone over OAuth.
Can you copy a Supabase project to another account on the free tier?
Yes - the free tier can't use the official Restore to a new project, but a manual three-pass supabase db dump and psql restore works into any fresh project. SupaClone also works on any plan because it connects through the Management API rather than physical backups.
Does copying include storage and edge functions?
Not by default. The official database restore is database-only. A manual dump copies tables and data but not storage files or edge functions. SupaClone includes Storage and Edge Functions natively - selectable per run alongside your schemas and their data.
Is transferring the same as copying?
No. A transfer moves the one project to another organization - the source no longer has it. A copy leaves the source running and creates a separate, independent project in the other account.
Are my secrets and API keys copied to the new account?
No. Secrets and API keys are never copied by any method, on purpose. With SupaClone they appear as explicit manual steps in the clone report so you can set them safely in the destination account.