Deploy and Host self hosted Supabase Realtime (Open-Source Firebase Alternative) on Railway

Nine self-hosted Supabase services behind one Envoy gateway, with Realtime v2.134.10 streaming Postgres Changes, Broadcast and Presence.

About Hosting Supabase Realtime open-source software on Railway (self hosted Supabase Realtime template)

You keep the data: rows live in Postgres on a volume you own, and the realtime service that checks RLS and fans out events runs beside it.

Railway handles networking, TLS, volumes and restarts, so you can focus on publications and policies.

Why Deploy Supabase Realtime, the Firebase alternative on Railway (Railway Free Trial)

Firebase ties your live updates to Google's billing and rules model. Here you keep the Postgres rows, the JWT and the RLS policies that decide who sees each change.

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 Realtime on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Railway vs Other Hosting Providers and VPS for Supabase Realtime self hosting

Railway does the gateway wiring; a VPS doesn't.

Provider	What You Get with Railway	What You Get with the Other Provider
DigitalOcean	One template for nine services, a TLS gateway domain, anon key in the logs	A Droplet you size, then Compose, a proxy and certificates
AWS	Generated JWT and Postgres secrets, services on a private network	ECS or EC2 plus load balancers, security groups and IAM
Hetzner	Redeploys keep the volume-backed db, so publication and RLS policies survive	Cheap CPU and RAM, but you own patching, backups and routing

Common Use Cases for hosted Supabase Realtime

Live order or status dashboard: add orders to the supabase_realtime publication and every INSERT or UPDATE arrives in the browser through a postgres_changes subscription. RLS decides which rows each logged-in user actually receives, so a customer sees their own order and an admin sees the board.
Chat room on Broadcast: channel.send({ type: 'broadcast', event: 'msg', payload }) for messages you never persist, or send from the database with realtime.send when the row does need to exist.
Who is online with Presence: channel.track({ user_id }) plus on('presence', { event: 'sync' }) gives you a live roster and join and leave events without a polling endpoint.
Collaborative cursors: Broadcast at high frequency, so pointer moves and selections never touch Postgres and never wait on a replication slot.
Background job finished: an Edge Function or trigger fires a Broadcast when the job completes, and the waiting client updates itself instead of refreshing the page.

Dependencies for Supabase Realtime Docker hosted on Railway

Realtime doesn't run alone here: it needs db (Postgres 17 with the realtime schema), the gateway that routes /realtime/v1, and the shared JWT_SECRET. It also gets its own encryption key per deploy.

Deployment Dependencies for Managed Supabase Realtime Service (Backend as a Service)

Clients connect to the gateway URL and anon key printed in the supabase deploy logs. Every service derives keys from one JWT_SECRET, so never change it on a single service.

Implementation Details for Supabase Realtime (Using Supabase official docker image)

It's an Elixir server that speaks WebSockets and tracks channel topics. Broadcast is ephemeral and can also be sent from SQL with realtime.send. Presence follows join, leave and sync events.

How does Supabase Realtime compare against other realtime backends

Realtime is one service inside a stack you already run.

Supabase Realtime vs Firebase

Data model: Firebase listens on Firestore, a proprietary NoSQL store. Realtime listens to Postgres tables you own.
Rules: Firebase has its own rules language. Realtime reuses RLS: the policy guarding a query also decides which INSERT events a subscriber sees.
Where Firebase wins: offline client persistence and hands-off managed ops.

Supabase Realtime vs Pusher

Ownership: Pusher is hosted pub/sub you never see. Realtime is a container you deploy, so limits and uptime are yours.
Database ties: Realtime streams table changes via Postgres Changes, or you stay event-driven with Broadcast.
Auth: Pusher uses channel auth callbacks. Realtime uses private channels and RLS on realtime.messages, so the rule sits with the data.
Where Pusher wins: zero infrastructure, and fan-out spikes are not your problem.

Supabase Realtime vs Ably

