Migrate from Bolt.new to Supabase

If your Bolt.new project uses Supabase for its backend — database, auth, storage, or edge functions — this guide walks you through migrating everything to a Supabase project you own. You'll retain full control of your data and won't depend on Bolt's managed infrastructure.

Approach

Automated Migration

Recommended

Staticbot automates the entire pipeline — schema, data, edge functions, storage, and auth — through a guided dashboard. No CLI required.

~15 min with automationStart automated migration

Manual Migration

Follow the steps below to migrate your Supabase backend yourself using the CLI and Supabase dashboard. Full control, requires developer time.

~2–3 hours depending on data volume

?Is Your Bolt App Using Supabase?

Bolt often scaffolds apps using Supabase, but not always. Confirm before proceeding.

A. Check your dependencies

Open package.json and look for:

"@supabase/supabase-js"

Or in your source files:

import { createClient } from '@supabase/supabase-js'

B. Check your environment variables

Look in .env or .env.example for:

SUPABASE_URL= SUPABASE_ANON_KEY= VITE_SUPABASE_URL= NEXT_PUBLIC_SUPABASE_URL=

C. Check the API URL in use

If the URL looks like https://xxxxx.supabase.co, that's a Supabase backend.

If any of the above match → proceed with this guide. If not, your Bolt app may use a different backend and these steps don't apply.

1Create Your Own Supabase Project

Go to supabase.com and create a new project
Choose a region close to your users
Once created, save these values from Project Settings → API:

SUPABASE_URL=https://<project-ref>.supabase.co SUPABASE_ANON_KEY=eyJ... SUPABASE_SERVICE_ROLE_KEY=eyJ...

Keep the service role key secret — it bypasses all Row-Level Security policies. Never expose it in client-side code.

2Export the Database from Bolt's Supabase Project

You need the database connection string from the source project. Go to Project Settings → Database → Connection string (use the URI format).

Option A — Supabase CLI (recommended)

Install the CLI if you haven't already:

npm install -g supabase

Dump the full schema and data:

supabase db dump --db-url "postgresql://postgres:[PASSWORD]@db.[PROJECT-REF].supabase.co:5432/postgres" -f dump.sql

To export schema only (without data):

supabase db dump --db-url "..." --schema-only -f schema.sql

Option B — SQL Editor (manual)

Open the source project's SQL Editor and export individual tables using SELECT * queries. For schema, use the Table Editor's built-in export or copy the migration files from your repo.

If your Bolt project has a supabase/migrations/ folder, those SQL files are your schema source of truth — you can apply them directly to the new project without dumping.

3Import the Schema into Your New Project

Link the CLI to your new project and apply the schema:

Link your local Supabase CLI to the new project:

supabase link --project-ref <NEW_PROJECT_REF>

If you have migration files in your repo:

supabase db push

If you're using a SQL dump file:

# Open SQL Editor in new project → paste dump.sql contents and run

Or via psql if you have direct access:

psql "postgresql://postgres:[PASSWORD]@db.[NEW-REF].supabase.co:5432/postgres" < dump.sql

Verify all tables are present in the new project's Table Editor before proceeding.

4Migrate Auth Configuration

Auth settings are not exported by a standard DB dump. You need to manually recreate them in your new project.

Recreate in Authentication → Settings:

Enable the same OAuth providers (Google, GitHub, etc.)
Set the same redirect URLs
Copy JWT expiry and refresh token settings
Recreate email templates if you customized them

Migrating users (optional)

If your app has existing users you want to preserve, export them from the source project using the service role key:

select * from auth.users;

Password hashes can be re-imported and will continue to work. OAuth users will need to re-authenticate after migrating (their OAuth provider link is project-specific).

Don't forget RLS policies

Row-Level Security policies are stored in the database and are included in a full dump. If you ran schema-only, verify they were copied:

select * from pg_policies;

5Update Your App's Environment Variables

Replace the Bolt-managed Supabase credentials in your project with your new project's credentials.

Update your .env file:

SUPABASE_URL=https://<new-project-ref>.supabase.co SUPABASE_ANON_KEY=<new-anon-key>

If using the Supabase JS client, it picks up the env vars automatically:

import { createClient } from '@supabase/supabase-js' const supabase = createClient( process.env.SUPABASE_URL!, process.env.SUPABASE_ANON_KEY! )

If you have a supabase/config.toml, update the project reference:

project_id = "<new-project-ref>"

6Migrate Storage Buckets

Storage files are not inside the Postgres database. You need to recreate buckets and re-upload files manually.

1. Recreate buckets in the new project

Go to Storage → New bucket in your new project and recreate each bucket with the same name and public/private setting.

2. Transfer files

For small storage: download files from the old project's dashboard and re-upload to the new one.

For larger storage, use a script with the service role key:

// List files in source bucket const { data } = await oldSupabase.storage .from('your-bucket') .list() // Download each file and re-upload to new project for (const file of data) { const { data: fileData } = await oldSupabase.storage .from('your-bucket') .download(file.name) await newSupabase.storage .from('your-bucket') .upload(file.name, fileData) }

Use the service role key for both old and new Supabase clients in this script — it bypasses storage RLS for bulk operations.

7Verify Row-Level Security

RLS misconfiguration is the most common cause of migration failures. Verify everything is correct before going live.

Confirm RLS is enabled on all tables that need it:

select tablename, rowsecurity from pg_tables where schemaname = 'public';

List all policies in the new project:

select tablename, policyname, cmd, qual from pg_policies where schemaname = 'public';

Test access patterns:

Anonymous access — can only read what should be public
Authenticated user access — users can only see their own rows
Admin/service role access — bypasses RLS (confirm this is intentional)

Common mistakes

RLS policies exist in source but weren't copied to the new project
Service role key mistakenly used client-side (bypasses all security)
Tables have RLS enabled but no policies — blocks all access

8Redeploy Your App

Update environment variables in your hosting platform and redeploy.

Vercel / Netlify / Cloudflare Pages

Go to project settings → Environment variables
Update SUPABASE_URL and SUPABASE_ANON_KEY to new values
Trigger a redeploy

After deploying, open the app in an incognito window and test a full user flow — sign up, sign in, data read/write, file upload — against the new project.

Migration Checklist

New Supabase project created

Database schema migrated

RLS policies copied and verified

Auth providers configured

Redirect URLs set

JWT settings matched

Storage buckets recreated

Files transferred

Environment variables updated

App redeployed

Anonymous access tested

Authenticated user access tested

File uploads working

No service key exposed client-side

Ready to Deploy the Frontend?

Now that your backend is on your own Supabase project, host the frontend on AWS with no configuration using Staticbot.

View Bolt.new Deployment Guide

Fully Automated

Skip the manual steps — migrate in 15 minutes

Staticbot's automated migration pipeline handles Bolt.new projects end-to-end — schema, data, edge functions, storage, and auth config, all migrated through a guided dashboard with no CLI required.

Start Automated Migration