Setting Up Your Database on PostgreSQL in Your Cloud
Your cloud’s own PostgreSQL on Azure, AWS or Google Cloud, or a server of yours, with the small Pental gateway beside it. One command builds it all, and it applies Pental’s signed updates itself.
Nothing from Supabase is involved. The Pental gateway is one small service that runs beside your PostgreSQL and gives the portal what it needs: the tables under the schema’s row-level security, sign-in, files and live updates. The schema in your database is the portal’s own, unchanged, and Pental never holds a credential to your database: only the gateway’s address and its publishable key.
Pros and cons
Pros
- Your cloud’s own managed database (Azure Database for PostgreSQL, Amazon RDS or Cloud SQL), under the contract and controls you already have, with daily backups on from the first command.
- One command creates the database, deploys the gateway and prints what the setup asks for.
- On Azure the database has no public address, and on AWS it sits in private subnets.
- Updates apply themselves every day, only when Pental has signed them, and your dashboard applies one at once.
Cons
- Your cloud bills you for the database and for a gateway that is always running.
- The setup token is yours to keep safe: it applies an update on demand, and a move needs it.
- The gateway is one more service to keep current: a new version is a download and the same command again.
What each cloud needs and makes
Each script runs on your own computer, signed in to your cloud (for your own server, on that server), and makes everything in your own account:
| Where | What you need, and what it makes |
|---|---|
| Microsoft Azure | The Azure CLI, signed in with az login. It makes Azure Database for PostgreSQL (Flexible Server) in a private network of its own with no public address, the gateway on Azure Container Apps with https on an Azure address, and a container registry for its image. |
| Amazon Web Services | The AWS CLI, signed in with aws configure, and Docker running. It makes Amazon RDS for PostgreSQL in private subnets, the gateway on ECS Fargate behind a load balancer with a certificate for a name of yours, and the secrets in Secrets Manager. |
| Google Cloud | The gcloud CLI, signed in with gcloud init, which also chooses the project, with billing on it. It makes Cloud SQL for PostgreSQL, the gateway on Cloud Run with https on a Google address, and the secrets in Secret Manager. |
| Your own server | Docker on a Linux server, a DNS name pointed at it and ports 80 and 443 open. It makes PostgreSQL 16, the gateway and Caddy (https from Let’s Encrypt) as containers on that server. |
Download the gateway and run one command
Download the gateway from the Database step (Download the Pental gateway) and run the command for your cloud. The setup writes it for you, with your portal’s address and the region nearest you already in (another is a choice from the list), and offers a name on your own domain where the cloud needs one. These are its shapes:
unzip pental-gateway-*.zip
cd pental-gateway
# Microsoft Azure: resource group, region, portal
deploy/azure/deploy.sh pental-rg uksouth https://yourfirm.pental.io
# Amazon Web Services: stack, region, portal, the gateway’s DNS name
deploy/aws/deploy.sh pental eu-west-2 https://yourfirm.pental.io db.yourfirm.com
# Google Cloud: project (the one gcloud is set to, or its ID), region, portal
deploy/gcp/deploy.sh "$(gcloud config get-value project)" europe-west2 https://yourfirm.pental.io
# Your own server
cd deploy/compose
./pental-setup.sh db.yourfirm.com https://yourfirm.pental.io
docker compose up -d --build- It is safe to run again: it keeps the secrets it made, in a
.deploy-*.envfile beside the script that only you can read, and updates in place. - On AWS the gateway answers on a name of yours. If that name’s DNS zone is in Route 53 in the same account, the certificate and the record are made for you; otherwise the script shows the two records to add and waits for them.
- When it finishes it prints the gateway’s address and a setup token.
Put it in your password manager. It applies an update on demand, and a move uses it later. It goes from your browser to your gateway and nowhere else: Pental never sees it and never stores it.
Connect it on pental.io
On the Database step choose PostgreSQL in your cloud and paste what the script printed, whole. The address and the token are taken from it, the box empties itself, and the gateway is asked at once whether it answers. Then press Set up and connect: your browser applies the portal schema through your gateway, reads its publishable key, has Pental check every service, and connects your portal. The token field is emptied after the run.
Keeping it updated
The gateway fetches Pental’s signed schema bundle every day and applies it itself, checked against the key the setup planted in your database; anything unsigned is refused. An update goes in whole or not at all, and never over a newer version. To apply one straight away, open Database on your pental.io dashboard, press Check for updates now, paste the setup token and choose Check and apply.
The gateway itself updates the way it installs. When your dashboard says a newer gateway is out, download it, unzip it over the folder you deployed from (the script keeps the gateway’s secrets there) and run the same command again; on your own server, docker compose up -d --build in that folder.
If something is not right
| What you see | What to do |
|---|---|
| No Pental gateway answers there yet | If the script has only just finished, give it a minute: the setup keeps asking by itself. |
| The gateway answers but cannot reach its database | The database may still be starting. If it carries on, run the same command again from the same folder: it updates the deployment in place. |
| The gateway does not accept this setup token | Copy it again from the script’s output or your password manager. It is also in the .deploy-*.env file beside the script. |
| The script stops: the gateway exists but this folder has no secrets | Run it from the folder you deployed from, where its .deploy-*.env file is. New secrets would lock the gateway out of its own vault. |
Moving later
Move it to Supabase Cloud or a self-hosted stack whenever you like, with everything in it. The move uses the gateway’s setup token.
Set It Up in the Trial
The Database step picks the region nearest you, offers a name on your own domain and puts both in the one command, then sets the database up through your gateway from your browser.
Also Worth Reading
Creating Your Database: Three Ways to Run It
Your portal runs on a database you own, in one of three places: Supabase Cloud, self-hosted Supabase, or PostgreSQL in your own cloud. What each is, its pros and cons, and the full guide for each.
DatabaseSetting Up Your Database on Supabase Cloud
A Supabase project in your own account, set up in five steps the setup checks as you go: the project, its publishable key, the setup SQL, the access token hook, then connect.
DatabaseSetting Up Your Database on Self-Hosted Supabase
Supabase’s open-source stack on a server you run, from a kit we give you. One script makes its secrets, one command starts it, and it sets up and updates its own database.
Setup guide
Prefer to watch it?
The whole setup recorded, with chapters you can jump to: registering, your own domain, your own database, your own mail server, branding, the first sign-in, and keeping the database updated.
- 0:00 · Registering, signing in, and the free trial
- 0:51 · Your name and your firm’s name
- 0:57 · Custom domain
- +5 more