How to Copy a Supabase Project? A Step-by-Step Guide

Published On - February 19, 2026

ivan Blogging

Copying a Supabase project is not as simple as pressing a single button. Because Supabase combines a managed PostgreSQL database, authentication, storage, edge functions, and configuration settings into one platform, duplicating a project requires careful planning and execution. Whether you are creating a staging environment, migrating between organizations, or preparing a backup, understanding the proper process ensures that nothing critical is lost.

TL;DR: To copy a Supabase project, you must duplicate its database, authentication settings, storage buckets, edge functions, and environment variables separately. Start by exporting your database schema and data, then create a new Supabase project and import everything methodically. Reconfigure authentication providers, storage policies, and secrets manually. Always test the cloned project thoroughly before moving it to production.

This step-by-step guide explains how to safely and reliably replicate a Supabase project while maintaining data integrity and operational stability.

Understanding What “Copying” a Supabase Project Means

Before beginning, it is essential to clarify what is involved in “copying” a Supabase project. Unlike simple hosting environments, Supabase projects consist of multiple integrated components:

  • PostgreSQL Database (schemas, tables, functions, triggers, extensions)
  • Authentication (users, providers, JWT settings)
  • Storage (files and bucket configurations)
  • Edge Functions
  • API settings and secrets
  • Row Level Security (RLS) policies

There is currently no one-click “clone project” feature. Therefore, copying a project requires systematically exporting and recreating each component.

Step 1: Export the PostgreSQL Database

The database is the core of your Supabase project. Properly exporting both schema and data is the most critical step.

There are two primary approaches:

Option A: Using pg_dump (Recommended)

This method provides the most complete and reliable export.

  1. Retrieve your database connection string from the Supabase dashboard.
  2. Use the pg_dump command:
pg_dump -h HOST -U USER -d DATABASE -F c -f backup.dump

This command creates a custom-format backup file including:

  • All schemas
  • Tables and data
  • Indexes and constraints
  • Functions and extensions
Image not found in postmeta

Option B: Using Supabase CLI

If you are working locally with migrations:

supabase db dump --file backup.sql

The CLI approach is useful when your project is already migration-driven.

Important: Ensure that extensions (such as uuid-ossp or pgcrypto) used in your project are noted. These must exist in the new environment as well.

Step 2: Create a New Supabase Project

Once you have backed up your database, create a new project:

  1. Log in to the Supabase dashboard.
  2. Click New Project.
  3. Select your organization.
  4. Choose region and pricing plan.
  5. Set a secure database password.

Be mindful to choose the appropriate geographic region. Changing regions later requires another migration.

Image not found in postmeta

After creation, wait until the database is fully provisioned before proceeding.

Step 3: Import the Database into the New Project

With your new project live, you can now restore the database.

Using pg_restore

pg_restore -h NEW_HOST -U NEW_USER -d NEW_DATABASE backup.dump

This restores:

  • Tables and records
  • Constraints and indexes
  • RLS policies
  • Stored procedures

After restoration, verify:

  • All tables are present
  • Row counts match the original
  • Indexes were recreated

Best Practice: Run a quick integrity check by querying key tables and testing critical joins.

Step 4: Reconfigure Authentication

Supabase authentication settings are not automatically copied with the database dump. You must configure them manually in the new project.

Go to:

  • Authentication → Providers

Re-enable and configure:

  • Email/password login
  • OAuth providers (Google, GitHub, etc.)
  • Password policies

If you used OAuth providers, remember:

  • Update callback URLs to reflect the new project URL
  • Ensure redirect URIs are correct

If you are copying users, those records exist in the auth.users table (if backed up properly). However, you should test login flows immediately after restoration.

Step 5: Copy Storage Buckets and Files

Supabase storage data is not stored directly in your database export. Buckets and objects must be copied separately.

Steps to copy storage:

  1. List all buckets in the original project.
  2. Recreate the same bucket structure in the new project.
  3. Download files via API or CLI.
  4. Upload files into the new project.

You can automate this process using scripts that leverage the Supabase storage client.

Important:

  • Reapply storage policies manually.
  • Confirm file permissions and public/private settings.

Step 6: Deploy Edge Functions

If your project uses Edge Functions, you must redeploy them to the new project.

Using the Supabase CLI:

supabase functions deploy FUNCTION_NAME --project-ref NEW_PROJECT_REF

Verify:

  • Environment variables are correctly set
  • Secrets are reconfigured
  • Functions trigger correctly

Edge function secrets do not automatically transfer. Re-enter API keys and private credentials via the dashboard.

Step 7: Review Row Level Security (RLS)

Although RLS policies are included in database dumps, it is essential to test them explicitly after migration.

Confirm:

  • Authenticated users retain proper access
  • Public routes behave as expected
  • No unintended exposure exists

Test using both authenticated and unauthenticated sessions.

Step 8: Update Environment Variables in Your Application

Your frontend or backend application likely references:

  • Project URL
  • Anon public key
  • Service role key

Replace these with credentials from the new project. You can find them under:

  • Settings → API

Failure to update these credentials will result in authentication errors or broken API requests.

Step 9: Conduct Comprehensive Testing

Before using the copied project in production, perform structured testing:

  • User registration and login
  • CRUD operations
  • File uploads and downloads
  • Edge function execution
  • RLS enforcement

Ideally, run automated integration tests if available.

Recommended Approach: Treat the copied project as a staging environment first. Monitor logs for errors that might not surface immediately.

Common Pitfalls to Avoid

  • Forgetting to copy extensions
  • Missing storage files
  • Incorrect OAuth redirect URLs
  • Unconfigured environment secrets
  • Region mismatch causing latency issues

Careful documentation reduces these risks significantly.

When to Use Supabase Migrations Instead

If you regularly duplicate environments (for example, development, staging, production), consider adopting a migration-based workflow.

With migrations:

  • Schema changes are version-controlled
  • Deployments become repeatable
  • Database state remains consistent

This is the most professional and scalable method for managing multiple Supabase environments.

Final Thoughts

Copying a Supabase project is a deliberate process that demands attention to every system component. While there is no one-click solution, following a structured step-by-step method allows you to safely replicate your database, authentication, storage, and backend logic.

The key principles are straightforward: export carefully, import methodically, reconfigure manually, and test thoroughly. When approached seriously, duplicating a Supabase project becomes a controlled technical procedure rather than a risky operation.

For teams managing production systems, documenting your copy process and incorporating migrations into your workflow will provide long-term reliability and operational confidence.