Skip to content

Deploying a Supabase App

Introduction

Supabase is an open-source Firebase alternative built around Postgres, PostgREST, and GoTrue authentication. Because Klutch.sh routes one port per app, you deploy Supabase components as separate apps (e.g., PostgREST API and Studio UI) backed by an external Postgres database. This guide shows how to run PostgREST and Studio with Dockerfiles on Klutch.sh, configure environment variables, attach storage, and verify the deployment.


Prerequisites

  • Klutch.sh account (sign up)
  • GitHub repositories containing your Dockerfiles (GitHub is the only supported git source)
  • External Postgres database (required) and optional storage (S3/MinIO) for object storage
  • Service and anon JWT secrets generated for Supabase

Architecture and ports

  • PostgREST API: HTTP on internal port 54321; choose HTTP traffic and set internal port to 54321. External clients call https://example-api.klutch.sh.
  • Supabase Studio: HTTP on internal port 3000; choose HTTP traffic and set internal port to 3000. External users visit https://example-studio.klutch.sh.
  • External Postgres is required; GoTrue/Auth and Storage can be added as additional apps if needed, following the same one-port-per-app pattern.

Repository layouts

PostgREST app:

supabase-postgrest/
├── Dockerfile
└── README.md

Studio app:

supabase-studio/
├── Dockerfile
└── README.md

Keep secrets out of Git; store them in Klutch.sh environment variables.


Dockerfile for PostgREST (production-ready)

Place in supabase-postgrest/Dockerfile:

FROM supabase/postgrest:v12.0.2
ENV PGRST_SERVER_PORT=54321
EXPOSE 54321
CMD ["/bin/postgrest", "/etc/postgrest/postgrest.conf"]

Provide a postgrest.conf via env vars (see below) or bake a config file into the image if you prefer.


Dockerfile for Supabase Studio (production-ready)

Place in supabase-studio/Dockerfile:

FROM supabase/studio:latest
ENV PORT=3000
EXPOSE 3000
CMD ["npm", "run", "start"]

Environment variables (Klutch.sh)

For PostgREST app:

  • PORT=54321
  • PGRST_SERVER_PORT=54321
  • PGRST_DB_URI=postgres://<user>:<password>@<host>:5432/<db>
  • PGRST_DB_SCHEMA=public
  • PGRST_DB_ANON_ROLE=anon
  • PGRST_DB_CHANNEL_ENABLED=true
  • PGRST_JWT_SECRET=<service_jwt_secret>

For Studio app:

  • PORT=3000
  • STUDIO_PG_META_URL=https://example-api.klutch.sh (your PostgREST endpoint)
  • STUDIO_PG_META_PORT=443
  • POSTGRES_PASSWORD=<db-password>
  • POSTGRES_PORT=5432
  • POSTGRES_USER=<db-user>
  • POSTGRES_DB=<db>
  • POSTGRES_HOST=<db-host>
  • SUPABASE_SERVICE_KEY=<service_jwt_secret>
  • SUPABASE_ANON_KEY=<anon_jwt_secret>
  • Optional: STORAGE_BACKEND_URL, S3_ACCESS_KEY, S3_SECRET_KEY, S3_BUCKET

If deploying without Dockerfiles and relying on Nixpacks:

  • PostgREST: NIXPACKS_START_CMD=/bin/postgrest /etc/postgrest/postgrest.conf
  • Studio: NIXPACKS_START_CMD=npm run start

Attach persistent volumes

Optional, if you keep configs/logs locally:

  • PostgREST: /etc/postgrest for config.
  • Studio: /app/.next/cache if you want to persist build cache (not required).

Ensure paths are writable inside the container.


Deploy Supabase components on Klutch.sh (Dockerfile workflow)

  1. Push each repository—with its Dockerfile at the root—to GitHub (one for PostgREST, one for Studio).
  2. In klutch.sh/app, create the PostgREST app: select HTTP traffic, set internal port 54321, add the PostgREST environment variables, and attach volumes if needed.
  3. Deploy PostgREST. Note its URL (e.g., https://example-api.klutch.sh).
  4. Create the Studio app: select HTTP traffic, set internal port 3000, add the Studio environment variables (pointing to your PostgREST URL and database), and attach volumes if desired.
  5. Deploy Studio. Access it at https://example-studio.klutch.sh to manage your database and APIs.

Sample requests

Health/status from PostgREST:

Terminal window
curl -I https://example-api.klutch.sh/

Query data (replace table_name):

Terminal window
curl "https://example-api.klutch.sh/table_name?select=*" \
-H "Authorization: Bearer <anon_or_service_jwt>"

Health checks and production tips

  • Use HTTP readiness probes on / for both apps.
  • Keep JWT secrets and DB credentials in Klutch.sh secrets; rotate regularly.
  • Pin image versions (supabase/postgrest and supabase/studio) and test upgrades in staging before production.
  • Back up your Postgres database regularly; Studio and PostgREST are stateless aside from configuration.

Supabase on Klutch.sh uses separate apps for PostgREST and Studio to align with single-port routing, plus an external Postgres backend. Configure ports, env vars, and storage, then connect Studio to your API and start building.