Supabase Region Migration

Move CE Pro to a new Supabase region without missing auth, storage, mobile, or stress-validation work.

AdvancedownermanagerdeveloperUpdated 2026-03-22

Supabase Region Migration

Moving CE Pro to a new Supabase project is not just a database copy.

The production stack currently depends on Supabase through:

  • web runtime envs and service-role helpers
  • hosted Auth callbacks and redirect allow-lists
  • storage buckets and signed upload/download flows
  • Supabase Edge Functions
  • mobile Supabase config and mobile function invocation

If you are migrating from the current Oregon project to a new Virginia project, use this guide as the cutover checklist and validation baseline.

Cutover Checklist

Before switching traffic:

  1. Create the new hosted project in Virginia and capture the new project ref, API URL, anon key, service-role key, and DB/pooler strings.
  2. Recreate the hosted Auth settings on the new project, including the production site_url, redirect allow-list, session limits, refresh rotation, and OTP expiry settings CE Pro expects.
  3. Apply the full schema and deploy the required Supabase Edge Functions to the new project.
  4. Recreate the storage buckets CE Pro needs and copy storage objects, not just tables.
  5. Update the web app envs, mobile envs, and any local ops/scripts that still point to the old project.
  6. Drain or pause background jobs and webhook delivery work before the final delta copy so you do not process the same workload in two places.
  7. Run smoke checks, then rerun the stress harness against the Virginia-backed stack before calling the move complete.

Repo Audit Highlights

The repo has a few migration-sensitive surfaces worth calling out explicitly.

Web app

The main web runtime is env-driven, so the core cutover values are:

  • NEXT_PUBLIC_SUPABASE_URL
  • NEXT_PUBLIC_SUPABASE_ANON_KEY
  • SUPABASE_SERVICE_ROLE_KEY

Those values drive the shared Supabase bootstrap paths, auth callback route, middleware session handling, direct proposal-view tracking, and script helpers.

Mobile

The mobile app has its own Supabase coupling and should be treated as a first-class migration surface.

  • The runtime reads EXPO_PUBLIC_SUPABASE_URL and EXPO_PUBLIC_SUPABASE_ANON_KEY.
  • The current mobile/eas.json still contains the old Oregon project ref URL.
  • The mobile app invokes Supabase Functions directly, including send-proposal.

If the mobile build or EAS secrets stay pointed at Oregon, the migration is only half-done.

Auth redirects

CE Pro generates hosted auth links for:

  • password reset
  • team invite/setup
  • customer magic-link login
  • super-admin reset flows

That means the new Supabase project must have the correct hosted redirect allow-list for the production app origin and the /auth/callback and /auth/complete flows CE Pro uses.

Storage buckets

At minimum, verify:

  • job-photos
  • record-attachments
  • bug-report-screenshots

Some of these are called out in repo migrations as manual bucket-creation steps on a fresh project, so do not assume db push alone makes storage ready.

Post-migration Validation

Run this in order:

  1. GET /api/health
  2. admin login, customer login, forgot-password, and invite flows
  3. admin Jobs, Invoices, Services, Lead Sources, and Tags reads
  4. job-photo and attachment upload/download
  5. proposal send and proposal-view tracking
  6. webhook smoke tests for the providers you actively use

Also verify:

  • background-job queue health
  • webhook-delivery health
  • no missing Edge Functions on the new project

Stress Test Rerun

After the smoke checks, rerun the same stress harness used during the scale-hardening work.

Small shakeout:

STRESS_BASE_URL=https://cleanestimate.pro \
STRESS_ADMIN_COOKIE_FILE=.secrets/va-admin-cookies.txt \
STRESS_CRON_SECRET=replace-me \
npm run test:stress -- --stages='[{"name":"shakeout","sessions":10,"durationSec":120}]'

Then the full 1k-ready profile:

STRESS_BASE_URL=https://cleanestimate.pro \
STRESS_ADMIN_COOKIE_FILE=.secrets/va-admin-cookies.txt \
STRESS_CRON_SECRET=replace-me \
npm run test:stress

The March 22, 2026 stabilized Oregon-backed baseline was:

  • error rate 1.70%
  • overall p95 2465ms
  • health p95 351ms

The Virginia cutover should at minimum preserve correctness and improve that latency ceiling.

Was this article helpful?

Still need help? Contact support