Supabase

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for Supabase. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of t3.large or larger. Supabase runs about a dozen containers in its Compose stack, including a PostgreSQL database, the Realtime server and the Kong gateway. It benefits from at least two vCPUs and 8 GiB of memory.

Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet. Create or select a security group that allows inbound port 22 from your management network and inbound port 80 from the network you will reach the dashboard from.

Leave the root volume at the default size or larger. The image also attaches a separate 30 GiB gp3 data volume mounted at /var/lib/supabase for the database and object storage.

Select Launch instance. First-boot initialisation takes approximately three to five minutes after the instance state becomes Running and the status checks pass. During that time Supabase rotates every secret and brings its full Compose stack up.

The following command launches an instance from the SecureAnyCloud Supabase Marketplace AMI into an existing subnet and security group.

Replace <ami-id> with the AMI ID shown on the Marketplace listing. Replace <key-name> with your EC2 key pair name and <subnet-id> with your subnet ID. Replace <security-group-id> with a security group that opens ports 22 and 80 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type t3.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":20,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=supabase-01}]'

The command prints a JSON document on success. Note the instance ID. Once the instance is running, retrieve its public address with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connect over SSH with the key pair you selected and the public IP address from Step 2. The SSH login user depends on the operating system of the AMI variant you launched:

AMI variant SSH login user

Supabase self-host on Ubuntu 24.04 ubuntu

The first-boot service rotates every secret and writes the credentials file before it completes, so the file is always in place when you log in for the first time. Read it:

sudo cat /root/supabase-credentials.txt

The plain-text file contains the Supabase URL, the Studio dashboard username (supabase) and password, the auto-generated anon and service_role API keys, and the PostgreSQL superuser password. Copy these values somewhere secure, such as a password manager or encrypted vault. Do not commit them to source control.

From the same SSH session, confirm the deployment is healthy. The nginx liveness endpoint returns ok. An authenticated request to the auto-generated REST API through the Kong gateway returns 200 once the database, the gateway and PostgREST are all up:

curl -fsS http://127.0.0.1/health

ANON=$(sudo grep '^supabase.anon.key=' /root/supabase-credentials.txt | cut -d= -f2-)
curl -fsS -o /dev/null -w '%{http_code}\n' -H "apikey: ${ANON}" http://127.0.0.1/rest/v1/

The first command returns ok and the second returns 200. Together they confirm that nginx, the Kong gateway and the database-backed REST API are all up. The Kong gateway requires the apikey header on the API routes, so an unauthenticated request to those routes returns 401 by design.

You can also inspect the Compose stack directly:

sudo docker compose -f /opt/supabase/docker/docker-compose.yml ps

Every container is reported as Up (most with a (healthy) marker) once the stack has warmed up.

Open a web browser and go to http://<public-ip>/. The Kong gateway presents an HTTP basic authentication challenge for the Studio dashboard.

Enter the dashboard username supabase and the dashboard password from /root/supabase-credentials.txt. The Studio dashboard opens on the default project.

The navigation rail down the left of every page links to the table editor, the SQL editor, the authentication panel, the storage browser, the database tools, the auto-generated API documentation and the project settings.

Select Table Editor in the navigation rail. The table editor is a spreadsheet-style view of your PostgreSQL tables. On a freshly launched instance the default public schema is empty.

Select New table to create your first table. Give it a name, define its columns and types, choose whether to enable Row Level Security, and save. Supabase creates the table in PostgreSQL and immediately exposes it over the auto-generated REST and Realtime APIs.

Select SQL Editor in the navigation rail. The SQL editor runs arbitrary SQL against the PostgreSQL database with the full power of Postgres. You can create tables, define functions and triggers, write Row Level Security policies, install extensions and query your data.

The following statement creates a simple table and inserts a row. Paste it into the editor and select Run:

create table if not exists notes ( id bigint generated always as identity primary key, title text not null, created_at timestamptz default now() ); insert into notes (title) values ('Hello from sac'); select * from notes;