Scope: Ably is a broad messaging platform. Realtime covers three things: changes, Broadcast and Presence.
Cost shape: Ably bills by message volume and connections. Here the bill is Railway compute for nine services, about 20-40 USD/mo at light use.
Where Ably wins: global edge delivery and delivery guarantees a single instance does not match.

Supabase Realtime vs Socket.IO

What it is: Socket.IO is a library plus a Node server you write. Realtime ships the channel API and Postgres listener.
Auth and presence: Socket.IO leaves both to your handlers. Realtime checks the JWT, applies RLS, and ships track and sync events.
Where Socket.IO wins: a few lines in an existing Node app, with full control over rooms and scaling adapters.

How to use Supabase Realtime (the OSS Postgres backend platform)?

Open Studio on your gateway domain, log in as supabase with DASHBOARD_PASSWORD.
Create a table, then add it to the publication so changes stream:

alter publication supabase_realtime add table public.messages;

Enable RLS and add a select policy, since subscribers only receive rows their JWT role can select.
In your app, create the client with the gateway URL and anon key, then subscribe:

supabase.channel("room1").on("postgres_changes",
  { event: "*", schema: "public", table: "messages" },
  p => console.log(p)).subscribe();

Insert a row and watch the event land, then try a Broadcast channel with channel.send({ type: "broadcast", event: "cursor", payload: {} }).

How to self host Supabase Realtime on other VPS Services (Supabase self hosting guide)

Clone the Repository

Grab the upstream repo shallow, then move into the docker directory.

git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker

Install Dependencies

You need Docker Engine and the Compose plugin, plus git. Upstream suggests at least 4 GB RAM for the full stack, since Postgres, Realtime and Studio all run side by side.

Configure Environment Variables

Copy the example file and change every secret before you start anything.

cp .env.example .env

Set POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY, the dashboard credentials and the Realtime encryption keys. Reuse the same JWT_SECRET everywhere or tokens won't validate across services.

Start the Supabase Realtime Application

Pull images, bring the stack up, then check the realtime container logs for a clean boot on port 4000.

docker compose pull
docker compose up -d
docker compose logs -f realtime

On Railway this clone, secret generation and startup ordering are already done: the template wires the gateway URL, anon key and Realtime service together for you.

Official Pricing of Supabase Realtime (Supabase pricing)

Realtime itself is open source and free to self host, so the only bill is the Railway infrastructure under it, roughly 20-40 USD/mo for this nine-service stack at light use.

Supabase Realtime cloud vs self hosted comparison (Pricing, features, costs, and more)

Cloud Realtime and the self-hosted service run the same Elixir code, so Broadcast, Presence and Postgres Changes behave the same.

Monthly cost of self hosting Supabase Realtime on Railway

Nine small services at light use land around 20-40 USD/mo, and that climbs as Postgres grows. Realtime holds every open channel and its Presence state in memory, so a busy chat room costs more than an idle dashboard.

System Requirements for Hosting Supabase Realtime on a VPS

Upstream suggests at least 4 GB RAM for the full stack, and Realtime is the piece that punishes you first when memory runs out. Watch Postgres disk and realtime connections.

Frequently Asked Questions (FAQs)

Why do I get no postgres_changes events?

The table usually isn't in the publication. Empty old records on UPDATE mean you need replica identity full.

Does Realtime respect Row Level Security?

Yes. Each change is checked against every subscriber's JWT, so a client only receives rows its role can select. Sign the user in before subscribing, not after.

Broadcast or Postgres Changes?

Broadcast for cursors and typing indicators, Postgres Changes for state you want persisted. Postgres changes are evaluated per subscriber, so busy tables are better served by a trigger calling realtime.send.

How do private channels work?

Create the channel with config: { private: true } and add RLS policies on realtime.messages for that topic. With no matching policy the join is rejected, which stops a public anon key opening someone else's room.

Where is the realtime endpoint on this template?

Through the supabase gateway on port 8000 at /realtime/v1. supabase-js finds it from the URL and anon key printed in the gateway deploy logs.

How many connections can it handle?

Thousands per Elixir node in theory. Each Railway service has its own resources, so watch realtime memory and Postgres load together, and load test before launch.