Self-hosting Supabase with Docker: the machine you need, the steps and what becomes your job

What it is and what it isn't

It's the same foundation: Postgres, Auth, the REST API, Realtime, Storage, Edge Functions and the Studio, each in its own container. Your app connects the same way with supabase-js, and according to its documentation it doesn't send telemetry to Supabase.

What changes: each install is a single project (the Studio has no organizations or multiple projects), support comes from the community, and it doesn't include branching, advanced metrics, managed backups or PITR, analytics, vector buckets, ETL or the Management API.

The machine you need

According to its Docker guide, at least 4 GB of RAM, 2 cores and 40 GB of SSD; recommended, 8 GB or more, 4 cores or more and 80 GB or more of SSD.

Those GB are for the whole stack, not the database: on our machines, out of 4 GB about 2 are left for Postgres. If you don't use Realtime, Storage, image transforms or functions, you can remove those services and leave it more.

1. Get the configuration and generate the keys

You need Linux with Docker Engine, Docker Compose, Git and OpenSSL. These are the commands from its guide. The tag self-hosted/v0.8.4 is the one it gives as an example: check its documentation for the latest before you copy them.

git clone --depth 1 --branch self-hosted/v0.8.4 https://github.com/supabase/supabase
mkdir supabase-project
cp -rf supabase/docker/. supabase-project
cd supabase-project && cp .env.example .env
printf 'ref=self-hosted/v0.8.4\n' > .supabase-version
docker compose pull
sh utils/generate-keys.sh
sh utils/add-new-auth-keys.sh

2. Configure and start

1. Review .env

   Check what the two scripts wrote and put your addresses in SUPABASE_PUBLIC_URL, API_EXTERNAL_URL and SITE_URL.

2. Change the Studio password

   It's DASHBOARD_PASSWORD. Its guide asks for at least one letter, not just numbers, and no special characters.

3. Start it

   From the docker-compose.yml folder: sh run.sh start. The Studio and the API are on port 8000, and it will ask for the username and password from .env.

3. Before you open it to anyone

No example keys. Its guide says so in bold: never start with the values in .env.example. They're public, so anyone who knows them holds the key to your database. And .env doesn't go in any repository.

HTTPS with a valid certificate. Put a reverse proxy in front that terminates TLS on 443: the address becomes https://your-domain and has to be changed in .env too. Signing in with Google or GitHub needs it.

Email. Its guide asks for a production SMTP server for Auth emails (SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS) and restarting the services afterwards. It recommends AWS SES, and any transactional email provider will do.

The Studio. It's only protected by an HTTP basic password: if you're the only one using it, better that it can't be reached from the whole internet.

4. What becomes your job

Its documentation is clear about what you take on: backups and recovery, security and updates for the system and services, and making sure it stays up.

Backups. Its Docker guide has no procedure, and reset.sh wipes the database and the Storage volumes. You need a scheduled pg_dump, a copy of the Storage files too, everything off that machine and, above all, to try restoring it once: a backup you've never restored isn't a backup. Going back to an exact minute means setting up Postgres archiving yourself.

Updates. A stable version of the configuration comes out roughly every month, and update.sh merges it with your files. Changing a single image has no compatibility promise. Set aside some time each month, with a backup first.

Monitoring. If the machine goes down on a Saturday night, you hear about it from your users or from whatever you've set up to watch it, and you fix it.

Is it worth it?

Yes, if you already look after servers, if you want the data on your own machine or if it's for learning and it doesn't matter if it goes down: the software is free and you only pay for the server.

Less so if your time is worth more than the difference from a managed service. Do the sums with what Supabase really costs: if your project fits within what Pro includes, not maintaining anything will probably work out better.

And there's a middle ground: your own machine on NapNodes, from €15 a month. It's this same open source Supabase, already set up on a virtual machine just for you in the EU, with HTTPS, daily backups, going back to any minute in 7 days, an encrypted off-site copy every night and unmetered egress, all run from a panel. It's still one project per machine, you bring the SMTP (without it, Auth sends no email), and there's no branching, no replicas, no choice of region and no free plan.

Frequently asked questions