Setting Up Your Database on Self-Hosted Supabase

The kit is the open-source Supabase self-hosting bundle, pinned to a known version, with a small Pental overlay. It runs the portal’s database on a server of yours: a virtual machine in your Azure, Google Cloud or AWS account, or your own hardware. Your data never leaves it.

Pros and cons

What you need

• A Linux server with Docker Engine 24 or later and Docker Compose 2.24.4 or later (docker compose version says which). Two CPUs, 4 GB of memory and 40 GB of disk suit a small firm.
• A DNS name for it, such as db.yourfirm.com, and the right to add a record for it. The setup offers one on your firm’s own domain.
• Ports 80 and 443 open to the internet. Port 80 is only used to get the certificate and to redirect to 443.
• The server able to reach the internet over https: Docker Hub for the images, Let’s Encrypt for the certificate and pental.io for schema updates.
• Your portal’s address, such as https://yourfirm.pental.io.

Point the name at the server

At your DNS provider, add an A record for the name with the server’s public IP address, then check it has arrived:

dig +short db.yourfirm.com

Install the kit and make its secrets

Download the kit from the Database step (Download the kit), copy it to the server, with scp for example, and run these there. The setup shows them with your own name and portal address already in.

unzip pental-self-hosted-kit-*.zip
cd pental-self-hosted-kit
./pental-setup.sh db.yourfirm.com https://yourfirm.pental.io

pental-setup.sh writes .env with every secret newly generated (never the example keys the whole internet knows), turns on the settings the portal needs, and prints the two things you paste on pental.io: the address and the publishable key. It is safe to run again: it keeps what it made.

Start it

docker compose up -d

The first start downloads the images. Then, on their own, Caddy fetches a TLS certificate for your name from Let’s Encrypt and the Pental updater sets up the portal’s database with Pental’s current schema. Nobody copies SQL anywhere. To check both have happened:

Connect it on pental.io

On the Database step choose Self-hosted Supabase and paste what pental-setup.sh printed, whole: the address and the key are taken from it and the box empties itself. The setup asks your stack straight away and watches until its database is set up. Then press Check and connect: Pental checks every service the portal uses (tables, sign-in, files and live updates), plants Pental’s public keys in your stack’s vault and connects your portal.

Keeping it updated

The database updates itself. When Pental publishes a new schema, the updater applies it at its daily run, 03:00 UTC unless you move it. It only applies SQL Pental has signed, checked against the key the setup planted in your own vault (before you connect, the key its first setup was checked with); anything else is refused and logged. It never applies an older version over a newer one, and an update that fails leaves the database exactly as it was.

In .env, PENTAL_UPDATE_HOUR_UTC (0 to 23) moves the daily run and PENTAL_AUTO_UPDATE=false turns it off. The kit itself updates the way it installs: download the newer kit, unzip it over the folder (your .env and your data stay as they are) and run docker compose up -d --build.

Keeping it safe

• Keep the server’s firewall to ports 80 and 443.
• .env holds every secret. Keep a copy somewhere safe: without it, the database’s sealed secrets cannot be opened.
• Studio, Supabase’s dashboard, is at your address behind the DASHBOARD_USERNAME and DASHBOARD_PASSWORD in .env.
• Back the database up regularly. Nightly, for example:

docker compose exec -T db pg_dumpall -U postgres | gzip > backup-$(date +%F).sql.gz

If something is not right

Moving later

Move it to Supabase Cloud or PostgreSQL in your cloud whenever you like, with everything in it. The move uses the stack’s service key, which grep ^SERVICE_ROLE_KEY= .env prints in the kit’s folder.