Modules / AI and operations
Supabase Cloud
Provision a managed Postgres project and wire the kit onto Supabase.
Setup and configuration
Create a Management API token at supabase.com/dashboard/account/tokens, export SUPABASE_ACCESS_TOKEN, then run pnpm supabase:provision -- --org <slug> --name <name> --region <region>. Without --yes it is a dry run and prints the plan; creating a project can be billable on paid plans. With --write-env it fills DATABASE_URL (session pooler) and STORAGE_* in the root .env without overwriting existing keys unless --force is passed. --migrate runs pnpm --filter @supastack/db db:migrate against the session pooler afterwards.
Choose the pooler deliberately. The session pooler (aws-0-<region>.pooler.supabase.com:5432, user postgres.<ref>) supports prepared statements — use it for migrations and long-lived servers. The transaction pooler (port 6543, pgbouncer) is for serverless functions and drops prepared statements; the kit's postgresClientOptions in packages/db detects port 6543, ?pgbouncer=true, or DATABASE_POOLER=transaction and sets prepare:false automatically. Direct connections (db.<ref>.supabase.co:5432) are IPv6-only on cloud — prefer the pooler from IPv4 networks.
Manual path: create the project in the dashboard, copy the pooled connection string from Connect → Transaction/Session pooler, set DATABASE_URL with sslmode=require, and run the migrate script yourself.
This kit uses Better Auth — not Supabase Auth — so auth tables, sessions, and providers live entirely in the kit's schema; Supabase only supplies Postgres and S3-compatible storage.
DATABASE_URL=postgres://postgres.<ref>:<password>@aws-0-<region>.pooler.supabase.com:5432/postgres?sslmode=require
STORAGE_PROVIDER=s3
STORAGE_ENDPOINT=https://<ref>.supabase.co/storage/v1/s3
STORAGE_REGION=<region>
STORAGE_BUCKET=<bucket>
STORAGE_ACCESS_KEY_ID=<s3 key>
STORAGE_SECRET_ACCESS_KEY=<s3 secret>Implementation workflow
For Supabase Storage, set STORAGE_PROVIDER=s3 with the endpoint https://<ref>.supabase.co/storage/v1/s3 and your project region; the kit enables forcePathStyle automatically for custom endpoints. Create S3 access keys in Dashboard → Storage → S3 connection settings — the Management API cannot mint them.
Backups: the free plan keeps daily backups; Pro adds point-in-time recovery. For your own dump use pg_dump against the session pooler or direct host.
Verification and troubleshooting
Run pnpm supabase:doctor after provisioning: it reports server version, SSL, pooler mode vs prepared statements, pending Drizzle migrations, and — critically — any public tables exposed via PostgREST (RLS disabled or anon/authenticated grants) with the exact fix SQL. --fix-rls applies them in a transaction. Common failures: 'prepared statement already exists' means you connected through :6543 without the prepare:false the kit applies; 'too many connections' means you are exhausting the pooler — lower maxConnections.