How to Copy or Duplicate a Supabase Project: Complete Step-by-Step Guide for Dev and Production Environments

Duplicating a Supabase project is a common requirement for teams that need reliable development, staging, or production environments. Whether you are preparing a safe space for testing new features or creating a production-ready replica of an existing setup, copying a Supabase project requires careful handling of databases, authentication settings, storage, and environment variables. This guide walks you through the process in a structured, professional way to ensure data integrity and operational stability.

TLDR: There is no one-click “duplicate project” button in Supabase, so copying a project requires manually recreating infrastructure and migrating data. You must clone the database schema, transfer data, replicate authentication settings, storage buckets, and configure environment variables. Using Supabase CLI, database dumps, and migration scripts ensures a reliable and repeatable process. Proper validation and testing are critical before declaring the new environment production-ready.

Understanding What “Copying” a Supabase Project Means

Before beginning, it is important to understand that a Supabase project consists of multiple components:

• PostgreSQL database (schemas, tables, functions, triggers, extensions)
• Authentication configuration (providers, JWT settings)
• Storage buckets and files
• Edge Functions
• API settings and keys
• Environment variables

Duplicating a project means replicating all relevant components in a new Supabase instance while preserving compatibility and integrity. This can be done for:

• Development environments (isolated testing)
• Staging environments (pre-production validation)
• Production migration (moving to a new account or region)

The approach varies slightly depending on whether you are cloning for development convenience or production deployment.

Step 1: Create a New Supabase Project

Supabase does not support direct duplication across projects. Start by creating a new project in the Supabase dashboard.

1. Log in to the Supabase Dashboard.
2. Click New Project.
3. Select your organization and region.
4. Set a secure database password.
5. Wait for the project provisioning to complete.

Important: Choose the same PostgreSQL version and region (if possible) to avoid compatibility and latency issues.

Step 2: Export the Database Schema

The database schema includes tables, views, functions, triggers, and extensions. The safest way to export it is by using pg_dump or the Supabase CLI.

Option A: Using pg_dump

pg_dump --schema-only --no-owner --file=schema.sql \
--dbname=postgresql://USER:PASSWORD@HOST:PORT/DATABASE

This command exports only the structure, without data.

Option B: Using Supabase CLI

supabase db dump --schema public > schema.sql

This method is often preferable in team environments that use migration tracking.

Step 3: Import the Schema into the New Project

Once you have exported the schema, import it into the newly created Supabase project.

psql postgresql://USER:PASSWORD@NEW_HOST:PORT/DATABASE \
-f schema.sql

After running the import:

• Verify tables and indexes were created.
• Confirm that extensions (e.g., uuid-ossp, pgcrypto) are enabled.
• Check row-level security (RLS) policies.

Failure to replicate extensions and RLS correctly is a common source of production instability.

Step 4: Migrate Data (If Needed)

If your goal is to fully duplicate production into staging or another production instance, you will also need the data.

Full Data Export

pg_dump --data-only --no-owner \
--dbname=postgresql://USER:PASSWORD@HOST:PORT/DATABASE \
> data.sql

Import Data

psql postgresql://USER:PASSWORD@NEW_HOST:PORT/DATABASE \
-f data.sql

Best Practice for Production:

• Put the source database in read-only mode temporarily.
• Perform the export during low-traffic hours.
• Validate row counts after import.

Security Warning: Be cautious when copying sensitive user data, especially across environments. Mask or anonymize data if duplicating to development.

Step 5: Copy Authentication Settings

Authentication settings do not transfer automatically. You must manually configure:

• OAuth providers (Google, GitHub, etc.)
• Redirect URLs
• Email templates
• JWT expiration policies

Navigate to Authentication → Providers in both projects and replicate the settings carefully.

If copying to production:

• Update OAuth credentials in external provider dashboards.
• Replace development callback URLs with production URLs.

Failing to update redirect URLs can break login functionality immediately after deployment.

Step 6: Replicate Storage Buckets and Files

Supabase Storage buckets must be recreated manually in the new project.

1. Go to Storage in the original project.
2. Document bucket names and access policies.
3. Create identical buckets in the new project.

To copy files:

• Download and re-upload using the dashboard (small volumes).
• Use Supabase Storage API scripts (large-scale transfers).

For production environments, automated transfer scripts are strongly recommended to avoid inconsistencies.

Step 7: Deploy Edge Functions

If your project uses Supabase Edge Functions:

supabase functions deploy FUNCTION_NAME \
--project-ref NEW_PROJECT_REF

Ensure:

• Environment variables are duplicated.
• API secrets are securely stored.
• You test each function endpoint after deployment.

Edge Functions often depend on external APIs, so verify integrations thoroughly.

Step 8: Update Environment Variables

Your frontend or backend application likely depends on Supabase project credentials:

• SUPABASE_URL
• SUPABASE_ANON_KEY
• SERVICE_ROLE_KEY

Replace these in:

• .env files
• CI/CD pipelines
• Server hosting platforms

Never reuse production service role keys in development environments.

Step 9: Validate the New Environment

Before declaring the duplication successful, perform structured validation:

• Run database integrity checks.
• Test authentication flows.
• Verify storage uploads and downloads.
• Execute Edge Functions.
• Monitor logs for errors.

In production scenarios, consider a phased rollout or blue-green deployment strategy to minimize risk.

Best Practices for Dev vs. Production Duplication

Development Environment

• Mask or seed synthetic data.
• Automate migrations via Supabase CLI.
• Reset databases frequently.

Production Environment

• Maintain strict backup procedures.
• Validate migration scripts in staging first.
• Document every configuration change.

For serious production systems, treat the duplication process as a formal change management event.

Automating the Process

For teams managing multiple environments, automation significantly reduces risk:

• Store migrations in version control.
• Use CI/CD for deploying schema changes.
• Create scripts for bucket and function deployment.

Infrastructure-as-code principles increase reproducibility and limit configuration drift between environments.

Common Pitfalls to Avoid

• Forgetting RLS policies.
• Overwriting production data accidentally.
• Missing critical extensions.
• Not updating OAuth redirect URLs.
• Hardcoding old API keys in frontend builds.

Each of these issues can cause outages, security holes, or broken user flows.

Final Thoughts

Duplicating a Supabase project is not difficult, but it requires discipline, accuracy, and a clear understanding of the system components involved. Because Supabase integrates database, authentication, storage, and serverless functions into a unified platform, each of these layers must be deliberately replicated.

For development use cases, the focus should be on safety and repeatability. For production deployments, the emphasis must shift toward data integrity, security controls, and rigorous validation. Proper planning and verification will ensure that your duplicated Supabase environment performs exactly as intended, without introducing unforeseen risks.

Handled correctly, this process becomes not just a migration task, but a foundational practice for scalable, professional application lifecycle management.