Move from Supabase Cloud to Aria

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.
• The aria command line, 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.

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.

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.

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.

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.

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.

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.