# 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.

Source: https://supahost.app/kb/change-region · Updated 2026-11-11

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

1. **Create the new instance** in the region you want, on the plan you need.
2. **Create the projects** on the new instance. They get new URLs and new keys.
3. **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.
4. **Load the database dump** into the new project. This needs direct Postgres access, which is available on Business and Enterprise over the SSH tunnel:

   ```bash
   ssh -N -L 5432:127.0.0.1:5432 supahost@acme-eu.supahost.space
   # 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.

5. **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.
6. **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
7. **Switch your app** to the new project URL and keys, and update your OAuth providers' callback URLs.
8. **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.

## Related

- [Regions](/docs/platform/regions)
- [Exporting your data](/docs/platform/exports)
- [Moving off SupaHost](/docs/platform/leaving-supahost)
- [Where is my data stored?](/kb/data-location)