Deploy and Host self hosted Supabase Webhooks (Database Change Webhooks for Postgres) on Railway

This template deploys a self-hosted Supabase stack on Railway with Database Webhooks built on pg_net.

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

Your webhook triggers live in your own Postgres, so the table events, the payloads and the delivery log in net._http_response stay on infrastructure you control.

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

Firebase locks your data into Google's proprietary Firestore, while this template runs stock Postgres where pg_net delivers each row-change webhook and net._http_response shows every result.

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 Webhooks 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 Webhooks self hosting

Here is how Railway compares with the usual hosts for the nine Supabase services.

Provider	What You Get with Railway	What You Get with the Other Provider
DigitalOcean	Git-linked deploys of all nine services from one template, with volumes and secrets wired up.	A Droplet you configure yourself, including Docker Compose, the .env file and firewall rules.
AWS	One dashboard and no VPC or IAM design before your first webhook fires.	Finer control over networking and scaling, but more setup time for ECS or EC2.
Hetzner	Managed deploys and restarts without SSH or patching the Docker host.	Low raw price per gigabyte of RAM, with upgrades and backups as manual tasks on a bare server.

Choose based on how much infrastructure work you want versus tuning the webhook pipeline itself.

Common Use Cases for hosted Supabase Webhooks

Welcome emails and Slack alerts: Attach an INSERT webhook to a signups table. The payload's record field carries the new user, so your receiver can send a welcome email or post to Slack without polling.
Cache and search invalidation: Trigger on UPDATE for a products table. Comparing record with old_record shows which fields changed, so you purge only the affected keys.
CRM sync on delete: Use DELETE events and call an Edge Function. On a delete, record is null and old_record holds the removed row, so the function can forward that ID to your CRM.
Row change auditing: Forward type, table, record and old_record to a logging service on every event for a before-and-after trail.
Failure checks without retries: Pg_net does not retry failed deliveries, so check net._http_response for status_code of 400 or higher or a non-null error_msg. Replay those payloads yourself.

Dependencies for Supabase Webhooks Docker hosted on Railway

Supabase Webhooks on Railway is the self-hosted Supabase stack with the webhook path wired in, so the pieces you depend on are the db service (supabase/postgres 17.6.1.136, with pg_net and the trigger function) and the functions service for Edge Function targets.

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

The template provisions the supabase gateway (Envoy, port 8000), db, auth (supabase/gotrue v2.196.0), rest (postgrest v14.17), realtime, storage (volume at /var/lib/storage), meta, functions (supabase/edge-runtime v1.76.2), and studio.

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

If you run the upstream image yourself, the db container is supabase/postgres 17.6.1.136 and needs its data volume plus the init SQL for roles, realtime, and webhooks.

How does Supabase Webhooks compare against other ways to react to Postgres row changes with webhooks

Supabase Database Webhooks wrap Postgres triggers around pg_net, so the HTTP call is queued and sent after the transaction commits.

Supabase Webhooks vs Firebase Cloud Functions triggers (Firebase Alternative)

Where Supabase wins: Triggers live in your own Postgres, so you can read old_record and record directly in SQL.
Where Firebase wins: Cloud Functions triggers are fully managed, and Google handles scaling and retries for you.
Data model: Firestore document events and Postgres row events differ, so migrating means rewriting triggers.

Supabase Webhooks vs Hasura Event Triggers (Hasura Alternative)

Where Supabase wins: The trigger and the webhook sit in one place, with no separate Hasura engine to keep in sync.
Where Hasura wins: Event Triggers offer configurable retries and an event log, which pg_net does not.
Delivery: pg_net queues are unlogged tables, so a crash can lose pending requests.

Supabase Webhooks vs Debezium (Change Data Capture Alternative)

Where Supabase wins: Setup is one SQL trigger, with no Kafka cluster and no connector to run.
Where Debezium wins: It reads the transaction log, so it captures every change at scale and streams to many sinks.
Throughput: pg_net handles about 200 requests per second, which suits app events rather than full data pipelines.

Supabase Webhooks vs Zapier (No-Code Automation Alternative)

Where Supabase wins: Requests go straight from Postgres to your endpoint or Edge Function, with no middleman and no per-task billing.
Where Zapier wins: Non-developers can wire up prebuilt app connectors without writing code.
Maintenance: Zapier handles integration logic for you, while the Supabase path means writing and debugging the receiver yourself.

How to use Supabase Webhooks (the OSS Firebase alternative)?

Open the Supabase Studio Extensions page and confirm pg_net is enabled.
Go to /dashboard/project/_/integrations/webhooks/overview and click create.
Name the webhook, pick the table, and select INSERT, UPDATE and/or DELETE.
For an Edge Function target, set Type of webhook to Supabase Edge Functions, pick the function, then under HTTP Headers select Add secret key. That key lands in the trigger definition, so it appears in database dumps.
To keep it out of dumps, store project_url and secret_key with vault.create_secret(...), then write a security definer trigger function with set search_path = '' that reads vault.decrypted_secrets and calls net.http_post.
Set timeout_milliseconds explicitly, since the default is 2000 ms.
Change a row, then check delivery with select * from net._http_response; and select * from net._http_response where "status_code" >= 400 or "error_msg" is not null order by "created" desc;.

create trigger signups_webhook
after insert or update or delete on public.signups
for each row execute function public.notify_signups();

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

Supabase Webhooks run on Postgres triggers and pg_net, so self-hosting means running the upstream Supabase Docker stack on your server.

Clone the Repository

Shallow-clone the official repository and move into the Docker directory.

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

Install Dependencies

Confirm Compose is present and pull the images. Upstream suggests at least 4 GB of RAM.

docker compose version
docker compose pull

Configure Environment Variables

Copy the example file and replace every secret before the first start.

cp .env.example .env
nano .env

Set POSTGRES_PASSWORD, JWT_SECRET and DASHBOARD_PASSWORD to fresh values.

Start the Supabase Webhooks Application

Bring the stack up detached and confirm the containers report healthy.

docker compose up -d
docker compose ps

Once Studio answers on your domain, enable pg_net and create your first Database Webhook.

Official Pricing of Supabase Webhooks (Supabase pricing)

Supabase Webhooks is free and open source, so there is no license fee to pay for the webhook feature itself.

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

Supabase Cloud and self hosting give you the same database webhook features, but the bill and the operational work differ.

Monthly cost of self hosting Supabase Webhooks on Railway

Railway usage for the nine Supabase services runs roughly 20 to 40 USD per month at light use, rising as your Postgres volume grows.

System Requirements for Hosting Supabase Webhooks on a VPS

Upstream recommends at least 4 GB of RAM, so plan around that for the same nine services on a VPS. Size up if you expect sustained traffic.

Frequently Asked Questions (FAQs)

Does the webhook fire before or after the commit?

Database Webhooks use pg_net, so the request is queued in your transaction but only sent after it commits. A rolled-back insert sends nothing.

Why do my calls time out at 1000 ms?

The upstream SQL example passes '1000' as the timeout, while pg_net's default is 2000 ms.

Why does localhost fail inside the db container?

A localhost or 127.0.0.1 URL points at the Postgres container, not your app.

How do I keep the secret key out of migrations?

Store project_url and secret_key with vault.create_secret, then read them through vault.decrypted_secrets in a security definer trigger function with set search_path = ''.

How long are responses kept in net._http_response?

Responses are kept for 6 hours by default.

Does Supabase retry failed deliveries or verify signatures?

The upstream docs I checked do not document a retry policy or built-in signature verification.