How to self-host Supabase (and when not to do it by hand)

Supabase is open source, so you can run it yourself. Plenty of people do, usually to control costs, keep data on a server they own, or avoid limits on a hosted plan.

This guide explains what self-hosting Supabase involves, what tends to go wrong, and when it is worth letting a tool do the work. It is based on Supabase’s official self-hosting documentation and on common community experience. Always check the official docs for current commands, because image versions and key names change.

What you are actually running

Supabase is not one program. A self-hosted install runs a set of services together, normally with Docker Compose:

• Postgres, the database everything else sits on.
• Auth (sign-up, sign-in, tokens).
• REST API over your tables.
• Realtime for live subscriptions.
• Storage for files.
• Studio, the dashboard.
• An API gateway that puts them behind one address.

That is roughly a dozen containers. It is a real stack, not a single process, and that shapes everything that follows.

What you need

A server with enough memory

Third-party guides commonly suggest at least 4 GB of RAM for the full stack, and more for real traffic. I could not confirm this against Supabase’s own pages, so check the current official requirements. One 2026 guide reported the stack idling at around 1.5 GB, which leaves little room on a 2 GB server once your own app is running next to it.

Memory is the number that surprises people most. Your application and its database load come on top of Supabase’s own services.

A domain and HTTPS

Supabase serves traffic through its gateway. For anything real you want a domain name, DNS records and a certificate, so browsers and mobile apps connect securely.

An SMTP service for email

Auth sends confirmation and password-reset emails. You need working SMTP settings or sign-up flows will stall.

Time for the boring parts

Backups, updates, monitoring and firewalling are yours to look after.

The manual route, in outline

The official documentation describes a Docker Compose setup. In outline:

1. Get a Linux server and install Docker and Docker Compose.
2. Fetch the official Docker files from the Supabase repository and copy the example environment file to .env.
3. Generate fresh secrets. Never run on the defaults. You need a new JWT secret, new API keys signed with it, and new database and dashboard passwords. Supabase provides helper scripts for this in recent versions; check the docs for the current ones.
4. Start the stack with docker compose up -d.
5. Open Studio through the gateway and sign in with your dashboard credentials.
6. Add your domain, HTTPS and SMTP settings.
7. Close the ports you do not need to expose, and set up backups.

Steps one to five are quick. Steps six and seven are where most of the time goes.

What tends to break after up

These are the recurring issues in community guides, not problems unique to any one setup.

• Data not persisting. If the database directory is not on a persistent volume, a recreated container can start empty. Check where Postgres writes its data before you trust it.
• Default or weak secrets. The example file is for trying things out. Production needs your own.
• Exposed ports. Leaving database or service ports reachable from the internet is a common mistake.
• No backups. A server disk failing is not hypothetical. Dump the database regularly and keep copies off the server.
• Auth email not arriving. Missing or wrong SMTP configuration.
• Out of memory. Containers restarting because the server is too small.
• Version drift. Old guides use old image tags. Supabase’s self-hosted default Postgres version can lag behind what a hosted project runs, so check before you migrate data.

Edge Functions

Supabase’s docs say Edge Functions work out of the box in the self-hosted stack, with a sample function included, and describe how to add your own. The hosted service deploys functions globally, so behaviour is not identical. If you depend on functions heavily, test them early.

Moving from Supabase Cloud

Migrating from a hosted project is more than a database dump. Community guides agree on this point: the database transfer does not move everything.

Piece	Moves with a database dump?	What to do
Tables and data	Yes	Dump and restore, ideally rehearsed first
Roles and extensions	Partly	Check them against the target
Auth users	Stored in the database	Verify sign-in after the move
Storage files	No	Copy objects across separately
Edge Functions	No	Redeploy them to the new setup
Secrets and settings	No	Recreate and point your app at the new URL

Rehearse the whole move on a test copy and only then cut over. Plan for a short window where writes are paused.

Hosted or self-hosted: a quick comparison

	Supabase Cloud	Self-hosted by hand	Self-hosted with Aria
Who runs the servers	Supabase	You	Aria sets up, hardens and runs the server
Updates and backups	Handled for you	You	Aria runs the server; Postgres backups are on the server (see pricing for details)
Pricing	Plan plus usage and compute	Server cost plus your time	One flat monthly price per server
Control of the server	Limited	Full	A dedicated server that you own
Time to first working app	Minutes	Hours to days	Short, via aria.yaml

Supabase’s current pricing is on its own site, and sources disagree on small details, so check there rather than trusting a third-party table.

Where Aria fits

Aria runs the official self-hosted Supabase (Auth, REST, Realtime, Storage and Studio) on a dedicated server that Aria sets up, hardens and runs for you. It also runs your own apps, workers and Postgres or Redis on the same server, and there is a guided move from Supabase Cloud.

The flow is the same as for any Aria project. Your coding agent reads your repository and writes an aria.yaml listing Supabase alongside your services. Aria estimates the memory the stack needs, suggests the smallest plan that fits, provisions the server and deploys. It also wires environment variables for you, including database URLs and generated secrets, and provides SMTP email for apps. Domains get automatic HTTPS.

Pricing is one flat monthly price per server, with draft prices from £8 a month ex VAT. There are no charges per seat, per app, per database or per request. Supabase needs real memory, so the suggested plan for a stack that includes it may well be larger than the entry plan.

Some parts, such as the GitHub App connection and real-domain features that need a server on the internet, are still being rolled out.

When you should self-host by hand

Doing it manually is a good choice if you enjoy it, want to learn how the pieces fit, have specific compliance needs, or need a setup that no tool supports. It is a bad choice if you simply want your app running and have no time for patching and backups.

FAQ

Can I self-host Supabase for free?

The software is open source, so there is no licence fee. You still pay for the server and spend time on setup, backups and updates.

How much RAM does self-hosted Supabase need?

Third-party guides commonly suggest at least 4 GB for the full stack and more for real traffic. Confirm the current figure in Supabase’s own documentation, then add room for your app.

Does self-hosted Supabase include Studio, Auth and Storage?

Yes. The official stack includes Auth, the REST API, Realtime, Storage and Studio, plus an API gateway and Postgres.

Can I move my Supabase Cloud project to my own server?

Yes, but it takes more than a database dump. Storage files and Edge Functions need their own steps, and you should rehearse the move first. Aria offers a guided move from Supabase Cloud.

Do I need Docker knowledge?

For the manual route, yes. With Aria, your agent writes the stack file and Aria handles the server.

Next step

Leaving a hosted project? Read our step-by-step guide to moving from Supabase Cloud to your own server, compare Aria with Supabase Cloud, see pricing, or get started.