Deploy Supabase — Open Source Firebase Alternative

Deploy and Host Supabase on Railway

Supabase is the open-source Firebase alternative — a complete backend built around a real PostgreSQL database, with authentication, an auto-generated REST API, real-time subscriptions, file storage, and a Studio dashboard. This template deploys a streamlined Supabase stack (without Edge Functions and Logflare) on Railway, wired over private networking with the JWT keys generated correctly, so the auth layer that trips up most self-hosters works on the first deploy.

What This Template Deploys

Only Kong is exposed publicly; every other service talks to Postgres over Railway's private network. This build omits Edge Functions and Logflare to keep the stack lean.

About Hosting

Supabase is a multi-service stack, and one detail determines whether it authenticates at all — this template handles it, and understanding it saves hours.

The JWT keys must be generated from the JWT secret — or nothing authenticates. All Supabase services validate requests using JWTs signed with a shared JWT_SECRET. The ANON_KEY (public, respects row-level security) and SERVICE_ROLE_KEY (admin, bypasses RLS — server-side only) are themselves JWTs signed with that secret. If they don't match, every request fails with "Invalid API key." This is the number-one self-hosted Supabase failure, and this template generates a matching secret and key set so the stack authenticates on first deploy.

Only Kong should be public — everything else stays private. The Kong gateway is the single public entry point; Postgres, GoTrue, PostgREST, Realtime, and Storage all connect over Railway's private network and need no public domain. Use Kong's public domain as your SUPABASE_URL in client code, with the ANON_KEY.

Never expose Studio publicly. The Studio dashboard has full access to your database, auth, and storage. It's protected by basic auth, but keep access restricted and don't hand out its URL.

Startup order settles itself. GoTrue and PostgREST need Postgres running with its schemas, so on first deploy they may restart once or twice while Postgres comes up — normal, and Railway's restart policy handles it.

PostgreSQL holds everything — back it up. Your data, plus the auth and storage schemas, all live in Postgres — the one thing you can't lose, so persist and back it up. Rotating JWT_SECRET later invalidates every key and active session at once, so treat the secret as permanent.

Typical cost: ~$15–25/month on Railway across the services, plus storage. Supabase is open source and free; the managed Supabase cloud bills per project and usage.

How It Compares

Firebase is easy but NoSQL and fully Google-hosted. Supabase Cloud is polished but bills per project and keeps your data on their infrastructure. PocketBase is a lighter single-service alternative. Self-hosted Supabase gives you the full Postgres-backed backend — auth, REST API, realtime, and storage — on infrastructure you own, with real SQL and no per-project fees.

Deploy in Under 5 Minutes

1. Click Deploy on Railway — the Supabase services build and wire together (~5 minutes)
2. Confirm JWT_SECRET, ANON_KEY, and SERVICE_ROLE_KEY are set and matching, and set a Postgres password
3. Generate a public domain for the Kong service only (not the other services)
4. Set DASHBOARD_USERNAME / DASHBOARD_PASSWORD and open Studio through Kong to log in
5. Create tables in the SQL editor, then point your client SDK at Kong's URL with the ANON_KEY

Common Use Cases

• Firebase alternative on Postgres — a full backend with real SQL, auth, and storage instead of NoSQL
• App backend-as-a-service — auth, database, REST API, and file storage for web and mobile apps in one stack
• Realtime apps — subscribe to database changes over websockets for live dashboards, chat, and collaboration
• Self-hosted user management — email and social auth with JWT sessions, fully on your infrastructure

Configuration

The keys must be generated from JWT_SECRET. ANON_KEY and SERVICE_ROLE_KEY are JWTs signed with the secret — mismatched keys mean nothing authenticates. This template generates a matching set; if you rotate the secret, regenerate both keys and redeploy every service.

Only expose Kong; keep Studio and Postgres private. Give a public domain to Kong alone. Studio has full admin access — keep it behind its basic auth. Never publish Postgres directly.

Dependencies for Supabase Hosting

• Railway account — ~$15–25/month across the services plus storage
• PostgreSQL (included) — the core of the stack, back it up
• An S3-compatible bucket for the Storage API (Railway bucket or external)
• Optional: SMTP credentials for auth emails

Deployment Dependencies

• Supabase GitHub Repository
• Supabase Self-Hosting Docs
• Railway Supabase Guide
• Railway Private Networking

Implementation Details

The template runs a streamlined Supabase stack — PostgreSQL, GoTrue (auth), PostgREST, Realtime, Storage, Studio, and the Kong API gateway — omitting Edge Functions and Logflare analytics to reduce footprint. Kong is the single public entry point on port 8000, routing by URL path; all other services connect to Postgres over the private network and are not publicly exposed.

Authentication hinges on a shared JWT_SECRET: the ANON_KEY and SERVICE_ROLE_KEY are JWTs signed with it, so they must be generated from the same secret or validation fails across every service. The template provisions a matching set. Studio connects to Postgres directly and is guarded by basic auth; it must not be publicly exposed given its administrative access. On first deploy, GoTrue and PostgREST may restart while Postgres initializes, which Railway resolves automatically. The Storage API needs an S3-compatible backend, and PostgreSQL holds all data plus the auth and storage schemas — the critical component to persist and back up. Clients connect to Kong's public URL with the ANON_KEY; the SERVICE_ROLE_KEY is reserved for server-side use.

Frequently Asked Questions

Why do I get "Invalid API key"? The ANON_KEY or SERVICE_ROLE_KEY doesn't match JWT_SECRET. Both keys are JWTs that must be generated from the secret — this template does that for you. If you change the secret, regenerate both keys and redeploy every service.

Which service gets a public domain? Only Kong, the API gateway. Postgres, GoTrue, PostgREST, Realtime, and Storage stay on the private network. Point your client SDK at Kong's public URL with the ANON_KEY.

Is it safe to expose Studio? No. Studio has full access to your database, auth, and storage. Keep it behind its basic auth and restrict access — never hand out its URL openly.

What's the difference between the anon and service keys? The anon key is public and respects row-level security, safe in frontend code. The service key bypasses RLS with admin rights and must stay server-side only.

Do my services restart on first deploy? Briefly, yes — GoTrue and PostgREST wait for Postgres to initialize its schemas and may restart once or twice. Railway handles this automatically.

How do I connect my app? Use Kong's public URL as SUPABASE_URL and the ANON_KEY in createClient(). Keep the service role key for server-side code only.

Why Deploy Supabase on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Supabase on Railway you get a full open-source backend with the hard part solved — the JWT keys generated correctly so auth works on first deploy, Kong as the single public gateway, and every other service private. A Postgres-backed Firebase alternative with auth, storage, and a REST API, on infrastructure you own.