# Self-hosted Supabase on Aria

> Run your own Supabase on Aria: Postgres, Auth, REST, Realtime, Storage and Studio on your server, wired into your app, at no extra cost.

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

To run Supabase on Aria, add one database of type `supabase` to `aria.yaml` and wire its address and keys into your services with `from`. Aria installs the official self-hosted Supabase stack on your own server: Postgres, Auth, the REST API, Realtime, Storage, Studio and edge functions. Supabase is included at no extra cost. It runs on the server your plan already pays for.

The overview of what Aria runs for you, and how it differs from Docker Compose and from Supabase Cloud, is [Self-hosted Supabase, managed for you](https://getaria.cloud/self-hosted-supabase).

## How much server does Supabase need?

Supabase needs about 4 GB of memory on its own, before your app and its builds. Start on the Developer plan or bigger. Aria adds Supabase to its memory estimate, so the plan it suggests already has room.

## How do I add Supabase to aria.yaml?

```yaml
version: 1
name: my-app
services:
  web:
    type: web
    port: 3000
    healthcheck: /
databases:
  main:
    type: supabase
env:
  NEXT_PUBLIC_SUPABASE_URL:
    services: [web]
    from: main.url
    build: true
  NEXT_PUBLIC_SUPABASE_ANON_KEY:
    services: [web]
    from: main.anon_key
    build: true
  SUPABASE_SERVICE_ROLE_KEY:
    services: [web]
    from: main.service_role_key
  DATABASE_URL:
    services: [web]
    from: main.db_url
```

What you can read from a Supabase database:

| Attribute | What it is |
|---|---|
| `url` | The public API address. Use it in browser code. |
| `anon_key` | The public key. Safe in a browser. |
| `service_role_key` | The all-powerful key. Server code only, never a `NEXT_PUBLIC_` variable. |
| `internal_url` | The address other services on your server use. |
| `db_url` | The Postgres connection string. |
| `public_host` | The public address without `https://`. |
| `jwt_secret` | The secret that signs Supabase tokens. |

Aria generates the keys and the database password. You never choose them.

## How does Aria build my schema?

Keep a `supabase/` folder in your repository, laid out like the Supabase CLI's:

```text
supabase/
  config.toml
  migrations/20250101000000_profiles.sql
  seed.sql
  functions/hello/index.ts
```

On every launch and every push Aria applies the migrations in order, each once. It runs `seed.sql` once, on a new database. It deploys each folder under `functions/` that holds an `index.ts` or `index.js`, and it applies the auth settings and storage buckets in `config.toml`. Settings Aria cannot apply yet, such as rate limits, MFA, CAPTCHA and SMS, are reported but not applied.

If your folder is not called `supabase`, set `path` on the database. With two Supabase databases, each needs its own `path`. To stop `seed.sql` from running, set `seed: false`.

Make changes in your repository, not in Studio. Aria applies the repository on every deploy, so a setting changed by hand in Studio can be overwritten.

## How do edge function secrets work?

List the secret under `env` and give it the Supabase database's name as its `services`:

```yaml
env:
  OPENAI_API_KEY:
    services: [main]
    required: true
    secret: true
    description: For the summarise function
```

Edge functions already receive `SUPABASE_URL`, `SUPABASE_ANON_KEY`, `SUPABASE_SERVICE_ROLE_KEY` and `SUPABASE_DB_URL`, so do not list those. Names that Supabase uses itself, such as anything starting with `SUPABASE_`, `SERVICE_`, `GOTRUE_` or `ARIA_`, and names like `JWT_SECRET`, `POSTGRES_PASSWORD`, `SITE_URL` and `SMTP_HOST`, are refused. Pick another name. A variable that `config.toml` reads with `env(NAME)`, such as a sign-in provider's secret, is listed the same way. Until it has a value, that provider stays off.

## How do I send real sign-up and password-reset email?

Add `auth.smtp` to the database. The password is a secret that you enter in Aria. It is never in the file.

```yaml
databases:
  main:
    type: supabase
    auth:
      smtp:
        host: smtp.resend.com
        port: 465
        user: resend
        password_secret: SMTP_PASSWORD
        sender: no-reply@example.com
        sender_name: Example
```

| Field | Default | What it does |
|---|---|---|
| `host` | required | Your provider's SMTP host. |
| `port` | 587 | `587` (STARTTLS) or `465` (TLS). |
| `user` | required | The SMTP login. |
| `password_secret` | required | The name of the secret holding the password or API key. |
| `sender` | required | The From address, on a domain your provider has verified. |
| `sender_name` | the app's name | The From name people see. |

Instead of `auth.smtp`, you can turn on [Aria Mail](https://getaria.cloud/docs/mail), which Aria wires into Auth when `auth.smtp` is not set. With either, new sign-ups must confirm their email unless `config.toml` turns confirmations off. If the seed inserts into `auth.users`, Aria's launch preview warns you, because demo users on a live database are rarely what you want. Without SMTP, Auth's email goes to the test inbox when `email: { enabled: true }` is on, and otherwise nowhere, with sign-ups confirmed automatically.

## How do I look inside the database?

Run this and approve it in the Aria app. You get a connection string for a temporary login that removes itself.

```bash
aria db url --database main
```

Add `--read-only` for a login that cannot write, or `--owner` for owner rights, which an import needs. The Database page in the dashboard shows the Supabase address, the keys (revealing a secret key asks for your approval) and **Copy database**, which makes a zip with a dump. Its **Users** and **Storage** tabs list the people who sign in and your files, and what you delete there waits 30 days in the Archive. See [Your data](https://getaria.cloud/docs/data).

## How do I check that Supabase works?

```bash
aria check
```

It tests the gateway, Auth, REST, Storage, Realtime, HTTPS and Auth's email, and exits with code 1 if anything fails.

## Is Supabase backed up?

Yes. A Supabase is backed up every night with its Storage files as part of your app. To bring it back, rebuild from Settings, then Recovery. See [Backups](https://getaria.cloud/docs/backups).

Next: [Move from Supabase Cloud to Aria](https://getaria.cloud/docs/move-from-supabase-cloud)