# Move from Supabase Cloud to Aria

> Copy a Supabase Cloud project to Supabase on Aria: dump the database and users, copy Storage files, carry over Auth settings and switch your app.

Source: https://getaria.cloud/docs/move-from-supabase-cloud (updated 1 November 2026)

To move a Supabase Cloud project to Aria, first launch your app on Aria with a `supabase` database. Then dump the old database with the Supabase CLI, load it into the new one through a temporary owner login, copy the Storage files with a script, carry over the Auth settings, and point your app at the new address. Nothing in the old project is changed or deleted.

## What do I need?

- An Aria app that already runs with `databases: main: type: supabase`. See [Self-hosted Supabase](https://getaria.cloud/docs/supabase).
- The [aria command line](https://getaria.cloud/docs/cli), signed in.
- The Supabase CLI, Docker, and `psql` on your computer.
- Node.js 18 or newer, for the Storage copy.
- Your Supabase Cloud database password and project settings.

Aria AI or your coding agent can do the steps with you. Aria's move guide includes a prompt to give an agent.

## Where is the guide in Aria?

Open your project, go to **Database**, and choose **Move from Supabase Cloud**. It lists every step below with your own addresses filled in, and the file you need for the Storage copy.

## How do I move the database and the users?

**1. Get your Supabase Cloud connection string.** In the Supabase dashboard open your project, click **Connect**, and copy the **Session pooler** connection string. Replace the password placeholder. Aria never needs this password.

```bash
export OLD_DB_URL='postgresql://postgres.<project-ref>:<password>@aws-0-<region>.pooler.supabase.com:5432/postgres'
```

**2. Download the database.** This works on every Supabase plan.

```bash
brew install supabase/tap/supabase libpq
supabase db dump --db-url "$OLD_DB_URL" -f roles.sql --role-only
supabase db dump --db-url "$OLD_DB_URL" -f schema.sql
supabase db dump --db-url "$OLD_DB_URL" -f data.sql --use-copy --data-only
```

The data includes your auth users with their password hashes, so everyone keeps their login.

**3. Get a temporary owner login to your Aria Supabase.** Loading a whole project creates roles and schemas, so it needs owner rights. Run this and approve it in the Aria app.

```bash
export ARIA_DB_URL="$(aria db url --database main --owner)"
```

**4. Load it.** Everything runs in one transaction: either all of it loads or nothing does. The guide in Aria prints this command with the correct role name for your database; run that one if it differs.

```bash
psql --single-transaction --variable ON_ERROR_STOP=1 \
  --command 'SET ROLE postgres' \
  --file roles.sql --file schema.sql \
  --command 'SET session_replication_role = replica' \
  --file data.sql \
  --dbname "$ARIA_DB_URL"
```

## How do I copy Storage files?

The database copy brings the bucket list and each file's record, but not the files. The guide gives you a script, `copy-storage.mjs`. It copies every object of every bucket through both Storage APIs, reads the old project only, and is safe to run again. The keys come from your environment and are never written to the file.

```bash
export OLD_SUPABASE_URL='https://<project-ref>.supabase.co'
export OLD_SUPABASE_SERVICE_ROLE_KEY='<old service-role key>'
export NEW_SUPABASE_URL='<your Aria Supabase address>'
export NEW_SUPABASE_SERVICE_ROLE_KEY='<your Aria service-role key>'
node copy-storage.mjs
```

The old key is under Project Settings, then API, in Supabase Cloud. Your new one is on the Database page in Aria, and revealing it asks for your approval.

## How do I carry over the Auth settings?

Supabase Cloud keeps Auth settings in its dashboard. On Aria they come from your repository, so they survive every redeploy and any later move to a bigger server. Put them here, never in the new project's Studio:

- Sign-in providers, email templates, sign-up rules and hooks go in `supabase/config.toml`.
- Provider secrets are read with `env(NAME)`, and `NAME` is listed in `aria.yaml` under `env` with `services` set to the Supabase database's name.
- The SMTP sender goes in `auth.smtp` on the database. See [Self-hosted Supabase](https://getaria.cloud/docs/supabase).

The guide lists each setting with where it goes on Aria and whether your Supabase already has it.

## What is not copied?

- **Edge Functions and their secrets.** Commit the functions under `supabase/functions` and list their secrets in `aria.yaml`.
- **Cron jobs and webhooks that call outside URLs.** Check that each still points where it should.
- **API keys and the JWT secret.** Your Aria Supabase has its own, so people sign in again once.
- **Settings Aria cannot apply yet:** rate limits, MFA, CAPTCHA and SMS.

## How do I point my app at Aria?

Services wired with `from: main.url`, `main.anon_key` and `main.db_url` already use your Aria Supabase. Redeploy any service that still has Supabase Cloud values set by hand, and search your code for hard-coded Supabase Cloud addresses or keys.

## Coming from Firebase, Neon or another Postgres?

The setup flow has a **Bring my data** step for Supabase Cloud, Firebase, Neon, any Postgres and an old server. Each gives the dump commands and a prompt for your coding agent. For a plain Postgres, dump the schema with `pg_dump --schema-only` into `supabase/migrations` and the data with `pg_dump --data-only --inserts` into `supabase/seed.sql`, then commit them. Write rows as `INSERT` statements, because Aria runs the SQL files in your repository without psql, so `COPY ... FROM stdin` is refused. A dump too large for that is better loaded with `psql` through `aria db url --owner`, as above.

Next: [Aria AI: the AI built into Aria](https://getaria.cloud/docs/aria-ai)