The results grid shows the inserted row. The new notes table now appears in the table editor and is immediately queryable over the REST API.

Supabase exposes every table in the exposed schemas over a RESTful API created by PostgREST. It is served on the same port 80 through the Kong gateway under the /rest/v1/ prefix. Authenticate with the anon API key from the credentials file.

The following command queries the REST API root. PostgREST answers with an OpenAPI description of every endpoint available on your database:

ANON=$(sudo grep '^supabase.anon.key=' /root/supabase-credentials.txt | cut -d= -f2-)
curl -fsS -o /dev/null -w 'rest api http %{http_code}\n' \
  -H "apikey: ${ANON}" \
  -H "Authorization: Bearer ${ANON}" \
  http://127.0.0.1/rest/v1/

A 200 response confirms the REST API is live. Once you create a table such as the notes table from Step 6, it is immediately reachable at http://<public-ip>/rest/v1/notes?select=* from any client that can reach the instance on port 80 and presents the anon key.

The API Docs page in the Studio dashboard documents every auto-generated endpoint for your tables, with ready-to-paste snippets for the JavaScript, Python and other Supabase client libraries.

The Supabase client libraries connect to the instance with the project URL and the anon key. In JavaScript, for example:

import { createClient } from '@supabase/supabase-js' const supabase = createClient('http://<public-ip>', '<anon-key>') const { data, error } = await supabase.from('notes').select('*')

Use the anon key in browser and mobile clients. It is safe to expose and is governed by your Row Level Security policies.

Use the service_role key only on a trusted server. It bypasses Row Level Security and must never be shipped to a client.

Select Authentication in the navigation rail. Supabase ships GoTrue, a complete authentication and user management service. From the dashboard you can invite users, configure email and password sign-in, enable social login providers, set up magic links and manage the JSON Web Token settings.

Every authenticated request carries a JWT signed with the per-instance JWT secret, and your Row Level Security policies can reference the authenticated user with the auth.uid() helper.

Select Storage in the navigation rail. Supabase Storage is an S3-compatible object store for files such as images, videos and documents, with the same Row Level Security model as the database. Create a bucket, upload files through the dashboard or the client libraries, and serve them through the storage API.

The imgproxy service provides on-the-fly image transformations. The object data is stored on the dedicated data volume at /var/lib/supabase/storage.

The deployed image contains the following components:

Component Purpose

Supabase self-host stack The open-source Firebase alternative: database, auth, APIs, storage, Studio

Docker Engine Container runtime that hosts the Supabase Compose stack

Docker Compose plugin Brings the Supabase stack up and down as a single Compose project

nginx Reverse proxy on port 80, forwards to the Kong gateway on loopback

supabase.service systemd unit Wraps docker compose up -d / down at the install directory

supabase-firstboot.service systemd unit One shot service that rotates every secret on first boot

Inside the Compose stack the following containers run:

Container Purpose

supabase-db The PostgreSQL database

supabase-kong The Kong API gateway, the single entry point to the stack

supabase-auth GoTrue authentication and user management

supabase-rest PostgREST auto-generated REST API

supabase-realtime Realtime subscriptions over WebSockets

supabase-storage Object and file storage service

supabase-imgproxy On the fly image transformations for storage

supabase-meta postgres-meta, the database management API

supabase-studio The Studio web dashboard

supabase-pooler Supavisor PostgreSQL connection pooler

Path Purpose

/opt/supabase/docker/ Supabase Compose stack: docker-compose.yml, .env, volumes/

/opt/supabase/docker/.env Stack configuration and the per-instance secrets

/opt/supabase/docker/docker-compose.yml The Compose definition for the whole stack

/var/lib/supabase/ Stateful data root on a dedicated EBS volume

/var/lib/supabase/db-data/ PostgreSQL data directory

/var/lib/supabase/storage/ Storage object data

/root/supabase-credentials.txt Per instance dashboard + API credentials, generated on first boot, root only

The data volume is mounted by UUID in /etc/fstab with the nofail option, so the instance always boots even if the volume is detached.

