Changing an instance's region

A SupaHost instance's region can't be changed after it's created. How to move projects to a new instance in another region, and what to recreate afterwards.

You can't change the region of an existing SupaHost instance. The region is fixed when the instance is created, because the instance is a VM with its disk, static IP address and backups in that region. To move, you create a new instance in the region you want and move your projects across.

Available regions

US Central, US West, US East, Belgium, London, Frankfurt, Singapore, Sydney and Tokyo. You can see your current region on Dashboard → Instance, and on each project's Overview and Settings tabs.

Is it worth moving?

Pick the region closest to where your app's server code runs, not necessarily your users. If your app runs on Vercel or another host, the database calls from that host make up most of the latency. A region change helps most when your backend and your database are on different continents. If your app talks to SupaHost straight from the browser, choose the region nearest most of your users.

How to move to another region

Create the new instance in the region you want, on the plan you need.
Create the projects on the new instance. They get new URLs and new keys.
Export each project from the old instance: on the project's Backups tab, click Create pg_dump for the database and Package files for Storage. Download both; links last 24 hours.
Load the database dump into the new project. This needs direct Postgres access, which is available on Business and Enterprise over the SSH tunnel:
```
ssh -N -L 5432:127.0.0.1:5432 [email protected]
# in a second terminal:
pg_restore --list app-one-20261111-0930.dump | head
```
A new project already contains the Auth, Storage and other Supabase schemas, so a straight pg_restore of the whole dump reports objects that already exist. Review what you restore and check the errors it prints. If the new instance isn't on Business, or you'd rather not do this by hand, email support before you start so the move can be planned with you.
Upload the files. The Storage archive contains every file plus buckets.json and objects.json describing buckets and metadata. Recreate the buckets with the same settings, then upload each file to the same path in the new project.
Recreate what isn't in the database dump:
- Auth settings on the Auth tab: App name, Site URL, Redirect URLs, sign-in options, email templates and OAuth providers
- Edge Functions and their secrets on the Functions tab
- Cron jobs on the Cron tab
- Custom domains on the Domains tab
- Team members and access tokens
Switch your app to the new project URL and keys, and update your OAuth providers' callback URLs.
Terminate the old instance once everything works, from Dashboard → Instance → Terminate.

What changes for your users

The new project has its own JWT secret, so existing sessions aren't valid there and users sign in again once. Auth users live in the database (the auth schema), so when they come across with your data, their existing passwords keep working.

If you use a custom domain for the API, you can move it to the new project and keep the same URL in your app. Remove it from the old project first, because a hostname can only belong to one project at a time.

On SupaHost

Keep writes to the old project paused during the move, or anything written after the export is lost.
Daily backups stay in the instance's region. They don't move with you, so take your own exports before terminating.
Terminating sends a request to SupaHost rather than deleting the instance on the spot.

Updated 11 November 2026 · View as Markdown · Something wrong or missing? Tell us