Deploy Supabase | (Just Updated) Firebase Alternative, No Keys To Paste, Data Survives Redeploys

Deploy and Host Supabase on Railway

Supabase is the open-source Firebase alternative: a Postgres database with a REST API, user authentication, file storage, realtime subscriptions and a dashboard (Studio) on top of it.

This template runs the self-hosted stack as eight services in one Railway project: Postgres, Auth (GoTrue), PostgREST, Realtime, Storage, Postgres Meta, Studio and a gateway that puts all of them behind one public domain. There is nothing to fill in at deploy time.

About Hosting Supabase

Supabase is not one program but a set of services that share a Postgres database and one JWT secret. The gateway routes /auth/v1, /rest/v1, /realtime/v1 and /storage/v1 to their services and serves Studio, behind a login, at the root of the domain.

Why Deploy Supabase on Railway

Most self-hosted Supabase guides start with a page of secrets to generate and paste by hand. This template does that part for you:

• No keys to paste. The JWT secret is generated per deploy, and the anon and service_role API keys are derived from it when the services start. The listings that ask for six or more keys at deploy time are asking you to run a script first.
• The dashboard is not open. Studio sits behind a login: user supabase, password in the DASHBOARD_PASSWORD variable of the gateway service, generated per deploy.
• Your keys are on screen, not in a script. Sign in to Studio and open Project Settings, API; the anon and service_role keys and the project URL are there. The URL is the gateway's public domain, and sign-in links and tokens point at it from the first boot.
• Data survives redeploys. Postgres has a volume, so do Storage (uploaded files) and Studio (saved SQL snippets). The pgsodium root key is kept on the Postgres volume, so encrypted columns and Vault secrets still decrypt after a redeploy.
• Verified end to end. On a clean deploy of this template: sign-up returns a token issued for the project URL, REST answers with the anon key, a bucket was created and a file uploaded and fetched, the Realtime websocket upgraded, and all of it was still there after a Postgres redeploy.

Common Use Cases

• Backend for a web or mobile app: auth, database API and file storage with no backend code
• A Firebase replacement with a normal Postgres database underneath
• Realtime features (presence, broadcast, row changes) for dashboards and collaborative apps
• A private development or staging Supabase to match a hosted project

Dependencies for Supabase Hosting

• Three Railway volumes: Postgres data, Storage files and Studio snippets (created by the template)
• Private networking between the services (Railway project default)

Deployment Dependencies

• Supabase self-hosting guide: https://supabase.com/docs/guides/self-hosting
• Images: supabase/postgres, supabase/gotrue, postgrest/postgrest, supabase/realtime, supabase/storage-api, supabase/postgres-meta, supabase/studio and Caddy, wrapped with settings baked in: https://github.com/bon5co/supabase-railway

Implementation Details

Point a client at the gateway's public domain:

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

Not included: edge functions, image transformation, the connection pooler (Supavisor), the logs service and the asymmetric or publishable/secret key formats. The legacy anon and service_role keys work with every supabase client library.