Deploy Supabase Lite

Deploy and Host

A minimal, cost-optimized self-hosted Supabase stack for Railway. Unlike the full 12-service Supabase template that needs 4–8 GB RAM, Supabase Lite runs the 7 core services in ~1.5 GB RAM for roughly $10–15/mo.

About Hosting

Supabase Lite runs 7 Docker-based services on Railway's managed infrastructure. All inter-service communication uses Railway private networking (*.railway.internal). Only the Kong gateway is exposed publicly via a Railway domain. Two persistent volumes are provisioned automatically: postgres-data (mounted at /var/lib/postgresql) and minio-data (mounted at /data).

Why Deploy

• Cost-efficient: ~1.5 GB RAM total vs 4–8 GB for the full Supabase template
• Production-ready auth, REST, realtime, and storage — the core Supabase API surface
• Private by default: only Kong is public; all other services are internal
• No vendor lock-in: standard Supabase images, portable schemas, standard Postgres

Common Use Cases

• Self-hosted backend for a web or mobile app needing auth + database + storage
• Cost-conscious Supabase alternative for hobby/staging projects
• API gateway pattern with Kong routing to auth/rest/realtime/storage
• S3-compatible file storage with MinIO backend

What's included

Not included: Studio UI, imgproxy, postgres-meta, edge-runtime, logflare, supavisor, vector.

Dependencies for

Deployment Dependencies

• PostgreSQL volume (postgres-data) for persistent database storage
• MinIO volume (minio-data) for persistent S3 object storage
• Railway private networking for inter-service communication
• Postgres must be healthy before auth/storage/rest start (handled by startCommand wait loops)

Architecture

┌─────────┐     ┌─────┐     ┌─────────────────────────────────┐
│  Client │────▶│ Kong│────▶│ auth / rest / realtime / storage│
└─────────┘     └─────┘     └─────────────────────────────────┘
                                  │
                    ┌─────────────┴─────────────┐
                    ▼                             ▼
              ┌──────────┐                ┌──────────┐
              │ postgres │                │  minio   │
              └──────────┘                └──────────┘

Post-deploy setup

Your public Supabase URL is the Kong service domain:

https://.up.railway.app

Service paths

Verify the stack

curl -sS "https:///health" -w "\nHTTP %{http_code}\n"
# expected: HTTP 200

Connect with the JS client

import { createClient } from '@supabase/supabase-js'
const supabase = createClient('https://.up.railway.app', '')

Key design decisions

• Postgres roles: Custom entrypoint elevates postgres to SUPERUSER and creates anon, authenticated, service_role roles for migrations.
• Kong DB-less: Declarative config rendered at runtime from Railway private-domain env vars. /health route returns 200 via request-termination plugin.
• Startup ordering: auth and storage use startCommand wait loops (nc -z) to block until postgres (and minio for storage) are accepting TCP connections.
• MinIO binding: Forces 0.0.0.0:8080 for Railway healthcheck compatibility.
• No SMTP: GOTRUE_MAILER_AUTOCONFIRM=true auto-confirms emails. Set SMTP vars for real email.

Troubleshooting

• Services FAILED but logs fine: Set PORT env var to match the app's listening port.
• "permission denied for schema auth": Check postgres logs — ALTER ROLE postgres WITH SUPERUSER must succeed.
• Kong 404 on /health: Don't change healthcheck path; entrypoint defines /health returning 200.
• Realtime crashes: Set APP_NAME=realtime.

License

MIT. All upstream images retain their respective licenses.