Deploy and Host self hosted Supabase Backups (Self-Hosted Supabase with Database Backups) on Railway

This template gives you a full self-hosted Supabase stack plus a clear routine for backing up its Postgres database, storage files and edge functions.

About Hosting Supabase Backups open-source software on Railway (self hosted Supabase backup and restore template)

This template runs the full self-hosted Supabase stack on Railway, with a db service (supabase/postgres 17.6.1.136) keeping data on a volume and a storage service (supabase/storage-api v1.74.0) keeping files on a separate volume.

Why Deploy Supabase Backups, the Supabase Cloud alternative on Railway (Railway Free Trial)

Supabase Cloud includes daily managed backups and point-in-time recovery on paid projects, which is convenient.

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

Your host decides how much backup plumbing you build yourself.

Provider	What You Get with Railway	What You Get with the Other Provider
DigitalOcean	Per-volume backup schedules set in the service panel, with a staged restore you review before deploying.	A Droplet with snapshots, but you write the pg_dump cron job and retention rules yourself.
AWS	Volume backups tied to each service, with restores kept inside the same project and environment.	EBS snapshots and S3 for dumps, flexible but you wire up IAM, lifecycle policies and the restore runbook.
Hetzner	Volume backups managed from the dashboard, with a separate schedule for the db and storage volumes.	Cheap VPS storage, but backups are a script you own, including off-host copies and restore tests.

Railway covers the volume side, while logical dumps stay your job on every provider.

Common Use Cases for hosted Supabase Backups

Nightly logical dumps: Run the three Supabase CLI dumps (roles, schema and data) on a schedule and push the files off Railway. Each dump is a portable copy for any Postgres 17 instance.
Fast rollback: Set Daily and Weekly Railway volume backups on the db and storage volumes. A restore brings back a whole volume quickly, though the two restores may not match the same moment.
Moving from Supabase Cloud: Dump your managed project with the CLI, restore with psql, then copy storage objects with the migration script. Reset custom login role passwords afterward.
Restore drills: Once a month, restore the latest dump into a scratch database with psql using ON_ERROR_STOP, then check row counts. A backup you have never restored is only a guess.
Storage and edge functions: Copy storage objects separately from the database dump, and copy function code from volumes/functions. The CLI does not download import maps or deno.json, so add those by hand.

Dependencies for Supabase Backups Docker hosted on Railway

This template runs nine services, with the database on a persistent volume, and the backup side depends on three things: the db service and its password, a Postgres 17 client on the machine that runs your dumps, and a Railway volume backup schedule.

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

db service: supabase/postgres 17.6.1.136 on a volume, holding roles, schema and data.
storage service: supabase/storage-api v1.74.0 with files on a volume at /var/lib/storage, which needs its own backup schedule.
supabase gateway: Envoy v1.39.1 on port 8000, the only public entry point.
Client tools: supabase CLI and psql or pg_dump 17, plus a temporary TCP proxy on the db service (port 5432) if you dump from outside Railway.

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

Connection string: postgresql://postgres:POSTGRES_PASSWORD@PROXY_HOST:PROXY_PORT/postgres, with the password copied from the db service variables.
Env vars: POSTGRES_PASSWORD, JWT_SECRET and DASHBOARD_PASSWORD are generated per deploy, so store copies off Railway before you rely on a restore.
Dump layout: roles, schema and data go to separate files, because restore order matters.
Volumes: the db and storage volumes get separate Railway backup schedules, and restores are per volume, so the two can drift apart.

How does Supabase Backups compare against other backup options for Postgres backends

Supabase Backups is a set of dump, restore and volume-schedule steps for a Postgres database you run yourself.

Supabase Backups vs Supabase Cloud backups and PITR (Supabase Cloud Alternative)

Recovery granularity: Supabase Backups gives you logical dumps plus Railway volume snapshots, not arbitrary-second recovery.
Who runs it: You own the schedule, storage and restore drill. Managed backups are handled for you on paid managed projects.
Where Cloud wins: If you need minute-level recovery without writing scripts, managed PITR is the easier answer.

