Self-hosted Supabase in production: the checklist

Before self-hosted Supabase carries real users, change every default secret, put HTTPS in front of the gateway, configure real email, set up backups and test a restore, and decide how you will upgrade. The official Docker guide covers the setup. It says nothing about backups, and it leaves monitoring, high availability and security hardening to you. This checklist goes through what to do, in the order that hurts least if you skip it. It is based on Supabase’s documentation, read on 31 October 2026.

If you have not chosen a server size yet, start with Supabase self-hosting requirements. If you are still deciding whether to self-host, read the self-hosting guide. We build Aria Cloud, which runs Supabase for you, and a short section near the end says what it covers.

What does Supabase say you are responsible for?

The self-hosting overview lists it: server provisioning and maintenance, security hardening and updates, service configuration, Postgres maintenance, high availability and scalability, backups and disaster recovery, and monitoring and uptime. Support is community-based. Some platform features are missing: branching, managed backups and point-in-time recovery, the Management API, and Studio does not support multiple projects. Everything below follows from that list.

The checklist

1. Replace every default secret

• Run sh utils/generate-keys.sh to generate secure passwords and secrets, then sh utils/add-new-auth-keys.sh to add the new API keys and key pair.
• Set DASHBOARD_PASSWORD. The guide says a secure password must be set before starting Supabase, and Studio sits behind HTTP basic authentication.
• Keep .env out of Git. The guide strongly recommends a secrets manager for production.
• Check VAULT_ENC_KEY (exactly 32 characters) and SECRET_KEY_BASE (at least 64) are set, because Supavisor and Realtime use them.

The example .env is for trying things out. Production needs your own values (Docker guide).

2. Put HTTPS in front

• Run a reverse proxy such as Caddy or Nginx on port 443 in front of the gateway. The guide recommends HTTPS in production, especially for OAuth providers.
• Point a domain at the server and set the public URL variables to match.
• Open only 80 and 443 to the internet. Keep the database off the public network.
• Keep Studio private if you can. Anyone who reaches the dashboard login can try the password.

3. Send real email

• Set SMTP_ADMIN_EMAIL, SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS and SMTP_SENDER_NAME in .env, then restart the services. The guide recommends AWS SES.
• Use port 465 or 587, the ports mail providers expect for authenticated sending.
• Sign up with a test address and click the confirmation link or magic link. Do this before launch.

4. Back up the database, and prove you can restore

The Docker guide does not mention backups. This is the largest gap.

• Take a logical dump on a schedule. PostgreSQL’s pg_dump makes a consistent snapshot without blocking other operations (PostgreSQL docs):

docker compose exec -T db pg_dump -U postgres -Fc postgres > supabase-$(date +%F).dump
docker compose exec -T db pg_dumpall -U postgres --globals-only > globals-$(date +%F).sql

The service is usually called db in the compose file. Check yours. The second command matters: pg_dump dumps one database and does not include roles, which pg_dumpall --globals-only covers.

• Copy the dumps off the server, to storage you do not run on the same machine. A backup on the same disk is not a backup.
• Back up the Storage files. By default Storage keeps files on a local bind mount, or you can use an S3-compatible backend (Docker guide). Dumps do not contain them.
• Restore into a scratch Postgres and check row counts. With pg_restore you can restore selectively from a custom-format dump. If you restore a plain dump with psql, use --single-transaction and ON_ERROR_STOP so a failure leaves nothing half-done.
• Write down how long a restore takes. That is your real recovery time.

5. Plan upgrades before you need one

• Supabase publishes stable snapshots of the Docker Compose setup roughly monthly, and the images can lag behind Docker Hub.
• update.sh pulls the latest configuration and merges it into your files with a three-way merge. Read the merge result before you restart.
• Do not change single image tags casually. The guide says compatibility with mixed tags is not guaranteed.
• Rehearse every upgrade on a restored copy first.
• Never run reset.sh on a live server. It deletes the Postgres data directory and Storage data.

6. Know your Postgres version

The platform may run Postgres 17 while the self-hosted Docker image defaults to Postgres 15, according to the restore guide. If you plan to move data in from the hosted service, see what really moves.

7. Rotate credentials

• sh utils/db-passwd.sh generates a new database password, updates all database roles and .env. Then run sh run.sh recreate.
• sh utils/rotate-new-api-keys.sh --update-env rotates the publishable and secret API keys without changing the signing key pair, and existing user sessions remain valid. Then run sh run.sh recreate.
• Put a date in the calendar. Rotation you never schedule is rotation you never do.

8. Watch memory and logs

• Logging is optional. sh run.sh config add logs adds Logflare and Vector and the log explorer in Studio, and increases resource needs.
• Watch free memory and container restarts. When a container goes over what the machine has, the Linux out-of-memory killer ends a process (Docker docs).
• Alert on disk use. Postgres, Storage and logs all grow.

9. Handle Edge Functions deliberately

• Functions live under volumes/functions/<name>/index.ts. Add one, then run sh run.sh restart functions.
• Put secrets in .env.functions, reference it with env_file, and add the file to .gitignore.
• Remember the limits. The guide lists defaults of 150 MB per worker and an idle request timeout of 150 seconds (self-hosted functions). A standalone instance resembles ordinary serverless, not the hosted service’s multi-region deployment.

10. Decide on availability

There is no high availability in the Docker guide. One server means one point of failure. Decide what downtime you can accept, and write down the restore steps for the night it matters.

What does Aria cover?

Aria Cloud runs the official self-hosted Supabase stack on a private server it sets up and runs. These items from the checklist are covered, as described in the Supabase docs and backups docs:

Checklist item	On Aria
Secrets and database password	Aria generates the keys and password; you never choose them
HTTPS and domain	An address with automatic HTTPS is included at no extra cost; connect a domain you own or buy one
Email	Set auth.smtp in aria.yaml; the SMTP password is a secret you enter in Aria
Backups	Nightly, encrypted, stored off the server, kept 30 days by default, with Storage files
Schema and functions	Applied from the supabase/ folder in your repository on each deploy
Health	aria check tests the gateway, Auth, REST, Storage, Realtime, HTTPS and Auth email

You still decide the plan size, test your restores and handle app-level secrets. Reading status and logs runs straight away for Aria AI or a coding agent, and every other change follows the rules in the safety model. Aria AI, or your coding agent over MCP, can read status and fix things inside those rules. Supabase needs about 4 GB on its own, so we suggest Developer (£16 a month ex VAT) or larger. See pricing and self-hosted Supabase, managed for you.

FAQ

What do I need before self-hosted Supabase is production-ready?

New secrets, HTTPS, working email, off-server backups with a tested restore, an upgrade plan and monitoring for memory and disk. The first five are in the checklist above.

Does the official guide cover backups?

No. The Docker guide does not mention backups. Supabase’s overview lists backups and disaster recovery as your responsibility.

How often should I back up?

At least nightly, and before every upgrade. How much data you can afford to lose decides the schedule. A nightly dump means you can lose up to a day.

Can I get point-in-time recovery?

Not from the standard Docker setup. Supabase lists managed backups and point-in-time recovery among the features missing in self-hosting.

Is self-hosted Supabase supported by Supabase?

It is community-supported, through GitHub Discussions, GitHub Issues, Discord and Reddit.

Can I rotate keys without logging users out?

For the publishable and secret API keys, the rotate script keeps the signing key pair, so existing sessions remain valid. Changing the JWT signing keys is a different operation. Check the guide before you try it.

Run Supabase without running the server. See pricing, read Supabase on Aria, or get started.