Deployment / self-hosting

Two deployment topics live in this repo:

1. Self-hosting the entire Supabase platform via docker/docker-compose.yml. This is the user-facing deliverable.
2. Deploying the apps in this repo (Studio, docs, www, design-system) to Vercel, plus publishing the supabase/studio Docker image.

The first topic is by far the larger one and is what most readers will be looking for.

Self-hosting

The canonical home is the docker/ directory.

File	Role
docker/docker-compose.yml	Main bundle. Defines the runtime stack.
docker/.env.example	Example secrets and config (~10 KB — many knobs).
docker/docker-compose.s3.yml	Override that swaps local Storage backend for S3.
docker/docker-compose.rustfs.yml	Storage backend backed by RustFS.
docker/docker-compose.pg17.yml	Override for Postgres 17.
docker/docker-compose.caddy.yml, docker-compose.envoy.yml, docker-compose.nginx.yml	Alternate edge proxies.
docker/dev/	Studio-dev-only compose overrides.
docker/volumes/	Bind-mounted config and data.
docker/CHANGELOG.md, docker/versions.md	Image-version history and release notes.
docker/reset.sh	Wipes the local stack.

What's running

The compose file starts a complete Supabase platform:

Service	Image	What it does
db	supabase/postgres	Postgres + extensions.
auth	supabase/auth	GoTrue JWT auth.
rest	postgrest/postgrest	Auto-REST over Postgres.
realtime	supabase/realtime	WebSocket fanout from logical replication.
storage	supabase/storage-api	Files API with Postgres-managed permissions.
imgproxy	darthsim/imgproxy	Image transformations.
meta	supabase/postgres-meta	Schema metadata API used by Studio.
functions	supabase/edge-runtime	Deno-based Edge Functions runtime.
analytics	supabase/logflare	Log analytics.
vector	timberio/vector	Logs collector → Logflare.
supavisor	supabase/supavisor	Postgres connection pooler.
studio	supabase/studio (built from this repo)	The dashboard.
kong	kong	API gateway in front of every service.

Quickstart

cd docker
cp .env.example .env       # ! edit secrets before any production use
docker compose up -d

The dashboard is then on http://localhost:8000 (proxied via Kong). Studio is configured via the .env file's DEFAULT_ORGANIZATION_NAME, DEFAULT_PROJECT_NAME, POSTGRES_PASSWORD, JWT_SECRET, and friends.

Production-hardening

docker/README.md is explicit: the default configuration is not secure for production use. Required steps before production:

• Replace every default password and secret in .env.
• Generate fresh JWT secrets.
• Review CORS settings.
• Put a TLS-terminating reverse proxy in front of the stack (Caddy / Envoy / Nginx overrides are provided).
• Configure ACLs / firewall rules at the network layer.
• Plan database backups (docker/dev/ is not enough).

Updating

The recommended order:

1. Read docker/CHANGELOG.md.
2. Check docker/versions.md for the new image versions.
3. Update docker-compose.yml if pinned versions changed.
4. docker compose pull && docker compose down && docker compose up -d.

Tests

docker/tests/ and the self-host-tests-smoke.yml workflow validate that the bundle still boots after compose-file changes.

App deployments

App	Target	Pipeline
apps/www	Vercel (supabase.com)	Vercel auto-deploy on master.
apps/docs	Vercel (supabase.com/docs)	Vercel auto-deploy + scheduled syncers.
apps/studio (hosted)	Vercel	Out-of-band (operated by the platform team).
apps/studio (self-host)	supabase/studio Docker image	studio-docker-build.yml publishes; docker/docker-compose.yml consumes.
apps/design-system	Vercel	Auto-deploy.
apps/ui-library	Vercel	Auto-deploy.

authorize-vercel-deploys.yml and scripts/authorizeVercelDeploys.ts enforce who can trigger preview deploys.

Mirror and release

• mirror.yml mirrors the public repo to internal infrastructure.
• publish_image.yml is the canonical Docker image publishing workflow.
• studio-docker-build.yml builds and publishes supabase/studio for self-host consumers.