Migrate from Base44 to Supabase manually

This is the manual, do-it-yourself path for variant B (BYO-Supabase). The automated Staticbot migration is free and takes ~15 minutes.

The 8 CLI steps below give you full control at the cost of a few hours of developer time. If you'd rather not run commands by hand — or you're on variant A (SDK-native with @base44/sdk), which has no sensible manual walkthrough — Staticbot automates the whole migration for free.

Automated guide

Manual migration · variant B

Manually move your Base44 + Supabase app to your own Supabase (8 steps)

~2–3 hours

These manual steps cover variant B (BYO-Supabase).

Your code already uses @supabase/supabase-js with VITE_SUPABASE_URL set as a Base44 platform secret. You're moving your existing Supabase data + functions to a new Supabase project you own. The steps below use the Base44 CLI + Supabase CLI + pg_dump.

Variant A (SDK-native with @base44/sdk) doesn't have a sensible manual walkthrough — entity-schema translation, the shim wiring, and the per-entity REST data fetch are too much to drive by hand. Use the automated path for variant A; it handles all of it end-to-end and you still see every step in the dashboard before confirming.

Prerequisites

A new (empty) target Supabase project created at supabase.com
Supabase CLI installed (npm i -g supabase) and authenticated
Base44 CLI installed (npm i -g @base44/cli) and logged in via base44 login
psql available locally (ships with PostgreSQL client)
Your Base44 project's GitHub repo cloned locally

1Find your source Supabase credentials

Your Base44 platform secrets contain the VITE_SUPABASE_URL + anon key you need. The service-role key is only available from the Supabase dashboard.

List Base44 secrets

From your project root:

base44 link # if not yet linked
base44 secrets list

Values are masked. To copy the actual value, use the Base44 dashboard (Settings → Secrets) or set them via base44 secrets set on a different env to read back.

Source Supabase dashboard

Open https://supabase.com/dashboard/project/<ref> (where <ref> is from VITE_SUPABASE_URL) → Project Settings → API. Note both:

service_role key — needed for dumping with full privileges
Database connection string (Project Settings → Database) — for pg_dump

2Link the Supabase CLI to your new target project

Replace <new-project-ref> with the ref of the empty Supabase project you created:

cd your-base44-repo
supabase link --project-ref <new-project-ref>

The CLI reads your repo's supabase/config.toml. If project_id is set there, update it to the new ref too so future supabase commands stay pointed at the right project.

3Push the database schema

Apply every SQL migration in supabase/migrations/ to the target:

supabase db push

Heads up: Base44 lets you run SQL in the Supabase SQL Editor without committing migration files

If you (or Base44's AI) ever applied schema changes directly via the SQL Editor on source without writing them into supabase/migrations/, those changes are missing from the repo and won't be pushed. Diff source vs target before moving on:

supabase db diff --linked # compares your linked target with repo state

4Deploy your edge functions

Deploy every function under supabase/functions/ to your new Supabase project:

supabase functions deploy

Base44 backend functions vs Supabase edge functions

Functions you defined via Base44 (base44 functions list) run on Base44's infrastructure, not on your source Supabase. After migration they keep working as long as your Base44 app exists. To move them onto your own Supabase as proper edge functions, re-export each one's source and re-author it inside supabase/functions/, then deploy via supabase functions deploy.

base44 functions pull # pulls function source for inspection

5Migrate data (with passwords intact)

Don't use CSV exports for this

Exporting tables as CSV from Supabase → Table Editor strips bcrypt password hashes from auth.users.encrypted_password, which forces every one of your users to reset their password. Use pg_dump instead — it preserves the hashes verbatim and gets foreign-key ordering right.

Dump source data with pg_dump

From the source Supabase dashboard (Settings → Database), copy the connection string and:

pg_dump --data-only --no-owner --no-privileges \
--schema=auth --schema=public --schema=storage \
"$SOURCE_DATABASE_URL" > data.sql

This dumps auth.users (including encrypted_password), auth.identities (OAuth links), all public-schema rows, and storage metadata — in the right dependency order.

Restore to your new Supabase

Grab the target's connection string from Supabase → Project Settings → Database and apply the dump:

psql "$TARGET_DATABASE_URL" -v ON_ERROR_STOP=1 -f data.sql

Existing users sign in with their existing passwords — no reset email. Storage object files (the actual bytes in buckets) aren't in this dump; copy them separately via the Supabase CLI or rclone against the S3-compatible storage endpoint.

6Reconfigure OAuth providers

Google/GitHub/Apple OAuth client IDs and secrets live in Supabase's auth control plane, not in the database — pg_dump doesn't carry them. In your new project's dashboard go to Authentication → Providers and re-enter each provider's client ID, secret, and redirect URL. The matching auth.identities rows are already restored from Step 5, so once providers are configured, OAuth users continue signing in without re-authorising.

Update OAuth callback URL on the provider side too

Each OAuth provider (Google Cloud Console, GitHub OAuth Apps, etc.) needs the new https://<new-ref>.supabase.co/auth/v1/callback added as an allowed redirect URI. Without that, OAuth sign-in fails with "redirect_uri_mismatch".

7Update Base44 platform secrets to point at your new Supabase

Base44 reads VITE_* values from its platform secrets store at build time — not from .env in the repo. Updating the repo alone has no effect. Use the Base44 CLI to swap the values:

base44 secrets set \
VITE_SUPABASE_URL=https://<new-ref>.supabase.co \
VITE_SUPABASE_ANON_KEY=<new-anon-key>

Per the Base44 CLI docs, any deployed backend functions that reference these secrets are automatically redeployed when you change them. The frontend bundle, however, only picks up the new values on the next deploy — covered in Step 8.

Alternative: ask Base44's AI

In the Base44 chat: "Set secrets: VITE_SUPABASE_URL=<url>, VITE_SUPABASE_ANON_KEY=<key>." Base44 will use its set_secrets tool — same end result as the CLI.

8Redeploy and verify

Deploy the whole project

base44 deploy

Rebuilds the frontend with the new VITE_SUPABASE_* values baked in, and redeploys backend functions + entities + site assets.

Verify in the browser

Open your *.base44.app URL in an incognito window. In DevTools → Network, confirm requests are hitting https://<new-ref>.supabase.co, not the old project. Sign in with an existing user to confirm password hashes survived.

Optional: archive the source Supabase project

Once you've verified everything works against the new project, pause or delete the old source Supabase project so you stop being billed for it.

Post-Migration Checklist

New Supabase project created

Schema pushed via supabase db push

Edge functions deployed

Data restored (with password hashes)

Storage objects copied to new project

OAuth providers reconfigured (both sides)

Base44 secrets updated

base44 deploy run successfully

Live app verified against new backend (incognito test)

Existing user can sign in without reset

Rather not run commands?

Staticbot does all 8 steps for you — free

Skip the CLI dance: paste your *.base44.app URL, connect your GitHub repo, and confirm each phase in a guided dashboard. Works for both variant A (SDK-native) and variant B (BYO-Supabase). Migrations are free.

See the automated guide Start a free migration