Self-Hosted Supabase: Running It Yourself

Self-hosting is for cases where the cloud does not meet a requirement, not for cases where you want to save money: the saving only appears at volume while the obligations start immediately.

Why

Data must not leave. Personal data, healthcare, finance, a client contract forbidding third parties. The most honest reason: price is not the question.

Volume. At large data and traffic the cloud bill grows until a server becomes cheaper.

Independence. Pricing, availability and service decisions are outside your control.

Full database control. Extensions, settings, direct access - everything the cloud limits.

What is not on that list: “simpler” and “faster”. Usually the opposite.

What the stack includes

Not one program but a set of services running together:

PostgreSQL - the database itself.
An HTTP data layer turning tables into an API.
An authentication service - sign-up, sign-in, tokens.
File storage.
A function runtime.
A dashboard.
A reverse proxy tying it all together.

It usually deploys as containers. The operating principles match those described for the self-hosted n8n stack: data volumes, environment variables, a reverse proxy with a certificate.

A practical detail: you maintain the whole set. Upgrading one service can require coordinating with the others, and that is the main difference from the cloud, where that work is done for you.

What to back up

Three things, all mandatory:

The database. Regularly, automatically, with restores tested. A backup never restored is not a backup.

Storage files. They live separately from the database and get forgotten. A database without them restores links to objects that no longer exist.

Token signing keys. The most underrated item. Losing them invalidates every issued token: users are signed out and integrations stop working until reconfigured.

Plus environment variables and configuration: reconstructing those from memory is its own kind of fun.

Upgrades

An order that lowers risk:

Read the release notes. Breaking changes happen here.
Back up first. Always.
Test environment first. Upgrading a stack is not the same as upgrading one program.
Upgrade regularly. Skipped versions turn an upgrade into a migration across several major versions.
Verify afterwards. Authentication, data access, file upload, functions - down the list.

What you give up compared with the cloud

An honest list:

Automatic backups - you configure them.
One-click scaling - you plan capacity.
Built-in monitoring - you install it.
Availability guarantees - it equals your server’s availability.
Upgrades without your involvement.
Some features available only in the hosted version: the set differs and changes, so check before deciding rather than after.

A practical anchor: self-host when there is a requirement or a volume. For a prototype or a small project the cloud is simpler, and the time saved is worth more than the difference in the bill.

The overview is in the Supabase guide. On automation around the database: pairing with n8n.

FAQ

Why self-host Supabase?

Three reasons: data must not leave your perimeter by law or contract, volume has grown until the cloud bill rivals a server, and you need independence from service availability. In every case the decision comes from constraints rather than convenience.

What does the self-hosted stack include?

Not one program but a set of services: the PostgreSQL database, an HTTP data layer, an authentication service, file storage, a function runtime and a dashboard. They deploy together, usually as containers, and you maintain the whole set.

What must be backed up?

The database, the files in storage, and the keys used to sign tokens. Losing the keys invalidates every issued token: users are signed out and some integrations stop working until reconfigured.