The Supabase Compose stack is started by systemd at boot through the supabase.service unit. Manage it as follows:

sudo systemctl status supabase.service

To restart the whole stack:

sudo systemctl restart supabase.service

To inspect or follow individual containers, use docker compose from the install directory:

cd /opt/supabase/docker && sudo docker compose ps --format 'table {{.Name}}\t{{.Status}}'

sudo docker compose -f /opt/supabase/docker/docker-compose.yml logs --tail 100 supabase-kong
sudo docker compose -f /opt/supabase/docker/docker-compose.yml logs -f supabase-db

To follow the systemd unit log:

sudo journalctl -u supabase.service -n 50 --no-pager

The PostgreSQL database is reachable inside the instance. Connect with the psql client in the database container using the superuser password from the credentials file:

PGPASS=$(sudo grep '^supabase.postgres.password=' /root/supabase-credentials.txt | cut -d= -f2-) sudo docker exec -e PGPASSWORD="$PGPASS" -i supabase-db psql -U postgres -c '\dt'

For external clients, the Supavisor connection pooler exposes a pooled connection. For production workloads, keep the database on the private network and connect through a bastion or a VPN rather than exposing the database port to the internet.

The stack listens on plain HTTP on port 80. For any deployment beyond a trusted management network, enable HTTPS so credentials and data cannot be intercepted.

The simplest approach is to terminate TLS at nginx. Obtain a certificate for your domain. Then add a TLS server block to the nginx site at /etc/nginx/sites-available/supabase that listens on 443 with your certificate and proxies to the Kong gateway exactly as the port 80 block does. Reload nginx:

sudo nano /etc/nginx/sites-available/supabase
# add a 'listen 443 ssl;' server block with ssl_certificate / ssl_certificate_key
sudo nginx -t sudo systemctl reload nginx

If you need a free, automatically renewed certificate, install certbot, point it at your domain, and let it manage the nginx TLS configuration.

After enabling HTTPS, update SITE_URL, API_EXTERNAL_URL and SUPABASE_PUBLIC_URL in /opt/supabase/docker/.env to your https:// URL. Restart the stack with sudo systemctl restart supabase.service so the dashboard and the auth redirects use the correct external URL. Then restrict the instance security group so port 443 carries the live traffic.

Supabase has two data sources that must be backed up together. The first is the PostgreSQL database in /var/lib/supabase/db-data, which holds your schema, rows, users and policies. The second is the Storage object data in /var/lib/supabase/storage, which holds the uploaded files.

The cleanest database backup is a logical dump taken from the running database container:

PGPASS=$(sudo grep '^supabase.postgres.password=' /root/supabase-credentials.txt | cut -d= -f2-) sudo docker exec -e PGPASSWORD="$PGPASS" supabase-db pg_dumpall -U postgres | sudo tee /var/backups/supabase-$(date +%F).sql > /dev/null

Ship the dump to an Amazon S3 bucket or another object store, and copy the contents of /var/lib/supabase/storage alongside it.

Because the data root is on its own EBS volume, you can also take EBS snapshots of that volume for point-in-time recovery. For a consistent snapshot, stop the stack first with sudo systemctl stop supabase.service.

For kernel and package updates, Ubuntu's unattended-upgrades is enabled by default, so security patches apply automatically. To upgrade Supabase itself, follow the Supabase self-hosting upgrade documentation at https://supabase.com/docs/guides/self-hosting/docker. Pull the new images with sudo docker compose -f /opt/supabase/docker/docker-compose.yml pull, then restart the stack.

For larger deployments, decouple the stateful tiers from the single-instance pattern:

• Move the PostgreSQL database to Amazon RDS for PostgreSQL or Amazon Aurora by pointing the database connection settings in .env at the external endpoint
• Move the Storage object data to Amazon S3 with the storage service's S3 backend
• Front the Kong gateway with an Application Load Balancer for managed TLS termination and horizontal scaling of the stateless services
• Or run Supabase on Amazon EKS for a fully orchestrated deployment