Supabase Backups vs Neon branching (Neon Alternative)

Copy method: Neon branches are copy-on-write inside Neon, with no dump file to move. Supabase Backups produces portable SQL files you can store anywhere.
Testing restores: A Neon branch is the fastest way to test against real data. With Supabase Backups you restore into a scratch database with psql, which takes longer but works on any Postgres.

Supabase Backups vs pgBackRest (pgBackRest Alternative)

Scope: pgBackRest supports full, differential and incremental backups plus WAL archiving, the route to point-in-time recovery. Supabase Backups has no documented WAL or PITR procedure for self-hosted Supabase.
Setup effort: pgBackRest needs its own configuration and repository. The Supabase Backups route is a few dump commands and a psql restore.
Where pgBackRest wins: For large databases and real PITR, it is the stronger tool.

Supabase Backups vs Firebase export (Firebase Alternative)

Data format: Firebase exports Firestore data into a proprietary NoSQL layout tied to Google Cloud. Supabase Backups writes standard Postgres SQL that psql reads on any host.
Where Firebase wins: If your app already runs on Firestore, its export is built in and needs no database administration from you.

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

Backups only count once you have tested a restore, so work through these steps on day one.

Open the db service, go to Settings, then Networking, and add a TCP proxy on port 5432. 2. Build the connection string from the db service variables: postgresql://postgres:POSTGRES_PASSWORD@PROXY_HOST:PROXY_PORT/postgres. 3.

supabase db dump --db-url "$DB_URL" -f roles.sql --role-only
supabase db dump --db-url "$DB_URL" -f schema.sql
supabase db dump --db-url "$DB_URL" -f data.sql --use-copy --data-only -x "storage.buckets_vectors" -x "storage.vector_indexes"

psql --single-transaction --variable ON_ERROR_STOP=1 --file roles.sql --file schema.sql --command 'SET session_replication_role = replica' --file data.sql --dbname "$SCRATCH_DB_URL"

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

This section covers running the same Supabase stack on a plain VPS, so you can point the backup routine at your own disks instead of Railway volumes.

Clone the Repository

Pull the upstream Supabase repo with a shallow clone, then move into the Docker folder.

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

Install Dependencies

Install Docker and the Compose plugin on the VPS, then pull the images before you start anything.

docker compose pull

Configure Environment Variables

Copy the example env file and replace every secret before first boot, especially POSTGRES_PASSWORD and JWT_SECRET.

cp .env.example .env
nano .env

Start the Supabase Backups Application

Bring the stack up in the background, then check the db container is healthy.

docker compose up -d
docker compose ps

Railway handles the public domains, persistent volumes and the per-volume backup schedules for you, which a bare VPS leaves to you.

Official Pricing of Supabase Backups (Supabase pricing)

The Supabase Backups template itself is free and open source, so you pay nothing for the software.

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

Self hosting Supabase Backups trades a managed backup button for a routine you own.

Monthly cost of self hosting Supabase Backups on Railway

On Railway, expect roughly 20 to 40 USD per month for the nine small services at light use, and more as the Postgres volume grows.

System Requirements for Hosting Supabase Backups on a VPS

Upstream Supabase suggests at least 4 GB of RAM for the self-hosted stack, and the backup dumps need enough disk for the full database plus the storage files you copy off.

Frequently Asked Questions (FAQs)

Is there point-in-time recovery for a self-hosted Supabase stack?

Not from this template.

Do Railway volume backups replace dumps?

No, keep both.

How do I back up storage files?

Database dumps don't include files on the storage volume.

What about restore errors mentioning supabase_admin?

If schema.sql fails on ALTER ...

How often should I back up?

Run the Railway Daily schedule on both volumes and add a weekly dump of roles, schema and data for longer history.

Where should I store the dump files?

Keep them off Railway, in object